DNSサーバ障害時にエージェント監視エラー(agent ping失敗)の発生について

お世話になっております。

こんな事象が起きたことありますでしょうか。

Zabbixのエージェント監視のアクティブチェックでそれぞれDNS名ではなくIPアドレスを設定しているのですが、
DNSサーバで障害(DNSが応答しない)が発生した際、それにつられてDNSサーバ以外の監視対象でエージェント監視(agent ping)エラーが多発し致しました。(多発したのは複数台のエージェント監視で同様の事象が起きたため。)

認識としては、IPアドレスを指定している場合、DNS障害に関係なくエージェント監視(agent ping)でエラーとなることは無いと考えていたのですが、
認識間違ってますでしょうか。また、原因についてご存じの方いらっしゃいましたらご教授の程よろしくお願い致します。

<監視の設定>
Zabbix_server側のOS:Ubuntu16.04
Zabbix_agent側のOS:Linux系
Zabbiバージョン:
 ・Zabbix server 4.0.9
 ・Zabbix agent 4.0.9

◆Zabbix エージェント(アクティブチェック)
 Server=XXX.XXX.XXX.XXX[ZabbixサーバのIPアドレス]
 ServerActive=XXX.XXX.XXX.XXX[ZabbixサーバのIPアドレス]
 Hostname=abc
 
◆Zabbixサーバ上のホスト設定
 ホスト名:abc
 IPアドレス:YYY.YYY.YYY.YYY[Zabbix エージェントのIP]
 DNS名 :abc
 接続方法 :IPアドレス
 
◆Zabbixサーバ、エージェントのDNSサーバ参照先
 共に障害のあったDNSサーバのIPアドレスを設定。

<エラーが発生したときのログの出力>
・zabbix_agentd.log(Zabbixエージェントでの監視は複数台あり、そのうちの一台のログ)
4660:20220413:060546.029 active check configuration update from [XXX.XXX.XXX.XXX:10051] started to fail (cannot connect to [[XXX.XXX.XXX.XXX]:10051]: (null))
4660:20220413:060642.802 active check data upload to [XXX.XXX.XXX.XXX:10051] started to fail ([connect] cannot connect to [[XXX.XXX.XXX.XXX]:10051]: (null))
4660:20220413:064523.059 active check data upload to [XXX.XXX.XXX.XXX:10051] is working again
4660:20220413:064526.064 active check data upload to [XXX.XXX.XXX.XXX:10051] started to fail ([connect] cannot connect to [[XXX.XXX.XXX.XXX]:10051]: (null))
4660:20220413:084408.135 active check data upload to [XXX.XXX.XXX.XXX:10051] is working again
4660:20220413:084411.625 active check data upload to [XXX.XXX.XXX.XXX:10051] started to fail ([recv] ZBX_TCP_READ() timed out)
4660:20220413:091647.708 active check data upload to [XXX.XXX.XXX.XXX:10051] is working again
 ~

・zabbix_server.log
6304:20220413:060650.760 failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected
6300:20220413:060858.334 failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected
6300:20220413:060858.335 failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected
6300:20220413:060858.336 failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected
6300:20220413:060942.603 failed to accept an incoming connection: connection rejected, getpeername() failed: [107] Transport endpoint is not connected
 ~

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー TNK の写真

監視対象に対して能動的に(パッシブ)チェックする時には、設定さ
れている通り、IPアドレスで処理されるので問題ないのですが、他
の、他のサーバーからアクセスされたときなど、どこから接続して
きたのかをチェックしたりするためにDNSの名前解決が実施される
ため、DNSでの名前解決ができないことによる処理遅延などが発生
し、結果として監視が途切れてしまう状況になっていた可能性が考
えられます。

対策として、外部のDNSサーバー障害の影響を少なくするため、DNS
のキャッシュを持たせるなどの案も出ていたことがありましたが、
FQDNで運用していて動的にIPが変化する環境もあるため名前解決を
省くわけにもいかないので、現時点ではZabbix自体での対策は取ら
れてはいなかったと思います。

一例:
ZBXNEXT-1002 : dns caching by zabbix daemons
https://support.zabbix.com/browse/ZBXNEXT-1002

ユーザー KI の写真

コメントありがとうございます。

なるほど、、、認識間違ってました。。。
パッシブチェックの場合はIPアドレスの処理で、アクティブチェックの場合は他装置からのアクセスのため、DNSの名前解決が実施されるのですね。。。勉強不足でした。。。

投稿した後ではありますが、いろいろVMなどで再現確認などをしてみて事象が再現できました。
zabbix_server.logのデバッグLv4で出力してみたところ、Trapperの処理で、
DNS名前解決可の処理時間は「0.002489秒」ほどだったのに対し、
DNS名前解決不可の処理時間は「20.011763秒」ほどかかってました。(また、この時、Zabbix管理画面の[監視データ]⇒[グラフ]の『Utilization of trapper data collector process, in %』の使用率上昇を確認しました。)
恐らくはDNS名前解決不可の際、DNSのタイムアウトを待っていて、その間Trapperが捕まりっぱなしになっているようでした。

コメント頂いた通り、処理遅延の発生で監視が途切れてしまう状況になっておりました。
(1台のエージェント監視、Trapperがデフォルトの5プロセスであれば、agent.pingのエラーになることは無かったですが、10台のエージェント監視をしたらagent.pingの障害(5分無応答)が発生しました。)

対策については、実際に試したものとして、
①/etc/hostsにエージェント監視しているIP、ホスト名の記入
 →/etc/hostsにあるIPのものであれば、処理遅延は起きないが、IPが変わると遅延するし、管理が面倒なので、ダメかなと。。。
②Trapperのプロセス数を増やす(zabbix_server.confのStartTrapper=)
 →Trapperの上限1000があるし、サーバ負荷なども気にしなくてはいけなくなるので、ダメかなと。。。
③DNSのタイムアウト、リトライ時間を減らす(/etc/resolv.confに"options timeout:1 attempts:1"を追加してすぐにタイムアウトするようにしてみた)
 →agent.pingの障害は発生しなくなった。OS全体に影響する設定で、他への影響度合いが分からない。。。(DNS名問合せに通常1秒もかからないから、応答なかったら次のDNSサーバに行くっていうのはそれはそれでいい気はしますが・・・^^;)

一旦確認したいことは確認できましたので、ご対応ありがとうございましたm( _ _ )m
対策については、私自身もいろいろ試してみて探ってみてみます。