收集指標：Prometheus, Grafana

收集指標： Prometheus, Grafana

1）目標和框架

度量回路的任務是可靠地收集和存儲時間序列，為RCA提供快速PromQL，SLO上的差分和可理解的行。基本對：Prometheus（scrape → store → query）和Grafana（可視化，alerta，發行註釋）。對於長存儲和全局查詢-Thanos/Cortex/Mimir。

2）數據模型和語義

系列=度量名稱+標簽集（鍵=值）。
類型：counter，gauge，histogram，summary（在銷售中-通常是histogram）。

• RED （API）： 「rate」、「errors」、「duration」（直方圖）。
• USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
• 命名：'namespace_subsystem_metric_unit'（例如'http_server_requests_total'、'db_connections_current'）。

反基數：盡量減少標簽的不同值（標簽中沒有request_id user_id）。

3）展覽和發現服務

出口商：node_exporter, kube-state-metrics, cAdvisor, DB/Forges （postgres_exporter, redis_exporter, kafka_exporter)。
專有服務：客戶端庫（Go/Java/Node/Python）→ '/metrics'。

Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

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：［10 ms, 25.50.00.00.400.8600］］
• 付款/付款：添加最多5-10 s的尾巴。

PromQL p95:

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和Alertes（多窗口燒傷）

SLO 99.9% 的成功查詢/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）標簽衛生和節省

標簽名稱穩定且標準化：「服務」，「env」，「region」，「route」，「code」和「version」。
限制基數：帶有「路線」的度量標準必須使用模板的http。路線'（不是完整的URL）。
Sampling邏輯-在預告片中；在指標中-沒有user_id。
發布屬性（'service。版本"）對於比較舊/新版本很有用。

8）擴展和HA

• 兩個Prometheus（A/B）剪切相同的目標（HA → alertes重復）。
• Thanos： Sidecar to ever Prometheus, Store+Query for Global查詢和長期存儲（S3/GCS）。
• 備選方案：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： dashbords, Alerts,註釋

1.Platform Overview (SLO/RED, error-budget).

2.Route API（RPS/5xx/p95，「版本」比較）。

3.K8s Cluster/Nodes (control-plane, saturation).

4.DB/Cache/Queues (lag/locks/hit ratio/backlog).

5.Per-Release（前/後，CI版本註釋）。

Grafana Alerting：在PromQL、呼叫旋轉、靜音時間「發布窗口」上觸發。

註釋：CI用「commit」，「image」添加了發布事件。標記,引用管道。

10）Kubernetes： 一定要衡量什麼

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.

Workloads：重新啟動,「container_cpu_cfs_throttled_seconds_total」, OOM, Pending/Evicted, PDB違規。
網絡：drops，conntrack，「kube-proxy」錯誤。
配額/限制：要求vs限制，HPA/VPA，節點設置。

11） DB/緩存/隊列： 關鍵信號

PostgreSQL/MySQL: `connections`, `locks`, `deadlocks_total`, `xact_commit/rollback`, replication lag.

Redis: hit ratio, `evictions`, latency `instantaneous_ops_per_sec`.

Kafka/RabbitMQ: consumer lag, unacked, ISR, disk usage.

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

Postgres replication lag max(pg_replication_lag_seconds) > 2

12）安全性和多重性

RBAC到Prometheus/Grafana，datasource-permishens。
ingress/組件之間的 TLS/mTLS鏈。
租戶隔離：Cortex/Mimir中單獨的Prometheus或tenant標簽；系列限制和查詢。
Alert/notification中的秘密-禁止（使用ID tiket而不是PII）。

13）與發行版和自動回滾集成

SLO規則→ AnalysisTemplate （Argo Rollouts）或CI-gate。
觸發burn-alert時，pause/rollback canary；在日誌/註釋中-版本鏈接。
通過標簽「版本」比較穩定版本和金絲雀版本。

14）典型錯誤（反模式）

標簽的失控基數（user_id，url。滿,動態鍵）。
在沒有「env」標簽的單個群集中混合prod和stage。
只有沒有RED/USE的gauge；沒有p95/p99直方圖。
Alerta在「鐵」上沒有參考SLO →噪音。
缺乏記錄規則→了「嚴重」的程序事件查詢。
沒有版本註釋→很難匹配更改和降級。

15）實施清單（0-45天）

0-10天

Node/kube-state/cAdvisor出口商；服務中的'/metrics'。
基本的RED/USE dashbords；標準直方圖罐。
啟用CI版本註釋。

11-25天

為SLI錄制規則；多窗口燃燒的艾萊塔。
HA Prometheus（雙scrape），GitOps configs的備份。
Alertmanager：路線/安靜模式/呼叫旋轉。

26-45天

遠程寫入Thanos/Cortex/Mimir，長期存儲。
基數優化，系列限制，查詢。
SLO登錄版本和自動滾回集成。

16）成熟度量

關鍵服務的RED/USE覆蓋率≥ 95％。
「重」PromQL的平均運行時間<2 c（p95），以犧牲記錄規則為代價。
有用/嘈雜的變量比>3：1。
控制下的基數：<每集群10 M活動序列,沒有爆發。
100％的發行版在Grafana中具有註釋，並在之前/之後具有度量映射。

17）有用的嗅探

stable vs canary按版本比較

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-Alerta。添加了HA和長期存儲、版本註釋以及自動回滾集成-並且您可以快速、可擴展且經濟高效的指標輪廓,從而幫助您做出銷售決策。