收集指标：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和长期存储、版本注释以及自动回滚集成-并且您可以快速、可扩展且经济高效的指标轮廓,从而帮助您做出销售决策。