可观测性

概述 去年有个朋友跟我吐槽：他们公司上了 Prometheus、ELK、Jaeger 三套工具，运维团队 7 个人，每天光处理告警就耗掉 4 小时。某天凌晨支付服务 P0 故障，从告警触发到定位根因花了 42 分钟——根因是一个数据库连接池配置变更导致慢查询堆积，Jaeger 里有完整的 Trace，但没人看；ELK 里有慢查询日志，但没人搜；Prometheus 里有连接池指标的异常波动，但告警被淹没在 5000 条日常告警里。 问题出在哪？工具都上了，数据都采了，但三套系统各自为战，没有形成"可观测性"。这就像你给一辆车装了速度表、油表、温度计，但三个表盘分别放在后备箱、手套箱和引擎盖下面——仪表都在，但你开不了车。 可观测性（Observability）这个词来自控制理论，核心定义很简单：通过系统的外部输出推断系统内部状态的能力。说白了就是——不用进到系统里面去翻代码，光看数据就能回答"系统现在健不健康？出了问题在哪？为什么出问题？" 这篇文章不讲三支柱是什么（Metrics/Logs/Traces 满大街都有文章讲），讲的是从碎片化监控到统一可观测性体系，你需要做哪些架构决策，以及每个决策的踩坑实录。每一条都是我在生产环境中验证过的，不是 PPT 上的理论。 监控≠可观测性：先搞清楚你在解决什么问题 很多人把监控和可观测性混为一谈。这俩不是一回事。 监控（Monitoring） 回答的是"出了什么问题"——CPU 炸了、内存满了、接口超时了。它是预设的、基于已知故障模式的。你提前定义好"CPU > 80% 就告警"，系统照着执行。 可观测性（Observability） 回答的是"为什么出问题"——为什么这个接口突然变慢了？为什么这个 Pod 一直在重启？为什么这个用户的请求失败了？它是探索性的、面向未知故障模式的。你没法提前定义所有可能的故障，但通过 Metrics + Logs + Traces 的关联，你能在出事后快速定位。 举个例子：用户反馈下单失败。 只有监控：你看到订单服务的错误率从 0.1% 跳到 5%。你盯着 Grafana 看了 10 分钟，猜可能是数据库问题，跑去查 DB 日志。发现有个慢查询。但为什么有慢查询？不知道。继续猜。 有可观测性：你看到错误率跳到 5%，点开 Trace 链路，看到请求在库存服务的 DB 查询 Span 耗时 8 秒。点开这个 Span 关联的日志，看到是连接池等待超时。再看 Metrics，发现连接池活跃连接数在 15 分钟前从 5 飙到 50（配置变更后上限改大了，但数据库端 max_connections 没改）。3 分钟定位完毕。 维度 监控 可观测性 核心问题 出了什么问题？ 为什么出问题？ 数据预设 预定义指标和阈值 探索性分析，支持临时查询 故障模式 已知故障模式 未知故障模式也能排查 数据关联 各系统独立查看 Metrics↔Logs↔Traces 互相关联 典型工具 Zabbix、Nagios Prometheus+Loki+Tempo+Grafana 适用阶段 基础运维阶段 微服务/云原生阶段 别被概念绕晕了。记住一点：监控告诉你"病了"，可观测性告诉你"病在哪、为什么病"。如果你的系统是单体应用、部署在 3 台服务器上，监控够了。但如果你的系统是 50 个微服务跑在 K8s 上，没有可观测性，出了故障你就是盲人摸象。...

概述 2021 年我刚接手一个运维团队时，做了个简单统计：团队 12 个人，一周 40 小时工作时间里，平均 24 小时花在手动处理工单、重启服务、补磁盘空间这些事情上。琐事占比 60%。剩下 16 小时里，一半在开会同步信息，真正做工程优化的时间每周不到 8 小时。 团队里每个人都很忙，但系统还是不稳定。MTTR 40 分钟，可用性 99.5%，告警群每天 200 多条。老板问我：“我们团队到底行不行？“我答不上来。不是谦虚，是没有量化标准。 后来我花了 3 年时间，把可用性从 99.5% 推到 99.9%，MTTR 从 40 分钟压到 8 分钟，琐事占比从 60% 降到 20% 以内。回头复盘，最关键的一步不是引入了什么工具，而是建立了一套成熟度评估体系——先搞清楚团队在哪个段位，再决定下一步投什么。 这篇文章分享我实际用过的 SRE 团队成熟度 5 级模型。它借鉴了 CMMI 的分层思路，但完全针对 SRE 场景重新设计，每个级别都有可量化的判断标准。文末有一份 Python 自检脚本，你跑一下就知道自己的团队在哪一级。 为什么需要 SRE 成熟度模型 先说几个常见场景，看看你中了几条： 招人时 JD 写"精通 K8s 和 Prometheus”，面了一圈发现候选人技术栈差不多，但来了之后产出天差地别——因为你不知道团队缺的是"会写 PromQL 的人"还是"能设计 SLO 体系的人” 申报预算时跟老板说"我们需要买 Datadog 和搭建混沌工程平台"，老板问"现在是什么水平？投了能到什么水平？“你答不上来 跨团队协作时，开发觉得 SRE 只会卡上线，SRE 觉得开发只管发版不管稳定性——根源是双方对"SRE 该干什么"没有共识 团队里有人想推进自动化，有人觉得"手动操作挺好的为什么要改”，你作为负责人没法用数据说服 这些问题的共同根因是：没有一把可量量的尺子来衡量团队能力。...

概述 凌晨两点，我被电话叫醒。 某出行项目的用户反馈，凌晨时段打开 App 查看行程历史，页面要白屏 3-5 秒才出内容。排查了一圈，发现这组 API 用了 Serverless 函数计算，白天流量正常，凌晨流量低谷后函数实例被回收，第一个请求触发的冷启动直接让 P99 延迟飙到 4.8 秒。 这不是个例。我在多个项目中见过 Serverless 从 POC 到生产翻车的场景：冷启动让接口超时、月账单比传统服务器贵 3 倍、线上故障找不到日志、安全策略越配越乱最后谁也不敢改。 Serverless 的宣传话术很诱人——按需付费、自动扩缩容、无需运维。但真正在生产环境跑过的人都知道，“免运维"是个伪命题。Serverless 不是删掉了运维，而是把运维的战场从服务器管理转移到了冷启动治理、成本控制、可观测性建设和安全策略管理上。而且这些新战场的复杂度，一点也不比传统运维低。 这篇文章不讲 Serverless 的概念和入门，直接上 5 个生产级踩坑和治理决策。每个坑都来自真实项目，每个决策都有数据支撑。 1. 冷启动治理：从 5 秒到 200ms 的四层优化 1.1 冷启动到底卡在哪 很多人只知道"冷启动慢”，但说不清楚慢在哪。先拆解一次完整的冷启动过程： 阶段 耗时占比 具体动作 可优化空间 资源分配 15-20% 平台分配 CPU/内存、挂载文件系统 平台侧，用户不可控 运行时初始化 20-30% 加载语言 Runtime（Java 最慢，Node.js 最快） 选运行时 代码加载 15-25% 下载部署包、解压、加载依赖 精简包体积 初始化逻辑 30-40% 执行全局代码：连接 DB、初始化 SDK、加载配置 用户可控，优化空间最大 关键发现：初始化逻辑阶段占比最大（30-40%），而且这是用户唯一能深度优化的部分。很多团队的冷启动慢，不是因为平台不行，而是在全局初始化里塞了太多东西——建数据库连接池、初始化 Redis 客户端、加载配置文件、注册服务发现——这些操作在传统服务器上只执行一次，但在 Serverless 里每次冷启动都要重来。...

概述 凌晨三点，手机震动。告警群炸了 200 条消息，用户投诉已经涌进客服群。你爬起来打开电脑，登录跳板机，发现某个核心接口 P99 飙到 8 秒。接下来 30 分钟你都在翻日志、查 Grafana、问上下游——最终定位到是某个配置中心推了一行错误参数。 这个场景太熟悉了。在我经手的上百次线上故障中，定位环节消耗的时间占 MTTR 的 60% 以上。恢复操作本身可能只要 2 分钟（回滚、重启、切流量），但找到"到底哪里出了问题"往往要花 20-30 分钟。 MTTR（Mean Time To Repair/Recovery）衡量的是从故障发生到服务恢复的平均时间。但这个数字是个黑盒——30 分钟的 MTTR 里，到底哪些环节在拖后腿？检测花了多久？响应花了多久？定位花了多久？恢复花了多久？不拆开看，优化就无从下手。 这篇文章拆解我在某出行项目和某电商项目中实战验证的 MTTR 优化体系——四层防御模型：检测层、响应层、定位层、恢复层。每层有具体的工程手段和度量指标，不是空谈方法论。最终效果：核心服务 MTTR 从 40 分钟降到 8 分钟，故障定位时间从 30 分钟降到 5 分钟。 MTTR 拆解：你优化的是哪个环节 很多人把 MTTR 当成一个整体来优化，这是错的。MTTR 至少要拆成四个阶段： 阶段 全称 含义 典型耗时 优化重点 MTTD Mean Time To Detect 从故障发生到告警触发 1-5 min 监控覆盖、SLO 告警 MTTA Mean Time To Acknowledge 从告警触发到有人开始处理 2-10 min On-Call 机制、告警路由 MTTI Mean Time To Identify 从开始处理到定位根因 10-30 min 可观测性、诊断工具 MTTR Mean Time To Restore 从定位根因到服务恢复 1-5 min 回滚、自愈、预案 注意 MTTR 有两种常见解读：Repair（修复）和 Recovery（恢复）。SRE 语境下我更推荐用 Recovery——目标是恢复服务而非彻底修复 Bug。彻底修复是 Postmortem 之后的事（相关文章：故障复盘改进项跟踪）。...

概述 线上炸了，你打开 Kibana 搜日志，发现关键 Pod 3 分钟前被 OOM Kill 重启了，旧日志跟着容器一起灰飞烟灭。这种事在 K8s 环境里太常见了——Pod 是短命的，日志不能跟着 Pod 一起消失。 K8s 的日志采集和传统虚拟机完全不是一回事。传统环境日志躺在 /var/log/ 下，SSH 上去就能看。K8s 里 Pod 随时可能被调度到任何节点，随时可能被销毁重建，日志分散在整个集群。如果不做集中采集，故障排查时你根本找不到日志在哪。 这篇文章把 K8s 日志采集的几种方案拆开讲清楚：DaemonSet 模式、Sidecar 模式、以及基于节点 Agent 的方案。每种方案什么场景用、怎么配置、踩什么坑，全部覆盖。最后给出一套生产可用的选型决策框架。 K8s 日志的三种类型 在讲采集方案之前，先搞清楚 K8s 里有哪些日志。不同类型的日志采集策略完全不同。 1. 容器标准输出日志 这是最常见的一类。应用把日志写到 stdout/stderr，容器运行时（containerd 或 Docker）负责把这些日志落盘到节点的 /var/log/containers/ 目录。 # 查看某节点的容器日志文件 ls /var/log/containers/ # 输出示例 # nginx-xxx_default_app-abc123.log # redis-yyy_default_app-def456.log # 这些文件实际是指向 /var/log/pods/ 下的符号链接 ls -l /var/log/containers/nginx-xxx_default_app-abc123.log # lrwxrwxrwx 1 root root 99 ... nginx-xxx_default_app-abc123.log -> /var/log/pods/default_nginx-xxx_abc123/app/0.log 这类日志的好处是采集简单——DaemonSet 模式直接读 /var/log/containers/*....

概述 你有没有遇到过这种情况：用户反馈"系统好卡"，你打开 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 是追踪的最小单元，记录一次操作的开始和结束。关键字段：...