← クラウドインフラ 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：プロセスとサービス管理（systemd）　|　関連：監視とアラート設計・分散トレーシング

要点（BLUF）

• 可観測性の信号は3種。メトリクス＝数値の時系列（WHATが変わったか）、ログ＝出来事の記録（何が起きたか）、トレース＝1リクエストの経路（どこで遅れたか）。
• 役割が違うので併用する。メトリクスで異常に気づき、トレースで場所を絞り、ログで原因を読む——という流れが定石。
• 収集の標準は OpenTelemetry（OTel）（CNCF標準・ベンダ非依存）。メトリクス可視化は Prometheus＋Grafana が定番。近年は継続的プロファイリングが第4の柱として台頭（要最新確認）。

概念 ── 監視と可観測性の違い

**監視（monitoring）**は「事前に決めた指標を見張る」こと（CPUが80%超えたら警告）。**可観測性（observability）**は「想定していなかった問いにも、出てくる信号から答えられる」度合い。マイクロサービス（Service・Ingress）では障害の形が予測しきれないので、後者が要ります。

その材料が3本柱です。

flowchart LR
    metrics["メトリクス（数値の時系列）→ 異常に気づく"] --> trace["トレース（リクエスト経路）→ 場所を絞る"]
    trace --> logs["ログ（出来事の詳細）→ 原因を読む"]

仕組み ── 3本柱の使い分け

メトリクスは安くて長期保存に向き、ダッシュボードとアラート（監視とアラート設計）の主役。ログは詳細だが量が膨大なので、構造化（JSON）して検索可能に。トレースはサービス横断の遅延切り分けに必須（分散トレーシング）。

ログは systemd の journald（プロセスとサービス管理（systemd））やコンテナの標準出力（コンテナとは（名前空間・cgroups））から集める——「標準出力に出す」習慣がここで効きます。

仕組み ── OpenTelemetry と Prometheus

OpenTelemetry（OTel）は、3信号の生成・収集・送信を標準化する仕様＋SDK。ベンダに依存しない計装（instrumentation）で、後からバックエンド（保存・可視化先）を差し替えられます。

Prometheusは、各サービスが公開する /metrics エンドポイントを**定期的に取りに行く（pull型スクレイプ）**メトリクス基盤。Grafanaでダッシュボード化します。

flowchart LR
    app["アプリ（/metrics を公開）"] -->|"pull スクレイプ"| prom["Prometheus（保存・集計）"]
    prom --> graf["Grafana（ダッシュボード）"]
    prom --> alert["アラート（07-02）"]

# prometheus.yml ── 15秒ごとに自分とアプリの /metrics を取得
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: "myapp"
    static_configs:
      - targets: ["myapp:8000"]   # アプリの /metrics 公開先

なぜ3本柱を併用するのか

• 強みが相補的だから：メトリクスは「異常の検知」に強いが「なぜ」は語らない。ログは「なぜ」に強いが量が多い。トレースは「どこ」に強い。3つで「気づく→絞る→読む」が完結する。
• 標準化で囲い込みを避けるため：OTel で計装を標準化すれば、可視化/保存先（バックエンド）をベンダロックインなしに選べる。
• SLOの土台だから：信頼性の定量化（SREとは・SLI/SLO/エラーバジェット）は、ここで集めたメトリクスがそのまま SLI になる。

⚠️ よくある誤解・落とし穴

• 「ログを全部とれば可観測性は足りる」→ ログだけでは異常検知が遅く高コスト。メトリクスで気づき、ログで深掘る分業を。
• 「メトリクスのカーディナリティ（ラベルの種類）爆発」→ user_id 等を無制限にラベル化すると時系列が爆発し基盤が落ちる。ラベルは有限な次元に。
• 「ログが非構造（ただの文字列）」→ 検索・集計できない。**構造化ログ（JSON）**にし、相関ID（トレースID）を付ける。
• 「全リクエストをトレース」→ 量とコストが膨大。サンプリングで代表を取る（分散トレーシング）。
• 「クラウド固有の監視サービスを最新確認なしに前提」→ 製品名・料金・機能は動きが速い。要最新確認。

対応ラボ

cloud-infra-study/labs/07-01_prometheus.yml ＋ 07-01_observability_compose.yaml（Prometheus＋Grafana を Compose で起動し、ダッシュボードでメトリクスを見る最小構成。Docker 前提）。

関連

• これらの信号でアラートを作るのは 監視とアラート設計
• サービス横断の経路追跡は 分散トレーシング
• ログ源としての標準出力/journaldは プロセスとサービス管理（systemd）
• 集めた信号で信頼性を測るのは SREとは・SLI/SLO/エラーバジェット

← 第7章 監視と可観測性 目次