こちらの記事では、インフラエンジニアとして働く私が、経験や本での勉強を踏まえて、システム監視の基本的な概論をまとめました。

サービスを止まらせず、通常運転させることがインフラエンジニアとしての腕の見せどころ。

そんなインフラエンジニアとして働き始めたペーペーの私ですが、監視についての考え方はまとまり始めました。

そこで「個人的な考え方を整理してやろう」と思い立ち、書いた記事です。

他の方のご意見はすごくありがたいので、何かありましたらコメントお願いします🙇

運用は育てるマインド

システム監視の本題に入る前に、運用監視のマインドを定めておきましょう！

【初めから多くは望まず、随時育てる！】

要件定義や現状からわかる範囲でシンプルに定義し、運用しながら徐々に育てていく意識が大切ですね。

「完璧に運用・監視していくぞ」と息巻いても、運用していくうちに課題は見つかるものです。その度に落ち込んでは何も進歩しません。

課題が見つかったら、その課題をどう運用していけば解決に役立てられるか、その都度見つけていこう！というお話です。

「監視項目」 + 「正常な結果」で定義

まずはシステムの正常な状態をしっかり定義しておく。

サービスを提供する会社側としては、

トラブルで不意に意図せず停止・性能低下することがないようにしたい！
もし停止・性能低下した場合には迅速に復旧できるようにして、正常な状態を長く保ちたい！

このように、正常な状態を保つことがシステム監視の目的です。

非機能要件に密接しますが、システムがどうのような状況の時に正常と認めるかを社内で定義しておきましょう。

例えば「ボタンを押して画面を表示するのにかかる時間は3秒以内」などなど。

そうして正常な状態を定義したら、「監視項目」と「閾値」も決めましょう。

閾値の決め方は、要求されている機能要件と非機能要件を満たすこと。

しかし、閾値を低く設定してしまうと、アラートが頻繁に出てしまいます。

アラート発火は極力減らすよう調整したいところ！

いっぱいアラートメールが飛んでしまっては、いざ障害が発生した時に、情報が混乱してしまいます。

誤報や対応不要のアラートは０件に！念の為のアラート発報は厳禁です！

確認したい項目は直接確認

システム監視においては、確認したい項目を直接確認するようにしましょう。

たとえば、「ロードアベレージが高くなると応答時間が遅くなる」という知見があったとしても、ロードアベレージを応答時間の目安にすることはやめよう。応答時間を直接監視するようにしよう。ということです！

正常な状態じゃなくなった時の対応方法を監視項目ごとに定義

正常じゃない状態とは？

完全にダウンした時は分かりやすいが、たまに応答が遅い時など微妙なことも多いです。

「どんな状況だ？....その状況だとこういうアクションを起こそう」という場合わけが必要になりますね。

なんとも言えない場合について、どんな方針で対応するか決めよう。

例えば下記の通り

[正常な状態] ：HTTP応答がステータス 200 である
- [対応方針] → ステータス 500 になった場合は Apache を再起動
[正常な状態] ：ディスク使用量が 80% 以下である
- [対応方針] → 80% を超えた場合はログの保持時間を短くする

正常な状態であることは、ツールを使って継続的に確認しましょう。

ツールじゃなくても、お手製のシェルスクリプトを cron に仕込むやり方もあります。勉強がてらシェルスクリプトを作ってみるのもいいかもしれないです。

っていうか私はそうしています！

ZabbixとかGrafanaとか使っているのに...w

昔は5分おき、10分おきの監視が主流だったが、今はインターネットの普及やサーバ性能の向上によりシステムのリアルタイム性が増してきたこともあり、1〜3分間隔での監視が主流という考え方が一般的ですね。

監視項目を洗い出す

監視には、２つの監視があります。

システムの外部接続状況を監視する「外形監視」
システムの内部を監視する「内部監視」

外形監視の項目は、設計段階で機能要件として明確になっています。

HTTPのみなのか、HTTPSも利用するのか、メールサーバとして利用するかなどです。

内部監視には「サービス稼働状況監視」と、「システムリソース監視」があります。

稼働するサーバ内部のリソースやプロセスを監視するというイメージですね。

[定番] 外形監視の項目

ブラウザからWebアプリにアクセスし表示内容やレスポンスのチェックなど、ユーザーと同じ方法でアクセスしシステムが正常に動作しているのかを確認します。

定期的に外形監視を行うことで、ユーザーがストレスを感じずに使えるか、UIに課題がないかも確認できるので、ユーザー視点でのチェックは不可欠です。

主な監視項目は下記の通りかなと。

HTTPレスポンスコード・内容・応答時間・サイズ
HTTPSレスポンスコード・内容・応答時間・サイズ
POP、SMTP、FTP・・・
死活監視
メール送受信
ファイルPUT・GETなど

[定番] 内部監視の項目

サーバ内部のリソースを監視します。

主な監視項目は下記の通りです。

CPU使用率
ロードアベレージ
ディスクごとの使用量
ディスクごとのI/O要求りょう
ディスクごとのレイテンシ
NICごとのトラフィック IN/OUT
サービスに使うプロセスの監視(apache, nginx, mysqldなど)
システムに使うプロセスの監視(ntpd, snmpdなど)

サーバー上のプロセスの稼働状況を監視することを「プロセス監視」といいます。

システムを想定通りに動かすには、様々なプロセスが正常に動作する必要があります。

そのためシステムを支えるプロセスの動作状況に問題がないかを監視し、何かあった際には迅速に対応できるよう備えることが重要です。

まとめ

いくらきっちりかっちり監視体制を整えたとしても、予想外の障害が起きるものです。

そんな時こそ、インフラエンジニアの出番。

落ち着いて、エラーメールやログを見て、サーバのリソース状況やプロセスなどをくまなく調査し、原因の可能性がありそうな箇所を徹底的に攻める！

調査の時に、見るべきポイントや使えるコマンドなどを頭に入れておけば、スムーズに復旧することもできます。

要するに、普段から備えておこうということですね！