監視とアラート

監視とは

監視(モニタリング)は、システムが正常に動いているかを継続的にチェックし、異常があれば人に知らせる仕組みです。障害は必ず起きるものなので、「起きたことにすぐ気づける」体制がサービス運用の生命線になります。

利用者からの「サイトが見られない」という連絡で初めて障害を知るのは最悪のパターンです。監視とアラートを整備し、利用者より先に異常へ気づくことが運用の基本目標です。

監視の基本的な種類

代表的なツールに Prometheus(メトリクス収集)+ Grafana(可視化)の組み合わせや、Zabbix、クラウドの CloudWatch などがあります。[[ログ設計]] がきちんとしていると、ログ監視の精度も上がります。

アラート設計のポイント

異常を検知したら、Slack やメール、電話などで担当者に通知します。これがアラートです。アラート設計で最も重要なのは、本当に対応が必要なものだけを通知することです。

• しきい値を適切に設定する(CPU 90%が5分続いたら、など)
• 対応不要なアラートを放置しない — 鳴りすぎるアラートはオオカミ少年化(全部無視される状態)を招く
• アラートには「何が起きたか」「どこを見るべきか」が分かる情報を含める
• 深夜に人を起こすのは、利用者に影響が出ている緊急事態だけに絞る

「アラートが多い=よく監視できている」ではありません。ノイズを減らし続ける地道な調整が、[[SRE]] の重要な仕事の1つです。

初学者向けポイント

• まずは死活監視とディスク残量から。ディスクフルは古典的かつ頻出の障害原因
• ダッシュボードで普段の値を眺めておくと「いつもと違う」に気づけるようになる
• 監視は [[高可用性設計]] とセット — 冗長化していても、壊れたことに気づけなければ意味がない
• メトリクス・ログ・トレースを統合して「なぜ壊れたか」まで追う発展形が [[オブザーバビリティ]]

関連技術とのつながり

• [[オブザーバビリティ]] — 監視の発展形。原因調査までを見据えたデータ収集の考え方
• [[ログ設計]] — ログ監視の精度は元のログの質で決まる
• [[高可用性設計]] — 障害への備え(冗長化)と検知(監視)は両輪
• [[SRE]] — アラート品質の改善やしきい値調整は SRE の中心業務

Q: 監視とアラートの基本目標として正しいのはどれ?
- [x] 利用者より先にシステムの異常に気づくこと
- [ ] 利用者からの連絡を待って障害を知ること
- [ ] アラートの数をできるだけ増やすこと
解説: 利用者からの連絡で障害を知るのは最悪のパターンで、監視により先に気づく体制を作るのが基本目標です。

Q: 死活監視が確認するものはどれ?
- [ ] ソースコードの品質
- [x] サービスが応答するかどうか
- [ ] 開発チームの作業進捗
解説: 死活監視は HTTP で200が返るか、ping が通るかなど、サービスが生きて応答するかを確認します。

Q: アラート設計のポイントとして正しいのはどれ?
- [ ] 些細なことでもすべて通知して安心感を高める
- [ ] 深夜のアラートは無条件にすべて電話で起こす
- [x] 本当に対応が必要なものだけを通知し、ノイズを減らし続ける
解説: 鳴りすぎるアラートは全部無視されるオオカミ少年化を招くため、対応が必要なものに絞る調整が重要です。