可观察性堆栈

1）为什么需要观测堆栈

快速RCA和减少MTTR：从症状到原因在几分钟内。
SLO控制：测量错误/潜伏期,通过错误的预算进行排序。
发行控制：金丝雀布局，按指标自动回滚。
安全和审计：访问路线，异常，法律保留。
FinOps-Process：存储/查询成本，每次SLO成本。

方法：金色信号（latency/traffic/errors/saturation），RED，USE。

2）基本堆栈架构

按图层分组的组件

收集/代理：Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes。

Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.

存储：对象S3/GCS/MinIO（长期寒冷），SSD（热排）。
查询/可视化：Grafana（面板，SLO小部件），Kibana（如果ELK）。
管理：Alertmanager/Grafana-alerta，服务目录，RBAC，秘密经理。

部署模式

托管（Grafana Cloud/云服务）-在数量上快速而昂贵。
自我托管在K8s-完全控制，需要操作和FinOps。

3）数据标准： 单一"可观察性方案"

3.1个指标（Prometheus/OpenMetrics）

强制性标签是："env"，"region"，"cluster"，"namespace"，"service"，"version"，"tenant"（如果是多特南特），"endpoint"。
命名："snake_case"，后缀"_total"，"_seconds"，"_bytes"。
直方图：固定的"buckets"（SLO定向）。
基数：不在标签中包含"user_id"、"request_id"。

3.2 Logi

格式：JSON；必填字段"ts"、"level"、"service"、"env"、"trace_id"、"span_id"、"msg"。
PII：掩盖代理（PAN、令牌、电子邮件等）。
Loki标签：只有低基数（"app"，"namespace"，"level"，"tenant"）。

3.3条赛道

OTel语义： '服务。name`, `deployment.environment`, `db.system`, `http.`.

Sampling：p99的目标路径是"always_on"/tail-sampling，其余路径是"parent/ratio"。
嵌入ID：将"trace_id/span_id"推入日志和度量（labels/fields）。

4）M-L-T相关性（Metrics/Logs/Traces）

从Alert图形（度量）→，"trace_id"上的过滤逻辑→特定的路径。
从轨道（慢速span）→调用span间隔上的特定后端指标。
面板中的Drilldown按钮是："到日志"和"到轨道"，并带有变量替换（"$env"，"$service"，"$trace_id"）。

5） OpenTelemetry Collector： 参考管线

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6） Alerting： SLO和多烧伤

想法是：alertim不在"CPU> 80%"的水平，而是在Error Budget的消费上。

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

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

7） Dashbords： 文件夹结构

00_Overview平台：SLO, p95, 5xx%, capacity,活动事件。
10_Services服务：RPS，p95/p99，错误，版本（注释）。
20_Infra-K8s/nods/storage/网络，etcd，控制器。

30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.

40_Edge/DNS/CDN/WAF-ingress, LB, WAF规则。
50_Synthetic是药房和无头脚本。
60_Cost/FinOps-存储，查询，热/冷，预测。

每个面板：说明,单位,所有者,运行手册链接,drilldown。

8） Logi： LogQL讲习班

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9）轨道： TraceQL和焦点

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10）合成和制药

Blackbox-exporter：来自≥3 个区域/ASN的HTTP/TCP/TLS/DNS样本。
Headless： 登录/deposit脚本按计划。
Quorum-alerts：如果≥2地区看到故障,则触发。
状态页面：自动更新+手动评论。

11）存储和重构

度量标准：热7天至30天（快速行）、降低/记录规则、冷-对象存储（月）。
Logs：热3-7天，然后是索引S3/GCS（Loki chunk store/ELK ILM）。
路线：3-7天"always_on"+长期存储样本（tail-sampled/check）。

• Rollover的大小和时间；请求预算（配额/限额）。
• prod/stage和安全数据的单独策略。

12）多重性和可用性

按"tenant"/"namespace"/Spaces，索引模式和分辨率划分。
对计费资源进行标记："tenant"、"service"、"team"。
进口dashbords/alerta-在特定命令的空间中。

13）安全和合规性

从代理商到bekends的TLS/mTLS，用于私人健康的HMAC。
RBAC用于阅读/写入，审核所有请求和差异。

边缘的PII修订版；禁止登录中的秘密；DSAR/Legal Hold.

隔离：敏感域的单个群集/neyspace。

14） FinOps： 可观测性的成本

我们降低了ingest（而不是查询）中的标签基数和逻辑。
Sampling Trass+针对关键路径的目标前进。
用于重聚的downsampling/recording规则。
将罕见的访问归档到冷对象。

Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15） CI/CD和可观察性测试

放大CI中的指标/标志：禁止基数"爆炸"，检查直方图/单位。
可观察性合同测试：中间件中的"trace_id"强制性指标/逻辑字段。
金丝雀：图上发布的注释,SLO-auto-rollback。

16）示例： 快速查询

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

CPU throttling:

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

Kafka lag:

promql max by (topic, group) (kafka_consumergroup_lag)

从日志到轨道（Loki → Tempo）：在Tempo UI/dashboard上传输"trace_id"作为链接。

17）堆栈质量： 支票清单

• 统一指标/标志/轨迹图和度量单位。
• "trace_id"在日志和度量标准中，从面板中删除。
• Multi-burn SLO-alerta无翻转（quorum/multi-window）。
• Downsampling、查询配额、步骤/范围限制。
• 重建和存储类已记录并应用。
• RBAC/审计/PII修订版包括在内。
• Dashbords：所有者,runbooks, ≤2 -3屏幕,快速响应。
• FinOps-dashbord（体积、成本、顶级对话者）。

18）实施计划（3次迭代）

1.MVP（2周）：Prometheus→Mimir，Loki，Tempo；OTel Collector;基本的dashbords和SLO-alerta；blackbox样本。
2.尺度（3-4周）：tail-sampling，downsampling，多区域ingest，RBAC/Spaces，FinOps-dashbords。
3.Pro （4周以上）：通过SLO、无头关键路径合成、Legal Hold、SLO产品组合和报告自动回滚。

19）反模式

"没有SLO的美丽图形"-没有动作→没有好处。
高基数标签（"user_id"，"request_id"）是内存和成本的爆炸。
没有JSON且没有"trace_id"的日志没有相关性。
根据资源而不是症状，Alerts是噪音和呼唤倦怠。
缺乏重组政策是成本的不受控制的增长。

20）迷你常见问题

选择什么： Loki或ELK?

ELK用于复杂的搜索/面板；对于类似于grep的场景,Loki更便宜、更快。他们经常使用混合动力车。

每个人都需要赛道吗？
是的，至少在带有尾部采样的关键路径（登录，检查，支付）上-这大大加快了RCA。

如何从头开始？
OTel Collector → Mimir/Loki/Tempo →基本的SLO和blackbox样本→然后是行车记录仪和burn-alerta。

底线

可观察性堆栈不是一组不同的工具，而是一致的系统：统一的数据标准→ M-L-T相关性→ SLO对等和合成→安全性和FinOps。记录电路、标签纪律和续集，连接OTel，添加滚动和自动滚动-并获得可管理的可靠性，成本可理解。