シグナルとメトリックの分布

（セクション： エコシステムとネットワーク）

1）目的とエリア

• 統一されたテレメトリー言語とデータ契約。
• 管理されたQoSチャネル：重要な信号の優先度。
• 透明なSLI/SLOと予測可能なアラート。
• プライバシー、分離、予算削減の指標。

2）シグナルタクソノミ

1.ビジネスイベント：オンボーディング、預金/支払い、ゲームイベント、アトリビューション。
2.技術指標：レイテンシ/スループット/エラーコード、キュー、CPU/RAM/IOの使用。
3.ログ：操作とエラーに関する構造化されたエントリ。
4.トレース：クエリ/トピックのスパン、ホップ間の相関。
5.健康状態：合成プローブ、準備/生活、ハートビートノード。
6.リスク/コンプライアンス信号：KYC/KYB/AMLヒット、制裁イベント。

各クラスには、独自のクリティカルレベルとストレージ/デリバリーポリシーがあります。

3）配布アーキテクチャ（参考）

エッジコレクタ（SDK/エージェント）→Ingress （HTTP/OTLP/gRPC/QUIC）→バス（Kafka/Pulsar）→プロセッサ（ストリームジョブ）→ストレージ（メトリック、オブジェクト/列-ログ/イベント、tracer）→ショーケース/ダッシュボード/アラート。
マルチテナンシー：名前空間/キーのテナントID、個々のクォータ/リミット/ACL。
QoSセグメンテーション：クリティカル（P0）、重要（P1）、背景（P2）。
Egress：トピックやマテリアライズされたビューへのサブスクリプションを通じて加入者（Ops/BI/サードパーティ）。

4）契約とスキーム（イベント/メトリック/トレイル）

4.1イベント（簡略化、YAML）

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4.2メトリック（OpenMetrics/OTLP）

安定したラベルが付いているゲージ/カウンター/ヒストグラム（限られたcardinality）。
識別子：'metric_name {service、 region、 tenant、 version、 route}'。
コード中のp99ではなくレイテンシ/寸法のヒストグラム。

4.3つのトレイル

必須フィールドは'trace_id'、 'span_id'、 'parent_id'、 'service'、 'peer'、 'route'、 'qos'です。
ドメイン（消費者/生産者）とネットワークホップ（リレー/ブリッジ）の間のリンク。

5） QoSと優先順位付け

P0（クリティカル）：SLI支払い/支払い、ブリッジ/ノードのステータス、バーンレートSLO→厳密な配信（acks、 retries、 idempotency）、最小タイムアウト。
P1（重要）：プロダクトイベント/キーメトリック→SLO内での保証配信。
P2（背景）：詳細なログ、デバッグ→ベストエフォート、オーバーロード時にドロップできます。

政治家：「idempotency_key」による異なるキュー、生産者のクォータ、バックプレッシャー、レート制限、祖父。

6）カーディナリティとメトリクスの予算

ルール6ラベル：メトリックあたり6キー以下、値の固定辞書。
Cardinality ≤ 10k時系列/メートル/テナント。
サンプリング：トレースのヘッド/テールベース。ダウンサンプリング10s→1m→5m→1hのメトリック。
クォータ：1テントあたりとQoSクラスあたりのポイント/秒とバイト/秒の制限。
Linterスキーム：「exploding」ラベル（id、 email、 ipなど）でメトリックを拒否します。

7）集め、渡して下さい： プッシュ対プル

プッシュ（OTLP/StatsD/HTTP）：柔軟性、モバイル/エッジクライアント、P0チャンネル。
プル（Prometheus）：内部インフラストラクチャ、予測可能なターゲット。
ハイブリッド：輸出業者→ゲートウェイ→TSDB；地域のための連合されたスクレイプ。
輸送：QUIC/HTTP/2、圧縮、バッチング、TLS/mTLS、ジッタ付きレトライ。

8） SLI/SLOおよび警報

8.1基本的なSLI

可用性％エンドポイント/ゲートウェイ、

重要なルートのレイテンシp50/p95/p99、

エラー率（5xx/timeout/abort）、

バスによる配達遅れ、キューの深さ、

ショップウィンドウの鮮度（ingest→serve delay）。

8.2 SLOの例

P0パイプライン：可用性≥ 99。95％、 p99レイテンシー≤ 400ミリ、配信遅延P95 ≤ 2ミリ。
P1：空室状況≥ 99。9％、鮮度p95 ≤ 3分。
P2： Freshness P95 ≤ 15ページなし。

8.3バーンレートアラート（例）

2時間ウィンドウ：'error_budget_burn ≥ 2 ×'→ページ。
6時間ウィンドウ：'error_budget_burn ≥ 1 ×'→ページ/エスカレーション。
'queue_lag'と'drop_rate' P0と組み合わせます。

9）保管庫および保管

TSDBメトリクス： 高周波-7-14日；集計-6〜12ヶ月

イベント/ログ：ホットストレージ7-30日、コールド（オブジェクト）6-24ヶ月。
トレイル：サンプリング1-10％；「slow/erroneous」スパン（テールベース）を保存します。
PIIおよびデータ主体要求の削除/リビジョンポリシー。

10）プライバシー、セキュリティ、分離

PII最小化：フィールドのトークン化/仮名化、メトリック内の「生」識別子の禁止。
mTLS/event signatures、 producer key pinning。
トピック/サービス/テナントのACL/ABAC、書き込み/読み取りのための別のキー。
テナントのサンドボックス化：テナントごとの論理的/物理的分離、制限、レート制限。
監査証跡：設定へのアクセス/変更のログを変更しません。

11）処理ストリーム（ストリームジョブ）

Enrich：正規化、geo/version/trafficクラス。
集計：窓10s/1m/5m、ヒストグラム、量子スケッチ。
検出：異常（EWMA/ESD）、分布のドリフト、キューのバースト。
ルート：/alert/webhooksパートナーを紹介するファンアウト。
ガード：「赤いボタン」-ソース/トピックによるスロットリング/キルスイッチ。

12）ダッシュボード（参照レイアウト）

Ops Core（時間/リアルタイム）：p95レイテンシ、エラー率、配信遅延、キューの深さ、成功率のインジェスト。
パイプラインの健康：パイプラインごとの新鮮さ、低下率、背圧、燃焼率のSLO。
テナントの使用法：行/秒、バイト/秒、カーディナリティ、トップラベル。
セキュリティ/コンプライアンス：mTLSステータス、有効期限キー、アクセス、PIIリビジョン。
Business Lens： コンバージョン/ペイアウト/ブリッジSLI。

13）構成例

QoSクラスと制限（YAML）

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

メトリックラベル（政治）

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

アラートバーンレート

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14）データスキーマとクエリ

メトリックレジスタ（ディレクトリ）

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

キューとラグ

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

テントカーディナリティ

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15）プロセスと役割

テレメトリーオーナー-スキーム/ポリシー/クォータ、カーディナリティコントロール。
SRE/Ops-SLO、アラート、インシデント、スケーリング。
セキュリティ/コンプライアンス-キー、アクセス、PII、監査。
製品/BI-KPIは、分析、A/B指標を紹介します。
テナント（パートナー）-正しいSDK統合、契約コンプライアンス。

16） Playbookインシデント

A。カーディナリティの爆発

1.自動ブロックプロデューサー/メトリクス、2）「悪い」ラベルを切り取る、3）レトロな集約、4）死後とリンタールール。

B。キューラグの上昇P0

1.優先順位、2）パーティー/消費者の拡大、3）一時的にP2サンプリングを削減、4）ボトルネック分析。

C。 Freshness Storefrontsの秋

1.バックアップコネクタに切り替え、2）劣化モードをオンにします（「最終確定」）、3）ソースの所有者に通知します。

D。 PIIのメトリクス漏洩

1.即時フローブロッキング、2）ホットレイヤでの再現、3） DPO/コンプライアンス通知、4） レンター/SDKアップデート。

E。 Massive 5xx/トレースエラー

1.Page、 2） tail-based sampling> for errors、 3） critical route trace diagnostics、 4） release rollback/featureフラグ。

17）実装チェックリスト

1.イベント/メトリック/トレースコントラクトと許容ラベルのリストを承認します。
2.QoSクラス、トピック/キュー、クォータ、メトリクス予算を作成します。
3.ingest （push/pull）、 TLS/mTLS、 retrai、 idempotencyを設定します。
4.メトリクス/イベントディレクトリとスキーマリンタを含める。
5.SLI/SLO、バーンレートアラート、エスカレーションを定義します。
6.ダッシュボードの作成Ops/Pipelines/Tenant/Security。
7.テレメトリーカオステスト（損失/ジッタ/接着）を実行します。
8.定期的にカーディナリティ、保持および保管コストを見直します。

18）用語集

QoS-配信品質/優先度クラス。
鮮度-ショーケース内のデータの出現の遅れ。
バーンレート-SLOに対するエラー予算消費率。
Cardinality-メトリックの一意の行の数（ラベルの組み合わせ）。
テールベースのサンプリング-「遅い/誤った」トレースの選択。
Idempotency key-イベントの繰り返し重複除外のキー。

ボトムライン：信号とメトリクスの分布は、単に「グラフを収集して表示する」だけでなく、契約、QoSチャネル、予算の規律です。このフレームワークに従うことで、エコシステムは予測可能な観測性、サージ耐性、データプライベート性を獲得し、運用およびビジネスの両面での意思決定に役立ちます。