メトリックコレクション：Prometheus、 Grafana

メトリックコレクション： Prometheus、 Grafana

1）目的およびフレーム

メトリックループのタスクは、確実に時系列を収集して保存し、RCA、 SLOアラート、わかりやすいダッシュボードのための高速なPromQLを与えることです。基本ペア：Prometheus（スクレイプ→ストア→クエリ）とGrafana（ビジュアライゼーション、アラート、リリースアノテーション）。長いストレージとグローバルクエリの場合-Thanos/Cortex/Mimir。

2）データモデルとセマンティクス

シリーズ=メトリック名+ラベルのセット（key=value）。
タイプ：カウンター、ゲージ、ヒストグラム、要約（prod-より頻繁にヒストグラム）。

• RED （API）： 'rate'、 'errors'、' duration'（ヒストグラム）。
• ［使用］：使用率、彩度、エラー（CPU/RAM/ディスク/ネット）。
• 命名：'namespace_subsystem_metric_unit'（例：'http_server_requests_total'、 'db_connections_current'）。

アンチカーディナリティ：異なるラベル値を最小限に抑えます（ラベルにuser_id request_idはありません）。

3）露出およびサービス発見

輸出者：node_exporter、 kube-state-metrics、 cAdvisor、 DB/Queues （postgres_exporter、 redis_exporter、 kafka_exporter)。
ネイティブサービス：クライアントライブラリ（Go/Java/Node/Python）→'/metrics'。
Service Discovery： Kubernetes、 EC2/ASG、 Consul、静的ファイル。

yaml global:
scrape_interval: 15s evaluation_interval: 15s scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs: [{ role: node }]
relabel_configs:
- action: labelmap regex: __meta_kubernetes_node_label_(.+)
- job_name: 'apps'
kubernetes_sd_configs: [{ role: pod }]
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+)
replacement: $1

yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4）ヒストグラムとレイテンシー

• Web/API： '10ms、 25,50,100,200,400,800,1600'
• 支払い/支払い：5-10秒にテールを追加します。

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5）録音ルール

重い要求を減らし、SLIを標準化します。

yaml groups:
- name: api_sli interval: 30s rules:
- record: job:http:success_ratio:rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:http:duration_p95:5m expr: histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6） SLOおよび警報（複数の窓の焼跡）

SLO 99。9％成功したRequests/30d。

yaml groups:
- name: slo_burn rules:
- alert: ErrorBudgetBurnHighShort expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 14 for: 5m labels: { severity: critical }
annotations: { summary: "Fast burn >14x for 5m" }

- alert: ErrorBudgetBurnHighLong expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 6 for: 1h labels: { severity: critical }
annotations: { summary: "Long burn >6x for 1h" }

yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7）ラベル衛生および経済

ラベル名は安定して標準化されています：'service'、 'env'、 'region'、 'route'、 'code'、 'version'。
Limit cardinality： 'route'のメトリックは'http'パターンを使用する必要があります。route'（完全なURLではありません）。
ロジックサンプリング-トレースで；メトリクス-user_idなし。
リリースプロパティ（'service。version'）は古いバージョンや新しいバージョンを比較するのに便利です。

8）スケーリングとHA

• 2つのプロメテウス（A/B）が同じターゲットをスクレイプします（HA→アラートが複製されます）。
• Thanos：各PrometheusへのSidecar、グローバルクエリと長期ストレージ（S3/GCS）のためのStore+Query。
• 代替：Cortex/Mimir（リモート書き込み、マルチテナンシー、水平スケーリング）。

yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }

yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9） Grafana： ダッシュボード、アラート、注釈

1.プラットフォームの概要（SLO/RED、 error-budget）。

2.RouteによるAPI （RPS/5xx/p95、比較'バージョン'）。

3.K8sクラスタ/ノード（コントロールプレーン、彩度）

4.DB/キャッシュ/キュー （lag/locks/hit ratio/backlog）

5.Per-Release （before/after、 CIからアノテーションをリリース）。

Grafanaアラート：PromQLでトリガーします。、通話中の回転、ミュート時「リリースウィンドウ」。

注釈：CIは'commit'、 'imageを持つリリースイベントを追加します。tag'、パイプラインへの参照。

10） Kubernetes： 何を測定するか

Control-plane： 'apiserver_request_total'、 etcd leader/fsync、スケジューラ待ち時間。
ワークロード：再起動、'container_cpu_cfs_throttled_seconds_total'、 OOM、保留中/Evicted、 PDB違反。
ネットワーク：ドロップ、conntrack、 'kube-proxy'エラー。
クォータ/リミット：リクエストとリミット、HPA/VPA、ノード飽和。

11） DB/キャッシュ/キュー： キー信号

PostgreSQL/MySQL： 'connections'、 'locks'、 'deadlocks_total'、 'xact_commit/rollback'、レプリケーションラグ。
Redis：ヒット比、'evictions'、レイテンシ'instantaneous_ops_per_sec'。
Kafka/RabbitMQ：消費者の遅れ、unacked、 ISR、ディスク使用量。

promql
Queue backlog sum by (topic) (kafka_consumergroup_lag)> 1000

Postgres replication lag max(pg_replication_lag_seconds) > 2

12）安全および複数のテナント

Prometheus/GrafanaへのRBAC、 datasource-permishens。
ingress/betweenコンポーネントのTLS/mTLSチェーン。
テナントの分離：Cortex/Mimirの独立したPrometheusまたはテナントラベル；シリーズおよび要求の限界。
アラート/通知の秘密-禁止（PIIではなくチケットIDを使用）。

13）リリースおよび自動ロールバックとの統合

SLOルール→AnalysisTemplate （Argo Rollouts）またはCI-gate。
バーンアラートがトリガーされると-pause/rollback canary；log/annotation-リリースへのリンク。
ラベル'version'による安定版とカナリア版の比較。

14）典型的なエラー（アンチパターン）

ラベルの制御されていないカーディナリティ（user_id、 URL。完全な、動的キー）。
'env'ラベルなしで同じクラスタでprodとstageをミックスします。
RED/USEのないゲージだけ；p95/p99ヒストグラムなし。
SLO→noiseにバインドせずにハードウェア上のアラート。
生産インシデントでの録音ルールの欠如→「重い」要求。
リリースアノテーションがない→変更や劣化を比較するのが難しい。

15）実装チェックリスト（0-45日）

0-10日

ノード/kube-state/cAdvisorエクスポート;サービス内の'/metrics'

基本的なRED/USEダッシュボード;標準的なヒストグラムのバケツ。
CIからのリリースアノテーションを含める。

11-25日

SLIのための記録規則；マルチウィンドウバーンアラート。
HA Prometheus（ダブルスクレイプ）、GitOps設定のバックアップ。
Alertmanager： routes/quiet mode/on-callローテーション。

26-45日

Thanos/Cortex/Mimirの長期貯蔵のリモート・ライト。
カーディナリティの最適化、シリーズ制限、要求。
SLOゲートリリースと自動ロールバック統合。

16）成熟度の指標

主なサービスのRED/USEカバレッジ≥ 95％です。
「heavy」 PromQLを実行する平均時間<2 s （p95）レコーディングルールによる。
有用な/騒々しい警報の比率は>3：1です。
Cardinality under control：クラスタごとの<10Mアクティブバッチ、スパイクなし。
Grafanaでは100％のリリースが注釈され、前後の相関メトリックが表示されます。

17）便利なスニペット

バージョン別の安定性とカナリア比較

promql histogram_quantile(0. 95,
sum by (le, version) (rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m]))
)

ルートによる5xxエラー

promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)

コンテナCPU彩度

promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1

トラックとのメトリクス関係（Exemplars有効）

promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track

18）結論

Prometheus+Grafanaは、メトリクスのデファクトスタンダードです。意味論と規律の勝利：RED/USE、きちんとしたラベル、SLOのヒストグラム、レコーディングルール、SLOアラート。HAと長期的なストレージ、リリースアノテーション、自動ロールバックとの統合を追加します。また、迅速でスケーラブルで経済的なメトリックループがあり、販売における意思決定を支援します。