監視
Monitoring ・ かんし
システムの健康状態を継続的に観測し、異常にユーザーより先に気づける状態を保つこと。
✦ 30秒で試す — 航海障害の第一発見者が、利用者になってしまうのはなぜサーバを見張っている監視の画面は？予想してみる概要
監視（モニタリング）は、システムの健康状態を継続的に観測し、異常が起きたとき、できれば起きる前に気づける状態を保つ営みです。CPU 使用率、応答時間、エラー率といった数値（メトリクス）を定期的に集め、ダッシュボードで見えるようにし、条件を満たしたらアラートで人を呼びます。この仕組みがあって初めて、「障害にユーザーより先に気づく」ことができます。
Web サービスを本番で運用するなら、規模を問わず欠かせません。Prometheus と Grafana、Datadog、CloudWatch などのツールやサービスが定番です。サーバが動いているか、という素朴な問いから始まり、「ユーザーは快適にサービスを使えているか」という問いに答えるまでが、監視の守備範囲です。
なぜ生まれたか
監視がなければ、障害の第一発見者はユーザーです。「サイトが開かない」という問い合わせや SNS の投稿で初めて異常を知り、そこから原因を探し始めます。気づくのが遅れるほど被害は広がり、信頼は失われます。ディスクの残量の枯渇やメモリリークのように、じわじわ進んである日突然止まる問題は、継続的に観測していなければ予兆を掴めません。
初期の監視は、決まった間隔でサーバに ping を打ち、応答がなければ知らせる「死活監視」でした。1999年に NetSaint として登場した Nagios（2002年に改名）のような道具が、「チェック項目を並べ、失敗したらアラートを出す」形を広めます。ところがクラウドコンピューティングやマイクロサービスの時代になると、システムは多数のサーバやコンテナに散らばり、台数も数分単位で増えたり減ったりします。「1台にログインして様子を見る」手法も、「サーバの一覧を手で登録してチェックする」手法も通用しなくなりました。何百もの部品の状態を人の目で追うことはできず、観測と通知を機械にした基盤なしには運用が成り立たない。監視は、分散システムの前提条件になっています。
詳細
収集からアラートまで
監視の基本形は「収集 → 保存 → 可視化 → 通知」の流れです。各サーバやアプリに置いたエージェント（またはアプリが公開するメトリクスの窓口）からメトリクスを定期的に集め、時系列データベースに保存します。Grafana などのダッシュボードで推移を描き、あらかじめ決めたルール（「エラー率が5%を5分間超えたら」など）に合えば、Slack や PagerDuty へアラートを飛ばします。監視サーバが取りに行く Pull 型と、エージェントが送りつける Push 型があります。
何を測るか — 外形監視とゴールデンシグナル
測るべきものには定石があります。まず「ユーザーから見えるか」を確かめる外形監視（synthetic monitoring）です。定期的に外から HTTP リクエストを送り、正しい応答が返るかを見ます。いちばん素朴で、いちばん大事な監視です。中の仕組みを知らずに外から見るので「ブラックボックス監視」とも呼ばれ、アプリ自身が出すメトリクスで中から見る「ホワイトボックス監視」と対になります。ロードバランサがサーバの生死を確かめるヘルスチェックも、外から見る監視の一種です。
中から見る指標の出発点は、Google の SRE 本が広めた「4つのゴールデンシグナル」です。レイテンシ（応答時間）、トラフィック（リクエストの量）、エラー（失敗の率）、サチュレーション（資源の飽和の度合い）の4つで、前の2つはレイテンシとスループットの2つの軸にあたります。CPU 使用率のような資源の指標だけでなく、ユーザー体験に直結する指標を軸に据えるのが現代的な設計です。
アラートの設計 — 監視の成否を分ける難所
監視でいちばん難しいのはアラートの設計です。閾値を厳しくしすぎると誤報が乱発し、通知が多すぎて人が慣れて無視する「アラート疲れ」に陥ります。本当の障害がノイズに埋もれる本末転倒です。原則は「アラートは人の対応が必要なものだけに絞る」ことです。夜間に人を起こすのは緊急の対応が要るものだけにし、それ以外はダッシュボードや営業時間内の通知に落とします。
この問題への洗練された答えが、SLO（サービスレベル目標。例: 「リクエストの99.9%を正常に応答する」）に基づくアラートです。SLO から許される失敗の量（エラーバジェット）が決まり、それをどれだけの速さで使っているかで鳴らします。原因が何であれ、ユーザーへの影響が出ているときだけ呼べるようになります。詳しくはアラートの記事で、閾値と比べながら確かめられます。
可観測性への発展 — ログ・メトリクス・トレース
近年、監視は可観測性（Observability）という考え方へ広がっています。メトリクスは「何かがおかしい」を教えてくれますが、「なぜおかしいか」までは語りません。そこで、出来事を1件ずつ記録したログと、1つのリクエストが複数のサービスをまたいで処理される経路を追う分散トレーシングを加え、「事前に想定していない問題にも、後から問いを立てて調べられる」状態を目指します。とくにマイクロサービスでは、遅延の原因がどのサービスにあるかを、トレースなしに特定するのは困難です。OpenTelemetry がこの3種のデータを集める標準として広まり、ベンダーに縛られない計装が現実的になりました。
監視と可観測性は置き換えの関係ではありません。監視は「決まった問い（いま健康か）」を見張り続けて異常に気づく仕組みで、可観測性は気づいたあとに「なぜか」を掘る力です。「観測できないものは運用できない」が現代の運用の合言葉です。監視は障害対応のためだけでなく、スケーリングの判断材料、CI/CD のデプロイ後の確認、性能改善の根拠と、運用のあらゆる判断の目として働きます。こうした実践を体系にまとめたのが、Google の SRE です。
試問
Web サービスの監視から、夜中に8つの知らせが届きました。通知が多すぎると人は慣れて無視するようになり、本当の障害を見落とします。それぞれを、いますぐ当番を起こすべきものと、朝に見れば足りるもの（ダッシュボードや営業時間内の通知）に振り分けてください。
夜中に届いた8つの知らせを、いますぐ人を起こすものと、朝に見れば足りるものに仕分けよ
項目を選んでから、入れる箱を選びます