モニタリングについて

システム・モニタリングについて、少し書きたいと思います。
この記事ではあえて「監視」ではなく、「モニタリング」という表現を使いたいと思います。
システムのモニタリングを構築する際、割と注力するのが障害検知だと思います。ハード障害であったり、スローダウンといった性能障害、DDos攻撃などによるシステム提供障害なんかも検知対象ですね。
こう見ると、割と今現在、システムが正しく動いているかという観点が大部分を占めていますが、モニタリングの観点としては「過去」、「現在」、「未来」の３つの観点での構築が必要だと考えています。
以下では、それぞれの観点がなぜ必要で、どういったものを構築の際に検討しなければいけないかを考察します。

■現在

最も一般的な監視の観点だと思います。
監視対象としているシステムが正常に稼働しているかを監視することが主眼となります。
この設計をする際、「正常に稼働している」をどう定義するかが重要になります。
ありがちなのがサーバのCPU、メモリといった資源の使用率を閾値として監視するような考え方。あとは、サーバにPing応答があるかで死活を監視するような考え方。どちらも良くない設計です。
たとえCPUやメモリが一定の閾値を超えていたとしても、正常にサービスが稼働していて顧客が利用できていた場合、それは有効に資源を使っているわけで何も問題はありません。また、Pingによる応答があったとしても、Webサービスが停止していた場合、そのサービスは利用できていないワケで正常ではないのです。
この「正常に稼働している」というのは、常に顧客視点で考えられるべきだと思います。どういった状態が顧客にとって快適にサービスが利用できる状態なのかを定義し、その定義に従って正常性を定義するのです。
そう考えると、一般的なWebアプリケーションの場合、このような設計になるでしょうか。
・HTTPリクエストに対して適切なレスポンスが返却される
上記の「適切な」というのがポイントで、ここには「応答時間が1～3秒程度」や「HTTPレスポンスコードで200が返却」のほか、製品画像などが含まれる場合には「製品画像のリンク切れがない」といった内容も含まれる。この場合、単純な静的コンテンツだけでなく、検索ボタンを押下して生成する動的ページについてもモニタリングをする必要がある。
また、最近ではセキュリティ上のモニタリングも重要で不正なログインや攻撃はされていないかを常時モニタリングする必要もあります。
この場合、連続で発生するログインエラーや特定のIPアドレスからの連続ログインといったログ情報を解析し、不正な振る舞いとのマッチングが必要となります。

■過去

過去のモニタリングは、システム監査上のトレースや障害調査時を想定します。「いつ」、「誰が」、「何をしたか」を性能やログ情報を保存して、見られるようにしておくことです。
これらのログはいつでも参照できるホットやウォームデータとして保存しておく必要はありませんが、きちんと整理されコールドデータとして保管されている必要があります。
ログの保存年限については、規制がある業界の場合には、その規制に従った保存期間分保存できる必要があり、またこれらの情報が消失や改ざんがされないよう設計しておく必要があります。
簡単に言うと、保存はできるが削除できない仕組みが必要になります。

■未来

未来のモニタリングは、モニタリングしているサービスが数か月先の未来において健全に動作し続けるかを考える行為です。
サービス利用者の動向やCPUやメモリといったリソースの消費状況、クラウドであればコスト状況を見て何かしらのコスト最適化をする必要があるかといった検討をする。こういった行為になります。
未来に対してのモニタリングをするにしても、必要なのは適切なメトリクス情報の取得です。
SREの言葉で言えば、SLIやSLOを定義して、それらに必要なメトリクスが取得できるように設計しておく必要があります。

まとめ

雑なまとめになってしまいましたが、「現在」、「過去」、「未来」の３つの視点でモニタリングを考える。
この中で一番価値のある作業は、「未来」のモニタリングだと思います。
この「未来」のモニタリングに注力するため、「過去」や「現在」のモニタリングは自動化し、極力工数を使わない設計にできると良いと思います。