監視

概要

監視（モニタリング）は、システムの健康状態を継続的に観測し、異常が起きたとき — できれば起きる前に — 気づける状態を保つ営みです。CPU使用率、応答時間、エラー率といった数値（メトリクス）を定期的に集め、ダッシュボードで可視化し、閾値を超えたらアラートで人間を呼ぶ。この仕組みがあって初めて、「障害にユーザーより先に気づく」ことができます。

Webサービスを本番運用するなら規模を問わず必須の営みで、Prometheus + Grafana、Datadog、CloudWatchなどのツール・サービスが定番です。サーバが正常か、という素朴な問いから始まり、「ユーザーは快適にサービスを使えているか」という問いに答えるまでが監視の守備範囲です。

なぜ生まれたか

監視がなければ、障害の第一発見者はユーザーです。「サイトが開かない」という問い合わせやSNSの投稿で初めて異常を知り、そこから原因を探し始める — 検知が遅れるほど被害は拡大し、信頼は失われます。また、ディスクの残量枯渇やメモリリークのように、じわじわ進行して突然死に至る問題は、継続的に観測していなければ予兆を掴めません。

さらにクラウドコンピューティングやマイクロサービスの時代になると、システムは多数のサーバやコンテナに分散し、「1台にログインして様子を見る」手法は通用しなくなりました。数百のコンポーネントの状態を人間の目視で追うことは不可能で、観測とアラートを機械化した基盤なしにはシステムを運用できない — 監視は現代の分散システムの前提条件になっています。

詳細

メトリクス収集からアラートまで

監視の基本形は「収集 → 保存 → 可視化 → 通知」のパイプラインです。各サーバやアプリケーションに置かれたエージェント（またはアプリが公開するメトリクスエンドポイント）から数値を定期的に集め、時系列データベースに保存します。Grafanaなどのダッシュボードで推移を可視化し、あらかじめ定義したルール（「エラー率が5%を5分間超えたら」など）に合致したらSlackやPagerDutyへアラートを飛ばす。Prometheusのように監視サーバ側が取りに行くPull型と、エージェントが送りつけるPush型の2方式があります。

何を測るか — 外形監視とゴールデンシグナル

測るべき指標には定石があります。まず「ユーザーから見えるか」を確かめる外形監視（synthetic monitoring）。定期的に外部からHTTPリクエストを送り、正常な応答が返るかを見る、最も素朴で最も重要な監視です。内部の指標としてはGoogleのSRE本が広めた「4つのゴールデンシグナル」— レイテンシ（応答時間）、トラフィック（リクエスト量）、エラー（失敗率）、サチュレーション（資源の飽和度）— が出発点になります。CPU使用率のような資源の指標だけでなく、「ユーザー体験に直結する指標」を軸に据えるのが現代的な設計です。

アラート設計 — 監視の成否を分ける難所

監視で最も難しいのはアラートの設計です。閾値を厳しくしすぎると誤報が乱発し、通知が多すぎて人間が慣れて無視する「アラート疲れ」に陥ります。本当の障害がノイズに埋もれる本末転倒です。原則は「アラートは人間の対応が必要なものだけに絞る」こと。緊急対応が必要なものだけを夜間に人を起こすアラートとし、それ以外はダッシュボードや営業時間内の通知に落とす、という重み付けが欠かせません。SLO（サービスレベル目標: 例「リクエストの99.9%を正常応答する」）を定め、その達成を脅かす消費ペースに基づいてアラートを出す「エラーバジェット」方式は、この問題への洗練された答えです。

可観測性への発展 — ログ・メトリクス・トレース

近年、監視は「可観測性（Observability）」という語彙へ発展しています。メトリクスは「何かがおかしい」を教えてくれますが、「なぜおかしいか」までは語りません。そこで、事象の詳細な記録であるログ、そして1つのリクエストが複数のサービスをまたいで処理される経路を追跡する分散トレースを加えた3本柱で、「未知の問題にも問いを立てて調査できる」状態を目指します。特にマイクロサービスでは、遅延の原因がどのサービスにあるかをトレースなしに特定するのは困難です。OpenTelemetryがこの3種のデータ収集の標準仕様として台頭しており、ベンダーに依存しない計装が現実的になってきました。

「観測できないものは運用できない」が現代運用の合言葉です。監視は障害対応のためだけでなく、スケーリングの判断材料、CI/CDのデプロイ後検証、性能改善の根拠と、運用のあらゆる意思決定の目として機能します。