はじめに
こんにちは、やすです。
この記事では、サーバの死活監視（ping監視）アラートの対応方法について、紹介します。
このアラートは、よほど用途が限定されているサーバ（重要度が高くないサーバ）以外は、基本的に即時対応が必要です。（2台構成にして冗長化していない限り、そのサーバが提供しているサービスが停止しているということになるので）
ping監視アラートは、通常はメールではなく電話で担当者に連絡がいきます。
障害対応フロー
基本は、下記の図の流れで落ち着いて対応していきましょう。
状況確認
障害対応に限らず、急いでいる時ほど「自分の目で」状況確認が大切です。
誰かから「今こうゆう状況なんです」と言われても、そのままそれを信じて突っ走らず、一旦、自分の目でも確認しましょう。伝言ゲームになっている可能性もあるので。
サーバは、動いているか？
まず、サーバが今動いているか確認しましょう。
・ping監視アラートが、今止まっているを確認する。
・対象サーバに繋がる端末から、手動でpingを飛ばす。
・AWSやVMなどの管理コンソールから、起動状態を確認する。
・実際にログインできる確認してみる。
これで動いていれば、ひとまず安心ですね。
サーバは、さっきは止まっていたのか？
アラートの連絡を受けて対応を開始するまで、そこまで時間は経っていないと思うのですが、念のためサーバが停止した形跡があるかを確認しましょう。
・AWSやVMなどの管理コンソールから、起動時刻を確認する。
・Linuxサーバなら、「uptime」を打ち、何日起動しっぱなしかを確認する。
・Windowsなら、コマンドプロンプトで「systeminfo」を打つか、タスクマネージャーのパフォーマンスタブ（CPU）で起動時刻を確認する。
これで停止した形跡がなければ、サーバ側の問題ではないことは確定ですね。
Zabbixサーバ⇔監視対象サーバ間でping疎通はできるか？
次に、「Zabbixサーバ（監視をしているサーバ）」と「監視対象サーバ（監視をされているサーバ）」間で、念のためping疎通ができるかを手動実行で確認しましょう。
どちら側からpingを打っても大丈夫です。
疎通が取れるのであれば、「一時的なネットワークの問題と考えられるので、様子を見る」で一旦OKです。頻発する、気になるようなら原因調査もしましょう。
疎通が取れなかったり、アラートが停止していないということであれば、「ネットワークまたは間にあるサーバの状態がおかしいと考えられるので、そちらを確認する（他チームに確認してもらう）」となります。
暫定対応（サーバが停止している場合）
計画停止？（作業影響？）
もしサーバが止まっていたら、だれか今何かやっていないか確認しましょう。
作業影響の場合、単純にアラートの抑止漏れということになります。
「次回はアラートの抑止忘れないでくださいね！」と伝えて対応終了です。
作業影響でない場合、いよいよ本当の障害の線が濃厚です。
AWSやVMの管理コンソールから、サーバを起動させましょう！
起動させたら正常動作の確認をし、問題なければ暫定対応はOKです。
上記の対応にある通り、ポイントが2つあります。
１つ目は、作業影響かどうかを調べられる仕組みを普段から整えておくことです。
例えば、関係者全員が見れるスケジュール表のようなものを作り、その時間帯に作業があるかを見れば分かるようにしておいたり、連絡網を整えて、どこに連絡をすれば良いかわかるように整理しておくなどです。
2つ目は、「サーバが正常に動作しているね」という正常動作確認のやり方を普段から整えておくことです。
例えば、どのサービスやプロセスが動いていればOKなのか、どの画面が見れていればOKなのかなど、「なにができていれば、OKなのか」を整理しておきましょう。
原因調査（サーバが動いていた場合）
ネットワークの問題？
「サーバは止まっていないのに、ping監視アラートが鳴った」ということは、「Zabbixサーバと監視対象サーバ間で一時的にping疎通ができない状態だった」と言い換えられます。
つまり、ネットワークの問題です。
・通信経路とその通信経路上にある機器を「traceroute(Linux)」や「tracert(Windows)」で確認する。（経路は毎回固定でない可能性もあるが、大きくは変わらないはず）
・ネットワークの瞬断や遅延、パケットロスがなかったかを確認する。
・ネットワーク機器（スイッチ、ルータ、FW）のログを確認する。
・間にあるサーバに異常はなかったかを確認する。
何にせよ、アラートが鳴ったのはサーバ側の問題じゃないですね。
ping監視の設定の問題？
もう1つの原因としては、ping監視の設定が厳しすぎる（遊びがない）ことが考えられます。
Pingの監視設定が厳しすぎると、軽微なネットワーク遅延や、短時間の一時的なネットワーク不安定でもアラートになります。
pingアラートは鳴ったが、直後の確認でなにも異常がない、ということは誤検知と言い換えられます。監視内容を見直しましょう。
・1回でも応答がなければアラートをあげる、という設定にしていないか？
→ 複数回の結果をもとに判断した方が精度が上がる。
・監視間隔が短すぎないか？
本当に異常があった場合は、確かに早く検知できた方が良いのですが、誤検知が増えて、毎回原因調査までやるとすると、それなりに時間を使います。これはもったいないです。
例えば「監視間隔は5分間隔で、1回でも応答がなければアラート」という条件なら、「監視間隔は1分間隔で、5回連続で応答がなければアラート」の条件にした方が誤検知が減ります。
原因調査（サーバが止まっていた場合）
状況確認と暫定対応が終わったら、原因を調査していきましょう。
リソース不足（高負荷）だった？
まず、インフラ観点としてはリソース状況を確認しましょう。
リソース不足になると最悪OSが停止する可能性もあります。
・AWSやZabbixの管理コンソールから、該当の時間のCPU・メモリ・ディスクの使用率が100%近くなっていなかったかを確認する。
・他の日と比べてどうか（今週の別の日、先週、先月、先月の同じ日など）を確認します。
リソースに異常があればわかりやすいですね。
AWSやVM側で障害はあったか？
次に基盤側で問題がなかったかを確認しましょう。
シスログにエラーなどはあったか？
該当時間になにか手掛かりになるログがでていないかをシスログで確認ます。
まとめ
今回は、ping監視アラートが発生した場合の対応について、まとめました。
落ち着いて1つ1つ対応していきましょう。
事前の準備も大事になってくるので、定期的にチーム内で手順を見ながらシミュレーションしたりロールプレイをしてみると良いと思います。
ではまた、バイバーイ♪
