可观测性

概述 你有没有遇到过这种情况：用户反馈"系统好卡"，你打开 Grafana 看了一堆面板，CPU 正常、内存正常、网络也正常，但用户就是说慢。这时候你需要的不是更多的指标面板，而是一条完整的请求链路——从用户点下按钮到数据库返回结果，每一跳花了多少时间，卡在哪一步。 这就是 APM（Application Performance Monitoring，应用性能监控）干的事。 简单说：日志告诉你发生了什么，指标告诉你系统是否健康，APM 告诉你为什么慢、慢在哪里、影响了谁。三者各管一摊，缺一不可。 本文从实际选型角度出发，拆解主流开源和商业 APM 工具的架构差异、适用场景和坑点。不吹不黑，每家都有适合的场景，关键看你的团队规模、技术栈和预算。 APM 要解决什么问题 先说清楚为什么需要 APM，而不是直接跳到工具对比。 微服务架构下的"链路黑盒" 单体应用时代，一个请求从入口到数据库都在一个进程里完成，打个断点就能调试。微服务拆分后，一个用户请求可能经过 API 网关 → 认证服务 → 订单服务 → 支付服务 → 消息队列 → 库存服务 → 数据库，中间还穿插着 Redis 缓存和第三方 API 调用。 任何一个环节变慢，整体就慢。但你看日志只能看到单个服务的视角，没法把整条链路串起来。这就像你在医院看病，内科查完说没问题让你去外科，外科查完说没问题让你去骨科——每个科室都说自己没问题，但你就是难受。APM 就是那个能把你所有科室检查结果串起来看的"全科医生"。 APM 的三个核心能力 能力 解决什么问题 类比 分布式追踪（Distributed Tracing） 一个请求经过哪些服务、每跳花了多久 快递物流追踪，每个中转站都有时间戳 性能剖析（Profiling） 某个函数执行慢，CPU 花在哪了 体检报告，精确到每个器官的指标 错误追踪（Error Tracking） 异常发生在哪个服务的哪行代码 车辆故障码，直接定位到故障部件 分布式追踪是 APM 最核心的能力。它通过在请求入口生成一个唯一的 Trace ID，然后通过 HTTP Header 或 RPC 上下文传递到下游服务，每个服务在自己的处理过程中记录一个 Span（你可以理解为链路上的一个节点），最终拼出完整的调用树。 关键概念速览 术语 含义 说明 Trace 一次完整的请求链路 由多个 Span 组成的有向无环图（DAG） Span 链路上的一个操作节点 包含操作名、起止时间、标签、日志 Context Propagation 上下文传递 Trace ID 通过 HTTP Header 在服务间传递 Sampling 采样 不可能记录所有请求，按策略采样部分 Instrumentation 探针/埋点 代码层面自动或手动注入追踪逻辑 采样策略很关键。线上流量大的时候，全量记录 Trace 会把存储和 CPU 吃干。常见做法是头部采样（Head-based Sampling）——在请求入口决定是否记录，要么整条链路全记，要么全不记。尾部采样（Tail-based Sampling）更精细——在链路结束时根据条件（比如耗时超过阈值、出现错误）决定是否保留，但实现复杂度高，需要中间层缓存完整链路。...

概述 先说个场景：凌晨三点，你被告警吵醒，爬起来打开 Grafana，发现几十个 Dashboard 里找不到一条有用的信息。指标倒是有几百万条——但全是垃圾。 这不是个例。我见过太多团队，Prometheus 部署完就不管了，指标只增不减，告警规则越写越多，最后监控系统自己先挂了：Prometheus 内存 OOM、查询超时 30 秒、告警评估延迟 5 分钟以上。监控系统成了最大的故障源，这话说出去都讽刺。 监控数据治理解决的就是这个问题。它不是什么高深理论，说白了就一句话：搞清楚你有哪些指标、哪些有用、哪些该删、怎么管它们的一生。 这篇文章从指标生命周期管理的角度，拆解监控数据治理的五个阶段：指标定义、采集策略、存储优化、质量度量、废弃淘汰。每个阶段都配实操代码和踩坑经验。 指标爆炸的根因：不是数据多了，是管不住 指标为什么会膨胀 指标膨胀不是一夜之间发生的。通常的路径是这样的： 初期：Node Exporter + cAdvisor，几百条指标，Prometheus 跑得好好的 业务接入：每个服务埋点，每个中间件装 Exporter，指标涨到几万条 高基数炸弹：有人把 user_id、request_id、session_id 塞进了标签，时序数据量从几万条直接爆炸到百万级 灾难：Prometheus 内存飙升、磁盘写满、查询卡死 这里的核心罪魁祸首是高基数标签。 Prometheus 的时间序列模型是：指标名{标签1="值1", 标签2="值2"} → 数值。每增加一个标签值组合，就多一条时间序列。举个例子： # 低基数：3 条时间序列 http_requests_total{method="GET",status="200"} http_requests_total{method="POST",status="200"} http_requests_total{method="GET",status="404"} # 高基数炸弹：100万用户 = 100万条时间序列 http_requests_total{method="GET",status="200",user_id="12345"} http_requests_total{method="GET",status="200",user_id="12346"} ... 第二行代码看起来人畜无害，但如果 user_id 有 100 万个值，就是 100 万条时间序列。Prometheus 单实例承载上限大约 50 万条 TimeSeries（受内存和磁盘 I/O 约束），直接超限。 高基数标签的常见来源 来源 典型场景 危害程度 替代方案 用户 ID http_requests_total{user_id="..."} 致命 用日志记录，或聚合为百分位 请求 ID http_request_duration{trace_id="....

概述 在现代微服务架构中，一个看似简单的用户请求可能穿越数十个服务节点。当故障发生时，SRE 工程师面对的第一个问题往往不是"怎么修"，而是"影响范围有多大"。如果无法快速回答这个问题，故障恢复就会被拖延在无休止的排查中。 服务依赖地图（Service Dependency Map）和故障域分析（Failure Domain Analysis）是解决这一问题的工程方法论。前者解决"谁依赖谁、怎么依赖"的认知问题，后者解决"故障会扩散到哪、爆炸半径多大"的控制问题。两者结合，构成了 SRE 可靠性工程的基础设施。 从依赖拓扑的发现方法出发，深入分析故障域的识别与隔离策略，最后给出爆炸半径控制的工程实践方案。 服务依赖的复杂性本质 微服务架构下的依赖特征 单体应用时代的依赖关系是显式的、编译期的——通过 import 语句和函数调用就能完整描绘依赖图。微服务架构彻底改变了这一范式： 维度 单体应用 微服务架构 依赖发现方式 代码静态分析 运行时流量观测 依赖类型 函数调用 HTTP/gRPC/消息队列/事件总线 依赖稳定性 编译期确定 运行时动态变化 依赖可见性 IDE 可直接跳转 需要专门工具发现 故障传播路径 进程内异常栈 跨网络级联故障 依赖数量级 几十到几百 几百到几千 依赖关系的分类体系 并非所有依赖都具有相同的风险等级。一个成熟的依赖地图必须对依赖关系进行分类标注： 按调用方式分类： 同步调用：HTTP REST、gRPC、数据库查询。调用方阻塞等待响应，是级联故障的主要传播路径。 异步调用：消息队列（Kafka、RabbitMQ）、事件总线。调用方不阻塞，但消费端故障可能导致消息积压。 共享资源依赖：共用数据库、缓存集群、存储卷。资源竞争可能引发间接故障。 基础设施依赖：DNS、服务发现、配置中心。这类依赖故障影响面极广，属于关键路径。 按关键性分类： 强依赖：被依赖方不可用时，调用方无法完成核心功能。例如订单服务依赖库存服务。 弱依赖：被依赖方不可用时，调用方可降级运行。例如商品详情页依赖推荐服务。 条件依赖：在特定场景下才触发的依赖。例如促销活动期间才调用的优惠券服务。 # 依赖分类标注示例 class DependencyType: SYNC_HTTP = "sync_http" SYNC_GRPC = "sync_grpc" ASYNC_MQ = "async_mq" SHARED_DB = "shared_db" SHARED_CACHE = "shared_cache" INFRA_DNS = "infra_dns" INFRA_SERVICE_DISCOVERY = "infra_sd" class DependencyCriticality: STRONG = "strong" # 不可降级 WEAK = "weak" # 可降级 CONDITIONAL = "conditional" # 条件触发 # 依赖关系数据结构 class ServiceDependency: def __init__(self, caller, callee, dep_type, criticality): self....

概述 在云原生和微服务时代，一个请求可能跨越数十个服务节点。传统的监控方式将 Metrics、Logs、Traces 分散在不同系统中——Prometheus 看指标、ELK 搜日志、Jaeger 追链路，三者之间没有统一的关联方式。当线上故障发生时，你需要在三个系统之间来回切换，手动拼接关联信息，效率低下。 OpenTelemetry（简称 OTel）是 CNCF 主导的可观测性统一标准，目标是用一套 SDK/API 统一采集三大信号（Metrics、Logs、Traces），通过统一的 Collector 处理后发送到任意后端。它不替代后端存储和可视化，而是解决"数据采集层碎片化"的问题。本文深入讲解 OTel 的规范、架构、实践和迁移策略。 参考来源：OpenTelemetry 官方文档、CNCF OpenTelemetry 规范 一、为什么需要 OpenTelemetry 1.1 可观测性碎片化问题 传统可观测性架构（碎片化）： 应用代码 ├── Prometheus Client (Metrics) │ └── → Prometheus → Grafana ├── Logback + Filebeat (Logs) │ └── → Elasticsearch → Kibana └── Jaeger Client (Traces) └── → Jaeger → Jaeger UI 问题： 1. 三套 SDK，三套配置，三套运维 2. Metrics / Logs / Traces 之间无关联（TraceID 未关联到日志） 3....

为什么需要分布式追踪 微服务架构下，一个用户请求往往要穿越多个服务。当某个接口耗时从 200ms 飙升到 2s 时，日志散落在 N 台机器上，你很难判断瓶颈在哪一层——是网关转发慢、下游 DB 查询慢、还是某个服务间调用排队？ 分布式追踪（Distributed Tracing）解决的就是这个问题：它为每个请求生成一个全局唯一的 Trace ID，在服务间透传，最终在 UI 上画出一条完整的调用链路树，让每一段耗时一目了然。 Jaeger（发音类似"耶格"）由 Uber 开源，现为 CNCF 毕业项目。本文基于 Jaeger v1.60+ 和 OpenTelemetry SDK 进行实践。官方文档 分布式追踪核心概念 Trace 一个 Trace 代表一次完整的分布式请求链路，由唯一的 128-bit Trace ID 标识。它是一棵由多个 Span 组成的树形结构： Trace (TraceID: a1b2c3...) ├── Span: HTTP GET /api/orders [gateway] │ ├── Span: RPC GetUser [user-service] │ │ └── Span: SELECT * FROM users [mysql] │ └── Span: RPC GetOrderList [order-service] │ └── Span: Redis GET [redis] Span Span 是追踪的最小单元，记录一次操作的开始和结束。关键字段：...

为什么选择 Loki 传统 ELK（Elasticsearch + Logstash + Kibana）方案虽然功能强大，但存在两个核心痛点： 存储成本高：Elasticsearch 将日志全文索引化，每条日志的索引膨胀可达原始数据的 3-5 倍 运维复杂：ES 集群扩缩容、分片再平衡、索引生命周期管理复杂，生产集群维护成本高 Loki 由 Grafana Labs 开源，设计理念是"像 Prometheus 那样做日志"。它只对日志的标签（Labels）做索引，不对日志正文建索引，通过 LogQL 进行全文检索。这种设计使存储成本降低 10 倍以上。 本文基于 Loki 3.x，参考 Loki 官方文档 Loki vs ELK 对比 维度 ELK (Elasticsearch) Loki 索引方式 全文倒排索引 仅索引标签，正文不索引 存储成本 高（索引膨胀 3-5x） 低（标签索引 + 压缩正文） 查询语言 Lucene Query / KQL LogQL（类 PromQL 语法） 扩展性 水平扩展，分片复杂 微服务模式，组件独立扩展 适用场景 全文检索、复杂分析 日志监控、指标化查询、与 Grafana 联动 资源消耗 高（JVM，内存大） 低（Go 编写，内存友好） Loki 并非要完全替代 ES。如果你的核心需求是全文检索和复杂文本分析，ES 仍是更好的选择。但对于 SRE 日志监控、指标告警、排障定位这类场景，Loki + Grafana 的组合在成本和效率上优势明显。...