要点: Observabilityの価値はTelemetry量ではなく、判断時間を短縮することです。
課題
特定RegionやTenantで業務が失敗してもHost DashboardはGreenです。無制限Label、Sampling漏れ、Alert Noiseが運用を弱くします。
単純な対策だけでは不十分な理由
CPUは顧客完了を表しません。PublishやPaymentなどProduct Promiseを測ります。
共通ContextでSLOからTrace、Log Evidenceへ移動します。
処理フロー
User Journey
SLI・SLO→Metrics
集約Signal→Trace
因果関係→Log
選択Evidence
SLI・SLO→Metrics
集約Signal→Trace
因果関係→Log
選択Evidence
アーキテクチャ上の判断
Boundaryで測定
契約上EligibleなBusiness Outcomeを数えます。
Cardinality制御
Route等はMetric、Tenant等はTrace・Logへ置きます。
SymptomでPage
Error-budget Burnを緊急Alertに使います。
さらに深く考える
Rare FailureをSampling保持
Error、Slow Trace、高価値JourneyをTail Ruleで保持します。
SLOでChangeをGovern
Budgetに応じRelease速度とReliability投資を切替えます。
実装手順
- 顧客BoundaryでSLIを定義します。
- Cardinality Policy付きでContextを伝播します。
- Multi-window Error Budget BurnでAlertします。
技術例: Multi-window Burn Rate
budget = 1 - sloTarget
burnShort = errorRate(5m) / budget
burnLong = errorRate(1h) / budget
if burnShort > 14 and burnLong > 6:
page(owner, runbook, affectedJourney)二Windowで短い低影響Spikeを避け、実IncidentからThresholdを調整します。
想定すべき障害パターン
- Queue境界でTrace Contextを失います。
- Tenant Labelが時系列を爆発させます。
- LogへTokenが残ります。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| Journey別Budget Burn | ReliabilityをRelease判断へ接続します。 |
| Region別p50・p95・p99 | Tail問題を分離します。 |
| Telemetry Drop・Sampling率 | Evidence欠落を示します。 |
設計の検証方法
- Host正常のままJourneyを壊しAlertを確認します。
- 高Cardinality入力でもSeriesを制限します。
- HTTP、Queue、Workerを一Traceで追跡します。
安全なRollout計画
重要Journey一つを既存Alertと並行運用し、実Ticketと比較します。OwnerとRunbookが信頼できてから次へ広げます。
本番前チェックリスト
- SLOにOwnerとBudget判断があります。
- Tenant IDを無制限Metric Labelにしません。
- SecretをRedactしData Class別Retentionを使います。
まとめ
良いObservabilityは顧客影響を迅速な根拠付き判断へ変えます。