監視とは？メトリクス・ログ・トレースでシステムを見る

初級 | 9分 で読める | 2025.12.02

公式ドキュメント
運用Infra

監視とは

システムを観測して異常を検知し、対応と改善を行って再び観測する監視の循環図

監視とは、アプリやサーバーが正常に動いているかを継続的に確認することです。エラーが増えていないか、レスポンスが遅くなっていないか、CPUやメモリが限界に近づいていないかを見ます。

初心者は、監視を「サービスの健康診断」と考えると理解しやすいです。

たとえば、Webサービスでは次のようなものを確認します。

  • サイトが表示できるか
  • APIのエラーが増えていないか
  • レスポンスが遅くなっていないか
  • サーバーのCPUやメモリが高すぎないか
  • データベース接続に失敗していないか

障害が起きてから気づくのではなく、早く気づいて原因を調べるために監視を入れます。

オブザーバビリティとは

オブザーバビリティ（可観測性）は、システムが出す情報から内部状態を調べられる性質です。監視で異常に気づいた後、原因の仮説を検証できる状態を目指します。

役割の違い: 監視は、決めた状態や利用者への影響を継続的に測り、対応が必要な変化を知らせます。オブザーバビリティは、事前に答えを用意していない問いも調べやすくします。

詳しい調査方法は、オブザーバビリティ入門で扱います。

何を監視するか

REDメソッド（サービス向け）:

  • Rate: リクエストレート
  • Errors: エラーレート
  • Duration: レスポンスタイム

USEメソッド（リソース向け）:

  • Utilization: 使用率
  • Saturation: 飽和度
  • Errors: エラー

CPU使用率だけでなく、利用者に見える成功率や応答時間を監視します。サービスレベル目標（SLO）を決めている場合は、目標から外れる速さを表すburn rateを通知条件にすると、利用者への影響と対応の緊急度を結び付けやすくなります。

メトリクスのlabelには、値の種類が増え続けるuser_id、request ID、生のURLを入れません。/users/123ではなく/users/{id}のようなroute template、HTTP method、status classなど、有限な値を使います。

ログにはpassword、access token、Cookie、Authorization header、不要な個人情報、request body全体を記録しません。エラーオブジェクトやHTTPクライアントがheaderを自動出力する場合もあるため、実際の出力を確認します。

アラート

メトリクスに基づいて通知を行います。

ポイント: アラートの設計では「このアラートを受け取った人が具体的にアクションを取れるか」を常に意識してください。対応手順のないアラートは価値がありません。

アラートの設計

# Prometheus alerting rules の例
groups:
  - name: app-alerts
    rules:
      - alert: HighErrorRatio
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            clamp_min(sum(rate(http_requests_total[5m])), 0.001)
          ) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "5xx error ratio is high"
          description: "5xx ratio is {{ $value | humanizePercentage }}"

      - alert: SlowResponseTime
        expr: |
          histogram_quantile(
            0.95,
            sum by (le) (rate(http_response_time_seconds_bucket[5m]))
          ) > 2
        for: 10m
        labels:
          severity: warning

分母をclamp_minで0より大きくしていますが、ほとんどアクセスがない時間帯では少数の失敗で比率が跳ねます。実運用では最低リクエスト数、対象service・route、SLO、評価時間を合わせて調整します。

注意: アラート疲れは深刻な問題です。不要なアラートが多いと、本当に重要なアラートが見逃される危険があります。

アラート疲れの防止

良いアラートの条件:

  • ✓ アクションが必要な事象のみ
  • ✓ 適切な閾値（ノイズを減らす）
  • ✓ 明確な対応手順
  • ✓ エスカレーションポリシー

避けるべきアラート:

  • ✗ 情報提供のみ（ダッシュボードで確認）
  • ✗ すぐに自動復旧する事象
  • ✗ 対応できない深夜のアラート

ダッシュボード

Grafanaダッシュボードの構成

セクション内容
サービス概要リクエストレート / レスポンスタイム（p95）
エラー指標エラーレート / 成功率
リソース使用率CPU / Memory / Disk / Network
ログ最近のエラーログ

まとめ

監視は、利用者への影響を継続的に測り、対応できる人へ知らせる仕組みです。RED/USEやSLOから必要な指標を選び、低cardinalityなlabel、安全なログ、行動可能なアラートとrunbookを用意します。通知後の原因調査では、メトリクス、ログ、トレースを関連付けます。

実践メモ: まずはGolden Signals（レイテンシ、トラフィック、エラー、飽和度）のダッシュボードから始めて、徐々に詳細なメトリクスを追加していきましょう。

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR