Zabbixにて障害検知時の切り分けについて
いつもお世話になっております。
Zabbixにて障害を検知したのですが、
インフラ側の問題なのかZabbix側の問題なのか切り分けが出来ず困っております。
良い方法がありましたらお知恵をお借りしたく。
■背景
監視を行っている他社ベンダー様のサーバにおいてメンテナンスがありました。
システム影響は出ないはずでしたが、
シンプルチェック:net.tcp.service[https] にてサービスダウン(0)を検知しました。
(特に何も対応しておりませんが、後にサービスアップ(1)判定となり復旧)
■調査
対象サーバのhttpdを確認したところ、
プロセス稼働時間、ログから見てダウンしておらずZabbixがダウン検知中も起動しておりました。
また、zabbix_server.logを確認しても該当時間帯にTimeoutなどのエラー記載もありませんでした。
※net.tcp.service[http]でも監視を行っていますが、
こちらは正常にサービスアップ(1)判定になっておりました。
■質問
サーバメンテナンスに伴う事象と考えましたが、
他社ベンダー様からは"システム影響は無い"と回答が来ております。
上記の調査からZabbix側もnet.tcp.service[https]を実行し、
正常にダウン判定をした…(サーバはhttps(443)は応答しなかった)と判断しようと考えておりますが、
他に見るべきポイントはありますでしょうか?
■etc
・ZabbixVer:Zabbix 2.2.8
・トリガーは「1分間隔で10回取得して全てサービスダウン(0)であれば障害」としているため
瞬間的なものではなく、何かしらの問題は起こっていたと考えています。
TNK - 投稿数: 4769
プロセスが立ち上がったままであったとしても、ネットワークなど
の他の要因によって、システムの利用者から使うことができていな
かったのであれば、それはシステムに影響があったということにな
るのではないでしょうか?
具体的に何をどうメンテナンスされたのかわかりませんが、シンプ
ルチェックのnet.tcp.service[https]を利用されているとのことで
すので、Zabbixサーバーから接続できない時間があったということ
だと思います。
最新データの画面からnet.tcp.service[https]の値が0になってい
た時間帯を抽出して、その時間帯に何を行っていたのかを確認した
方がよいかもしれません。
例えば、ネットワーク機器のメンテナンス作業も行われていたり、
Zabbixサーバーとの間のネットワークのどこかで障害が発生してい
たりということもなかったのでしょうか?
kaeru - 投稿数: 264
>>TNK様
ご回答ありがとうございます。
>システムの利用者から使うことができていな
>かったのであれば、それはシステムに影響があったということにな
> るのではないでしょうか?
おっしゃる通りかと思います。
ただ、ややこしいことに当方からインフラへの確認ルートが無い状況(契約が無い)状況です。
現行、エンドユーザから該当時間に接続できなかった等の報告が無く、
インフラ側もシステム影響は無いといわれているため、
顧客からはZabbixによる誤検知の可能性を疑われております。
そこで当方は以下を確認しております。
①httpsポート監視はダウンしていたが、httpポート監視はUPしておりhttpdもダウンしていなかった。
②Zabbixのログを確認したところTimeoutやerrorの記載は無かった
①②からZabbix側は正常に動作していた(暗にインフラ側の問題を示唆)と判断しようと考えていますが、
もしTNK様で上記状況に置いて、考慮不足、確認漏れなどお気づきの点がありましたらご指摘頂きたく。
kaeru - 投稿数: 264
自己解決で申し訳ありません。
>②Zabbixのログを確認したところTimeoutやerrorの記載は無かった
上記より、やはりインフラ側と思われるため、
切り分け結果は"インフラにて何かあった"と結論致しました。
ご回答、誠にありがとうございました。