観測可能性：ログ、メトリック、トレース

観測可能性： ログ、メトリック、トレース

1）なぜそれを必要とします

• メトリックは、SLI/SLOと症状アラートのためのコンパクトな集計です。
• トレース-エンドツーエンドのクエリチェーン。
• ログ-調査と監査のための詳細なイベント。

目的：エラー予算内の高速RCA、予防アラート、および管理された信頼性。

2）アーキテクチャの原則

単一のコンテキスト：どこでも'trace_id'、 'span_id'、 'tenant_id'、 'request_id'、 'user_agent'、 'client_ip_hash'を投げます。
標準：SDK/エージェントのOpenTelemetry （OTel）、 JSONログフォーマット（正規、スキーマ付き）。
症状>原因：CPUではなく、ユーザーの症状（レイテンシ/エラー）による警告。
シグナル通信：→メトリックからexemplars→へ、'trace_id'による特定のログへ。
セキュリティとプライバシー：ログでのPIIマスキング、トランジット/残りの部分での暗号化、不変の監査ログ。
マルチテナンシー：名前空間/キー/ポリシーの分離。

3）シグナル分類とスキーム

3.1メトリクス

RED （Rate、 Errors、 Duration）は、インフラのサービスとUSE （Utilization、 Saturation、 Errors）のためのものです。
対数：counter、 gauge、 histogram/summary。待ち時間については、固定バケット付きのヒストグラム。
例：「hot」ヒストグラムビンの'trace_id'への参照。

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3.2トレース

Span='name'、 'start/end'、' attributes'、'events'、'status'の操作。

• サンプリング：basic （head）+dynamic （tail）+「重要性」のルール（errors、 high p95）。

3.3つのログ

構造化されたJSONのみ。レベル：DEBUG/INFO/WARN/ERROR。
必須フィールドは'ts_utc'、 'level'、 'message'、 'trace_id'、 'span_id'、 'tenant_id'、 'env'、 'service'、 'region'、 'host'、 'labels{}'です。
禁止：秘密、トークン、PAN、パスワード。PII-トークン化/マスクのみ。

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4）収集と輸送

エージェント/エクスポーター（デーモンセット/サイドカー）→→バス/インジェストノード（TLS/mTLS）→シグナルストア上のバッファ。
要件：背圧、リトレイ、重複排除、カーディナリティ制限（ラベル！）、「ログストーム」に対する保護。

メトリクス：プル（Prometheus互換）またはOTLP経由でプッシュ。
トレース：OTLP/HTTP （gRPC）、コレクター上のテールサンプラー。
ログ：ローカルコレクション（journal/docker/stdout）→parser→normalizer。

5）貯蔵および保持（階層化される）

メトリクス：ホットTSDB 7-30日（ダウンサンプル付き）、より長い期間（90-365日）の集計。
トレース：1-7日間フル、その後、集計/「重要な」サービスのスパン；'service'、 'status'、 'error'にインデックスを保存します。
ログ：ホットインデックス7-14日、暖かい3-6ヶ月、アーカイブ1-7年まで（コンプライアンス）。監査-WORM。

コストの最適化：ダウンサンプリング、販売におけるDEBUGフィルタリング、ラベルクォータ、トラックのサンプリング。

6） SLI/SLO、警報および義務

SLI：可用性（％成功リクエスト）、レイテンシ（p95/p99）、 5xx共有、データの鮮度、成功したジョブの共有。
SLO： SLI上のターゲット（例：99.9％成功≤ 400ミリ秒）。
エラーの予算：0。1％「エラーの余白」→フィクション/実験のルール。

• 'ALERT HighLatency'： 'p99 （http_server_duration_seconds{route="/pay"}）> 1s' 5'34。
• 'ALERT ErrorRate'のレート（http_requests_total{code=~"5.."}[5m]）/レート（http_requests_total[5m]）> 0。02`.
• サイロアラート（CPU/ディスク）-ページングなしで補助としてのみ。

7）信号の相関

メトリックは「赤」→例題をクリック→特定の'trace_id'→「遅い」スパンを見て→同じ'trace_id'でログを開きます。
リリースとの相関関係：属性'version'、 'image_sha'、 'feature_flag'。
data/ETL： 'dataset_urn'、 'run_id'、 lineageへのリンク（対応する記事を参照）。

8）サンプリングおよびカーディナリティ

メトリクス：ラベルを制限する（'user_id'、 'session_id'なし）；登録時のクォータ/検証。
トレース：head-sample（入力時）とtail-sample（コレクター時）を「5xx、 p99、 errors-100％」のルールと組み合わせます。
ログ：レベルとスロットリング；頻繁な繰り返しエラー-集計イベント（dedupeキー）。

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9）セキュリティとプライバシー

In Transit/At Rest：暗号化（TLS 1。3のAEAD、 KMS/HSM）。
PII/秘密：出荷前の消毒剤、トークン化、マスキング。
アクセス：読むべきABAC/RBAC；生産者/読者/管理者の役割の分離。
監査：ログ/トレースへのアクセスのログを変更しません。export-暗号化された形式で。
マルチテナンシー：名前空間/ポリシー付きテナントラベル；暗号化のキーの分離。

10）構成プロファイル（フラグメント）

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11） データ/ETLおよびストリーミング

データのSLI：鮮度（最大遅延）、完全性（行と期待）、「品質」（バリデータ/重複）。
アラート：ウィンドウのスキップ、消費者の遅れ、DLQの増加。
相関：'run_id'、 'dataset_urn'、 lineageイベント；パイプラインのトレース（バッチ/パーティションごとのスパン）。
Kafka/NATS：生産者/消費者指標、遅延/失敗；ヘッダーによるトレース（'traceparent'を含む）。

12）プロファイリングおよびeBPF（付加的な信号）

低レベルのホットパスCPU/alloc/IO；インシデントあたりのプロファイル。
eBPFテレメトリー（ネットワーク遅延、DNS、システムコール）は'trace_id '/PIDに関連付けられています。

13）観測性試験

「シグナル・コントラクト」（Signal Contract）-メトリック/ラベル/ヒストグラムのCIへのエクスポートをチェックします。
合成プローブ：外部SLI用のRUMシナリオ/シミュレートクライアント。
カオス/ファイアドリル：依存関係の無効化、劣化-アラートとアテンダントの反応を見てみましょう。
Prodのスモーク：デプロイ後、新しいエンドポイントにメトリクスとトレースがあることを確認します。

14）コストとボリュームコントロール

シグナル/コマンドによる予算；ダッシュボード「信号あたりのコスト」。
予算の下のカーディナリティ（カーディナリティのためのSLO）、新しいラベルの制限。
監査のためのダウンサンプリング、データクラスのプレゼンテーション、コールドアーカイブ、WORM。

15）観測プラットフォームの運用とSLO

プラットフォームSLO： 99。成功した摂取量の9％；メトリックインデックスへの遅延≤ 30秒、ログ≤ 2分、トレース≤ 1分。
プラットフォームアラート：注入の遅れ、低下の成長、署名/暗号化エラー、バッファオーバーフロー。
DR/HA：マルチエリア、レプリケーション、構成/ルールバックアップ。

16）チェックリスト

• どこでも'trace_id'/'span_id'がスローされます。JSONはダイアグラムでログを記録します。
• ヒストグラムを持つRED/USEメトリック；exemplar→alignmentを指定します。
• テールサンプリングが有効です。5xx/p99ルール=100％。
• 症状による警告+Runybooks；静かな時間/反折り返し。
• PII消毒剤；WORMを通過した状態で暗号化して監査を行います。
• ボリューム/カーディナリティのためのリテンションと予算。

• 毎月のアラートレビュー（ノイズ/精度）、チューニングしきい値。
• エラー予算レポートと取られたアクション（fichfreeze、硬化）。
• クリティカルパスのダッシュボード/ログ/トレースコーティングのチェック。
• トレーニングのインシデントとランブックの更新。

17） Runbook'

RCA： p99/pay rise

1.「チェックアウト」のREDダッシュボードを開きます。
2.例→スロートラック→「狭いスパン」を明らかにする（例：「ゲートウェイ」'）を呼び出します。
3.'trace_id'→ビュータイムアウト/リトレイでログを開きます。
4.ロールバック機能/RPS制限を有効にし、依存関係の所有者に通知します。
5.安定化後-RCA、最適化チケット、再生テスト。

1.SLI 「freshness」 red→track job→failing pitch。

2.ブローカー/DLQログ、コネクタエラーを確認します。

3.再処理を開始し、消費者（BI/製品）にステータスチャネルで通知します。

18）頻繁なエラー

'trace_id'なしでスキーマなしでログを記録します。調査は時に遅れます。
症状の代わりにインフラストラクチャに関する警告。ページングは「牛乳に」入ります。
メトリックの無限のカーディナリティ。コストの爆発と不安定性。
すべてのトラック100％。高価で不要です。スマートサンプリングを有効にします。
ログのPII/秘密。消毒剤と赤いリストが含まれています。
「ミュート」機能。メトリック/トレース/ログのない新しいコード。

19） FAQ

Q：ログの生のテキストを保存する必要がありますか？
A：はい、しかし保持およびアーカイブと；アラートやSLOでは、集計で十分です。監査-WORMで。

Q：トラックのために選ぶべき何-頭部か尾の見本抽出か？
A：結合：間違いおよび異常のためのbasecoat+tail規則のためのhead probabilistic。

Q：ユーザーメトリックとテクニカルメトリックをリンクするにはどうすればよいですか？
A：一般的な'trace_id'とビジネスラベル（'route'、 'tenant'、 'plan'）、およびトラックとの相関を持つ製品イベント（コンバージョン）を通じて。

Q：アラートで溺れないようにするには？
A：症状を打ち、アラートごとに静かな時間、重複排除、グループ化、SLO優先順位付け、所有者ごとにデフォルトで入力します。

• 「監査ログと不変ログ」
• 「In Transit/At Rest Encryption」
• 「秘密管理」
• 「データ起源（系統）」
• 「デザインによるプライバシー（GDPR）」
• 「Webhook配信保証」