xDev Asia

オブザーバビリティの3本柱：メトリクス、ログ、トレース。Prometheus、Grafana、 OpenTelemetry、Jaeger、LokiとKubernetesにおけるオブザーバビリティ。

1. オブザーバビリティの3本柱

オブザーバビリティとは、外部からのシグナルを通じてシステムの内部状態を理解する能力です。3つの柱で構成されます：

柱	内容	回答する質問	ツール
Metrics	時間経過に沿った集計データ	「システムの現在の状態は？」	Prometheus + Grafana
Logs	各サービスからのテキストイベント	「何が起きたか？」	Loki、Elasticsearch、Fluentd
Traces	複数サービスを通過するリクエストの流れ	「リクエストはどこを通り、どのくらい時間がかかったか？」	Jaeger、Zipkin、Tempo

User request fails → Use 3 pillars:

  METRICS: CPU spike at 14:05?
  LOGS: Error "DB timeout" in service B  
  TRACES: Request A→B→C, step B took 8s  

  → Root cause: Service B DB connection pool exhausted

試験のポイント： KCNAでは各柱に対応するツールがよく出題されます。Prometheus = メトリクス。Grafana = ビジュアライゼーション。Jaeger = 分散トレーシング。Loki = ログ集約。

2. Prometheusとメトリクス

PrometheusはモニタリングとアラートのためのCNCF graduatedプロジェクトです。プルベース：Prometheusがターゲットからメトリクスをスクレイプします。

Prometheus Architecture:
  App (exposes /metrics)
       ↑ scrape
  Prometheus Server ──► Alert Manager ──► Slack/PagerDuty
       │
  Grafana (query PromQL → charts)

メトリクスタイプ	意味	例
Counter	増加のみ（再起動時にリセット）	http_requests_total
Gauge	自由に増減	memory_usage_bytes
Histogram	分布、パーセンタイル	request_duration_seconds
Summary	事前計算されたパーセンタイル	response_size_summary

3. OpenTelemetry (OTel)

OpenTelemetryはベンダー中立のSDKとCollectorを使用してテレメトリ（メトリクス、ログ、トレース）を収集するためのCNCF標準です。

OpenTelemetry Flow:
  App (instrumented with OTel SDK)
       │ OTLP (protocol)
  OTel Collector (receive, process, export)
       │
  ┌────┴────┐
 Jaeger   Prometheus   Loki
(traces)  (metrics)   (logs)

試験のポイント： OpenTelemetryはアプリからベンダー固有のコードを分離します。JaegerからZipkinへの切り替えはOTel Collectorの設定を変更するだけで、アプリコードの修正は不要です。

4. Kubernetesにおけるオブザーバビリティ

コンポーネント	提供するもの
kubelet /metrics	Prometheus向けのノードリソースメトリクス
metrics-server	kubectl topとHPA向けのCPU/Memory
kube-state-metrics	Kubernetesオブジェクトの状態（Pod、Deploymentのステータス）
Prometheus Operator	CRD（ServiceMonitor）でPrometheusスタックをデプロイ
Loki + Promtail	ログ集約（Promtailがノードからログを収集）

kubectlデバッグコマンド

kubectl logs pod-name              # Current container logs
kubectl logs pod-name --previous   # Last crashed container logs
kubectl logs -f pod-name           # Stream live logs
kubectl describe pod pod-name      # Events + status details
kubectl top pod                    # CPU/Memory (needs metrics-server)
kubectl top node                   # Node resource usage

5. チートシート

試験の質問	回答
オブザーバビリティの3本柱は？	メトリクス、ログ、トレース
分散トレーシングツールは？	Jaeger、Zipkin、Tempo
Kubernetesのメトリクス収集は？	Prometheus
ビジュアライゼーションダッシュボードは？	Grafana
ベンダー中立のテレメトリ標準は？	OpenTelemetry
kubectl topに必要なものは？	metrics-server

6. 練習問題

Q1: チームが1つのHTTPリクエストが5つのマイクロサービスを通過する流れをトレースし、どのサービスが最も遅延を追加しているか調べる必要があります。どのオブザーバビリティツールを使用すべきですか？

A) Prometheus
B) Grafana
C) Jaeger ✓
D) Loki

解説：分散トレーシング（Jaeger、Zipkin）はリクエストの複数サービスにわたる全体の流れを追跡し、各ホップのレイテンシと関係を表示します。Prometheusは集計メトリクス、Lokiはログ、Grafanaはビジュアライゼーションです。

Q2: 起動以来処理されたHTTPリクエストの合計数を追跡するために、どのタイプのPrometheusメトリクスを使用しますか？

A) Gauge
B) Histogram
C) Counter ✓
D) Summary

解説：Counterは単調増加メトリクスで、上がるだけです（再起動時に0にリセット）。リクエスト、エラー、転送バイト数などの累積イベントの追跡に最適です。Gaugeはメモリ使用量のように上下する値に使用します。

Q3: 開発者がアプリケーションを一度インストルメント化するだけで、コード変更なしに複数のバックエンド（Jaeger、Prometheusなど）にテレメトリをエクスポートできるフレームワークはどれですか？

A) Prometheusクライアントライブラリ
B) OpenTelemetry ✓
C) Kubernetes metrics-server
D) Grafana Agent

解説：OpenTelemetryはトレース、メトリクス、ログを生成するためのベンダー中立のAPIとSDKを提供します。OTel Collectorがテレメトリを異なるバックエンドにルーティングします。バックエンドの切り替えにはCollectorの設定変更のみが必要で、アプリケーションコードの変更は不要です。