可观测性建设路线图

使用方式

可观测性不是“装一套 Prometheus + Grafana”就结束，而是让团队在故障发生时能快速回答三个问题：哪里坏了、影响多大、为什么。按“指标 → 日志 → 链路 → 剖析 → SLO”的顺序建设，每一阶段都要有明确的使用场景和负责人。

先覆盖核心业务和关键依赖，再扩展到长尾服务；先保证数据可用，再追求全量和高级分析。

检查清单

阶段 1：基础指标

• 节点、容器、Kubernetes 控制面指标已采集。
• 核心业务有请求量、错误率、延迟和饱和度指标。
• 指标有统一标签规范（service、env、cluster、version）。
• Prometheus 有保留周期、远程存储和容量规划。
• Grafana 有分层看板：集群、命名空间、服务、实例。

阶段 2：日志

• 应用日志结构化（JSON），包含 trace_id、request_id。
• 日志采集覆盖容器、节点和关键中间件。
• 日志有保留周期、索引策略和成本控制。
• 敏感字段脱敏，访问有权限控制。
• 常见错误有可检索的聚合视图。

阶段 3：链路追踪

• 核心服务接入 OpenTelemetry SDK 或自动注入。
• trace 上下文跨 HTTP、gRPC、消息队列传递。
• 采样策略兼顾成本和排障需求。
• Jaeger/Tempo 能按 trace_id 关联日志和指标。
• 慢请求能定位到具体 span 和下游依赖。

阶段 4：性能剖析

• 关键服务支持持续 profiling（Pyroscope/Parca）。
• 能按 CPU、内存、锁和 IO 定位热点。
• profiling 开销和采样频率可控。
• 发布前后能对比性能剖面。

阶段 5：SLO 与告警

• 每个核心服务有 SLI 定义和 SLO 目标。
• 告警基于症状而不是原因，分级明确。
• 告警有去重、静默、升级和值班路径。
• 错误预算消耗有看板和复盘机制。
• 定期清理无效告警和低价值看板。

阶段 6：成本与治理

• 指标、日志、trace 的存储成本可分摊。
• 高基数标签和日志被识别并治理。
• 数据保留策略符合合规要求。
• 可观测性平台自身有高可用和备份。

常见误区

• 先买平台后定规范，导致标签混乱、数据无法关联。
• 只做指标不做日志和链路，故障时只能看到“坏了”但不知道“为什么”。
• 日志全量采集且永久保留，成本失控。
• 告警按原因配置，阈值一改再改，仍然误报。
• 没有 SLO，团队无法判断故障优先级和投入产出。
• 可观测性平台本身没有监控，故障时一起失联。

相关条目

• prometheus、grafana、alertmanager、thanos
• loki、fluent-bit、vector、logcli
• opentelemetry、jaeger、tempo
• pyroscope、parca、async-profiler、py-spy
• promql-cheatsheet、promtool
• build-observability-stack、build-prometheus-ha、build-loki-ha