【Zabbix】から Linux をうまく監視できないときの切り分けと対策 | SEの道標
zabbix

【Zabbix】から Linux をうまく監視できないときの切り分けと対策

Linux サーバの監視が開始できないときの切り分け方法

監視ポートは Listen になっているか？

エージェント側で ss -nltu を実行し、Zabbix エージェントであれば TCP/10050 が開いているか？SNMP エージェントであれば UDP/161 が開いているかを確認する。

[root@localhost ~]# ss -nltu
Netid   State    Recv-Q    Send-Q                            Local Address:Port       Peer Address:Port   Process
udp     UNCONN   0         0                                  192.168.1.41:161             0.0.0.0:*

firewalld や selinux は邪魔していないか？

特に firewalld は --permanent を付けて設定しないと、再起動時に元に戻ってしまうため、現状はどうなっているか？--reload してポートが開放しているか？の 2 段階で確認する必要がある。services と ports のどちらかに適切な設定が含まれているか確認する。

[root@localhost ~]# firewall-cmd --list-all
~~~
 services: snmp ssh
 ports: 10050/tcp
~~~
[root@localhost ~]# firewall-cmd --reload
[root@localhost ~]# firewall-cmd --list-all
~~~
 services: snmp ssh
 ports: 10050/tcp
~~~

SELinux については今のところ問題は確認できていないが、getenforce で Disabled や Permissive になっているか？なっていない場合は setenforce 0 で Permissive に一時変更し、事象が解消するか確認する。

[root@localhost ~]# setenforce 0

パケットが到達しているか確認する

また、エージェント側にて tcpdump でパケットが来ているかどうかを見るのも良い。192.168.1.40 がサーバである場合、以下のようにフィルタをして udp/161 や tcp/10050 のパケットが来ているか？また、Zabbix サーバへ返信しているか？を確認する。(host 192.168.1.40 を port 161 等に変更してもよい)

[root@localhost ~]# dnf -y install tcpdump
[root@localhost ~]# tcpdump -i eth0 host 192.168.1.40 -nn

Zabbix Web UI 側での確認ポイント

  • ホストに監視アイテムが登録されているか？ (「設定」⇒「ホスト」の上部ペイン「アイテム」に数字が表示されているか？(テンプレートをホストグループだけではなくホストにもリンクしているか？)
  • 「アイテム」の 3 つ右隣の「ディスカバリルール」をクリックし、表示されたディスカバリルールのリストの「監視間隔」の列が 3600 等の長い時間になっていないか？
  • SNMP 監視の SNMP バージョン (v1 , v2 , v3) はエージェント側の設定と合致しているか？(SNMP エージェント側が v2c の場合は Zabbix 側は v2 でよい)
  • SNMP 監視の SNMP コミュニティ名はエージェント側の設定と合致しているか？(マクロ変数で定義している場合はそれを確認)

SNMP エージェント (/etc/snmp/snmpd.conf) の設定の確認ポイント

  • com2sec で定義したコミュニティ名は Zabbix 側と合致しているか？
  • Zabbix サーバは com2sec で定義したアドレスの範囲になっているか？(default が設定されている場合は考慮不要)
  • group で定義した SNMP バージョンは Zabbix 側と合致しているか？
  • access で定義した view は、デフォルトの systemview を使っていないか？

設定に関しては以下も参照。

【入門】Zabbix のエージェントレス Linux 監視セットアップ
Zabbix の主な監視対象、監視方法と、今回の話の範囲 今回は CentOS8...
milestone-of-se.nesuke.com
2021.09.15

特定のトラブルシチュエーション

Zabbix サーバ再起動後、監視が再開されず、なぜか一部だけ未来時刻が観測されていた

事象

VirtualBOX 上の Zabbix 仮想アプライアンス 5.0 LTS にて SNMP エージェントや Zabbix エージェントを設定した後、Zabbix サーバを再起動したら監視が再開されなくなった。

また、一部の監視アイテムについては最新のチェック時刻に未来時刻が刻まれていた。

暫定対処

「設定」⇒「ホスト」にて上部ペインの「アイテム」をクリックし、監視アイテム一覧を表示し、「タイプ」毎に選択肢、「監視データ取得」をクリックすることで再開した。

原因

OS 起動時に時刻同期がされる前に未来時間での監視が行われた結果、Database 上で「次回監視時間」を扱うデータが未来時刻のままになったためではないかと推測される。

DB の調査までは行っていないが、推測の根拠は以下の通り。

起動時の /var/log/messages を確認すると、途中で ntp (chronyd) により時間が 9 時間更新されていた。

Sep  2 23:12:13 appliance systemd[1]: Starting Zabbix Server...
Sep  2 23:12:13 appliance systemd[1]: Started Zabbix Server.
Sep  2 23:12:13 appliance systemd[1]: Reached target Multi-User System.
Sep  2 23:12:13 appliance systemd[1]: Starting Update UTMP about System Runlevel Changes...
Sep  2 23:12:13 appliance systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Sep  2 23:12:13 appliance systemd[1]: Started Update UTMP about System Runlevel Changes.
Sep  2 23:12:13 appliance systemd[1]: Startup finished in 1.415s (kernel) + 15.054s (initrd) + 1min 14.555s (userspace) = 1min 31.025s.
Sep  2 14:12:42 appliance chronyd[649]: Selected source 129.250.35.250 (2.centos.pool.ntp.org)
Sep  2 14:12:42 appliance chronyd[649]: System clock wrong by -32397.673129 seconds

正しい時刻は 9/2 14:12 (JST) であり、UTC は 9/2 5:12 であった。じゃあ 9/2 23:12 は何の時刻か、というと、JST を UTC に見立てたときの JST の時刻であった。

なぜこのようなことが起きるのか。

実は、Linux では以下 3 種類の時計が管理されている。

  • Local time : JST 等の地域の時間。
  • Universal time: システムクロック。UTC として認識される。OS 起動時に RTC (ハードウェアクロック) から引き継がれ、OS 上で使われる時間。
  • RTC time : ハードウェアクロック。本来的にはマザーボードに埋め込まれている時計。仮想マシンの場合は扱いはハイパーバイザによってまちまち。

これは timedatectl で確認できる。

[root@localhost ~]# timedatectl
               Local time: 木 2021-09-02 15:34:00 JST
           Universal time: 木 2021-09-02 06:34:00 UTC
                 RTC time: 木 2021-09-02 15:33:58
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: n/a
          RTC in local TZ: no

そして chrony.conf にて rtcsync が設定されていると Local Time を RTC に書き込むことになる。RTC (ハードウェアクロック) にはタイムゾーンの概念が無いため、JST の時刻を書き込むが、Linux 起動時にはそれを UTC と認識し、OS 上の UTC (システムクロック) に引き継がれてしまう。

結果、JST の時刻を chronyd がハードウェアクロックへ書き込み、OS 再起動時にハードウェアクロックの JST 時刻を UTC 時刻としてシステムクロックへ渡し、そこからローカル時刻を計算し Local time とするが、そこからさらに chronyd で時刻同期を取り、修正される。

この chronyd の時刻修正するまでの間に Zabbix が監視を開始してしまうことが問題であったと推測される。

本格対処

/etc/chrony.conf にて rtcsync を #rtcsync としてコメントアウト。

[root@localhost ~]# vi /etc/chrony.conf
~~~
# rtcsync
~~~
   [Esc -> :wq]
[root@localhost ~]# systemctl restart chronyd

システムクロック (Universal Time) をハードウェアクロック (RTC Time) へ同期。

[root@localhost ~]# hwclock --systohc
[root@localhost ~]# timedatectl
               Local time: 木 2021-09-02 15:37:44 JST
           Universal time: 木 2021-09-02 06:37:44 UTC
                 RTC time: 木 2021-09-02 06:37:43

これで再起動しても監視が再開されるようになった。

コメント

タイトルとURLをコピーしました