はじめに
クラウドで簡単にインフラからアプリケーションまで整えることができるようになりました。
作ったのは良いけど、どのような観点で何を監視するのか分からなかったので、調べてみました。
（基本的な内容です。「入門 監視」に基づいています）
なぜ監視をするのか
監視を行う理由は「サービスを継続させるため」です。
監視することによりパフォーマンス劣化、障害、第三者の攻撃などに気付き対処できます。
調べてみて分かったこと
監視の目的はサービスの継続であるため、サービスの継続に関連しない監視は意味がない。何でもかんでも監視するのではなくサービスに必要な監視に限定するのが望ましい。
監視ツールを使っている場合。
監視はツールで出来る範囲の監視を行うのではなく、まずサービス全体で何を監視したら良いかを考えてからツール選定を行う。先にツールを選んでしまうと「ツールで出来ること＝監視できる範囲」と思い込んでしまう可能性がある。
ツールで監視できない箇所があり、そこで障害が起きサービスが止まったとしてもツールの所為にはできない。
- 監視の負荷を下げるため、検知から復旧までが手順化されているようであれば、なるべく自動化した方が良い。頻度にもよりますが毎回復旧させる手間や時間を考えたら可能な限り自動化し、運用負荷を減らした方が良い。
監視一覧
大きく分けて6つの監視があります。
- ビジネス監視
- フロントエンド監視
- アプリケーション監視
- サーバ監視
- ネットワーク監視
- セキュリティ監視
簡単に１つずつ紹介します。
ビジネス監視
ビジネスのKPI(Key Performance Indicator)を監視します。
例えばDAU(Daily Active User)、MAU(Monthly Active User)、売り上げなどを監視します。
サービスにより何を監視するのかは異なりますので注意してください。
フロントエンド監視
パフォーマンス（表示速度）監視をします。
各ページでどの程度の表示時間なら許容できるかはサービスによって異なります。「入門 監視」では最適なページロード時間は2秒以下、5.1秒を超えるとビジネスに影響が出始めると書かれていました。
表示速度が遅いとコンバージョン率が下がるため、速いに越したことはありません。
アプリケーション監視
アプリケーション監視はAPM(Application Performance Manager)と呼ばれています。
ツールは「NewRelic」や「AppDynamics」が有名です。
観点
- データベースクエリに掛かった時間、API呼び出しに掛かった時間、1日に発生したログイン数などユーザに影響のある個所を監視する。
- アプリケーションのリリース前後でどのような違いがでたかを測定する（パフォーマンスやエラー数など）。
- Healthエンドポイントを用意する。
アプリケーションが起動しているかなどの確認用エンドポイントを用意し、
定期的に実行する。成功すればHTTPステータス200を返し、失敗した場合はHTTPステータス200以外(503など)を返す。これによりサービスの正常性を確認できる。Healthエンドポイントのロジックを複雑にするとエラーとなった場合の調査が難しくなるため、なるべくシンプルに作る。 - ログは定期的に外部にデータを送信する。特にKurbernetesなどを利用しているとサーバやコンテナが落ちたタイミングでログがロストしてしまう可能性がある（後から調査できない状態）。そのため外部へログを送信する仕組みが安全。
- 分散トレーシングを活用しまし。
1つのリクエストが複数のサービスに跨るとログから詳細を追うのが難しくなります。各ログを時間で突き合わせてもなかなか一致しないのが現実です。そのため1つのリクエストに対してIDを割り当てておき、別サービスにもIDを引き継いでいくことで、リクエストの判別が容易になります。
サーバ監視
主な監視対象は次の通りです。
- サーバのCPU、メモリ、ネットワーク、ディスクを監視します。ここで大事なのは、どの状態を異常と判定する。例えば「ディスク使用量が80%を超えたら警告」としてアラートを送信する仕組みを作っていた場合。昨日まで使用率10%だったディスクが今日になって70%だったらどうでしょうか。80%を超えていないので警告ではないですが、正常な状態でしょうか。私は異常と判断し原因を調べます。このようにどの状態を正常、または、異常とするのか基準を決めることが大事。
- SSL証明書。有効期限切れまでどのくらいあるかを知り、それまでに何らかの方法で通知する仕組みが必要。（ドメインレジストラや認証局でも仕組みをもっています）
- WEBサーバー。秒間リクエスト数を監視する。
- データベースサーバ。コネクション数、秒間クエリ数、IOPSを監視する。また遅いクエリの監視もすると改善の役に立つ。
- ロードバランサー。ヘルスチェックを通じてバックエンドサーバの状態を判断する。
- メッセージキュー。キューから取り出され処理されたメッセージとキューの比率（消費率）を監視する。
- キャッシュ。キャッシュから追い出されたアイテム数、ヒットミス比率、またはキャッシュヒット率を監視する。
- DNS。ゾーン転送と秒間クエリ数を監視する。
- NTP。時刻が同期されているかを監視する。
- DHCP。IPアドレスをリースしたDHCPサーバとDHCPプールが十分な余裕をもっているか監視する。
- SMTP。メールサーバを自前でもっちている場合、ヘルスチェックやパフォーマンスなどの監視が必要。
- スケジュールジョブ監視。タスクやcronジョブを監視し、異常を検知する仕組みを作る。
ネットワーク監視
ネットワーク監視の基本はSNMP（Simple Network Management Protocol）を利用します。状態監視、リソース監視、パフォーマンス監視、トラフィック監視を行えます。
1988年からある古いプロトコルですが、現在も利用されています。
ネットワークのパフォーマンスには次の要素があります。
- 帯域幅。
ある接続から一度に送れる理論上の最大情報量。秒間ビット（bits per second）で表される。 - スループット。実際のパフォーマンス。秒間ビットで表される。
プロトコルと送信のオーバーヘッドにより、スループットは帯域幅より小さくなる。
iperf2などのツールでテストできる。
間違えやすい内容として、サーバ管理者はスループットを秒間バイトで話しますが、ネットワークエンジニアは秒間ビットで話します。秒間ビットを8で割れば秒間バイトになる。 - レイテンシ。パケットがネットワークリンクを通じてやり取りされるのにかかる時間
です。ツールは、iperf2、または、smokepingを利用すると良い。 - エラー。
- 送受信エラー
- ドロップ
- CRCエラー
- オーバーラン
- キャリアエラー
- リセット
- コリジョン
- ジッタ。あるメトリックの通常の測定値からの狂いのこと。
セキュリティ監視
セキュリティとは、脅威とリスクを見積もり、不正アクセス時に決断を下すことです。
最低限、SSHのログイン成功とsudoの成功、失敗を監視します。
まとめ
ネットワーク、サーバからアプリケーションまで様々な監視があることが分かりました。
また、上記で上げているものが全部ではありません。
利用しているもの一つ、一つに監視の考え方があり、サービスとして何を監視するのが良いのかを一度じっくり考えるのが大切だと思いました。