摘要：# 监控三件套：指标、日志、链路，到底该先搞哪个？ 我前两天帮一个朋友看他们新上线的电商系统，监控面板做得那叫一个“齐全”——十几个大盘，花花绿绿的曲线，乍一看特别唬人。结果真出了个订单支付延迟的故障，他们几个运维愣是对着屏幕看了半小时，愣是没找到根因。…

监控三件套：指标、日志、链路，到底该先搞哪个？

我前两天帮一个朋友看他们新上线的电商系统，监控面板做得那叫一个“齐全”——十几个大盘，花花绿绿的曲线，乍一看特别唬人。结果真出了个订单支付延迟的故障，他们几个运维愣是对着屏幕看了半小时，愣是没找到根因。指标全绿，日志刷屏，就是不知道问题卡在哪一层。

这种场景你应该不陌生吧？现在一说到系统可观测性，Metrics（指标）、Logs（日志）、Traces（链路追踪）这“三件套”就跟标配似的，谁都得上一套。但说实话，很多团队钱花了，数据收了，真到用的时候才发现：要么是数据太多看花了眼，要么是数据之间各说各话，根本串不起来。

今天咱就捞点干的，不聊那些“三位一体”、“数据融合”的漂亮话，就说说在真实项目里，资源有限、时间紧迫的情况下，这仨到底该怎么选、怎么配，才能真的在出问题时帮你一把，而不是添乱。

一、先搞明白它们仨到底能干啥（说人话版）

别被那些术语唬住，咱们用大白话拆开看。

Metrics（指标），说白了就是系统的“体检报告”。它告诉你现在心跳多少（QPS）、血压高不高（CPU使用率）、体温正不正常（错误率）。特点是数值化、周期采样、占用资源少。你不可能每秒钟记录每一次心跳的完整波形，那就累死了，所以你记个“每分钟72次”就够了。指标的作用是告诉你“出事了”，以及“大概哪不舒服”。比如突然发现错误率从0.1%飙到10%，你就知道，坏了，得查了。

Logs（日志），这就是系统的“日记本”或者“黑匣子录音”。它记录的是离散的事件：“用户A在几点几分调用了支付接口，传了啥参数，返回了啥结果，过程中打印了一句警告。”日志的特点是记录原始事件、上下文信息丰富、但体积庞大、格式可能很随意。它的作用是告诉你“当时发生了什么”，帮你还原事故现场。但问题是，日记可能写得啰嗦又杂乱，真要从几百万条里找到关键的那几句，跟大海捞针差不多。

Traces（链路追踪），这个可以理解为一次完整请求的“快递单号追踪”。从用户点击“下单”开始，这个请求就像个包裹，经过网关、订单服务、库存服务、支付服务……链路追踪会给这个包裹贴上一个唯一的ID，记录它每到一个“中转站”（服务）的到达时间、处理时长、以及下一个目的地。最后你能看到一张完整的“物流轨迹图”。它的核心作用是清晰地告诉你“慢在哪一环”。是卡在数据库查询了，还是某个外部API响应太慢了？一目了然。

二、别贪多嚼不烂：从“保命”到“养生”的配置顺序

很多团队一上来就想All in，三个全上，而且都要最细粒度。结果往往是运维被告警淹死，开发被日志卷死，硬盘被数据撑死。我的建议是，分阶段来，像打游戏点技能树一样。

第一阶段：先搞定Metrics，建立“火灾报警器”

如果你的系统还处在“裸奔”状态，或者预算非常有限，什么都别想，先把核心业务指标和系统资源指标监控起来。

为啥？因为指标最便宜（相对而言），最直观，能最快帮你发现异常。你不需要一开始就搞多么复杂的聚合和预测，就做两件事：

1. 业务黄金指标：吞吐量（比如每秒订单数）、错误率（比如HTTP 5xx比例）、延迟（比如P95响应时间）。这三个数健康，业务大体就健康。
2. 系统核心指标：CPU、内存、磁盘I/O、网络流量。这四个是基础设施的“生命体征”。

说白了，这个阶段的目标是：当线上服务挂了或者慢得离谱的时候，能有人（或系统）第一时间打电话叫你起床，而不是等用户骂到微博上你才知道。很多创业公司早期，靠一套成熟的指标监控体系，就能解决80%的突发性问题。

第二阶段：用Logs和Traces，打造“事故调查工具箱”

报警响了，你知道服务器CPU飙到90%了，然后呢？你怎么知道是哪个接口、哪个用户、哪段代码引起的？这时候，就需要日志和链路来当“侦探”了。

这里有个常见的误区：先铺天盖地打日志，还是先上链路追踪？

我的经验是：如果你的系统是单体应用，或者服务数量不多（<10个），先规范化日志可能更直接有效。确保关键业务流程（尤其是错误分支）都有结构化的日志（比如JSON格式），包含请求ID、用户ID、时间戳、错误码这些关键字段。这样你至少能靠grep和请求ID，勉强跟完一个请求的足迹。

但是，一旦你的服务超过十个，特别是微服务架构，链路追踪的优先级必须提到最高。原因很简单：在分布式系统里，一个问题就像一场连环车祸，你靠看每个司机（服务）自己写的日记（日志），很难拼凑出完整的车祸现场和责任链条。而链路追踪是上帝视角的“道路监控”，直接告诉你车祸是从哪辆车开始的，怎么连环撞的。

我见过太多团队，在微服务下还疯狂打日志，试图通过日志关联来排查问题，结果运维成本高到吓人，查一个问题动辄几小时。上了链路追踪之后，很多问题定位从小时级缩短到了分钟级。——这就是工具选对了的威力。

三、一些“反常识”的实话和私货

1. 日志不是越多越好：很多开发喜欢“以防万一”，在代码里到处打DEBUG日志。真到线上，日志量暴涨，不仅写磁盘IO压力大，检索起来更是灾难。日志要打在关键决策点和异常处理上，并且要分级别（ERROR > WARN > INFO）。把日志当“证据”，而不是“流水账”。
2. 指标可以“说谎”：平均响应时间（Average）是个著名的“骗子”。如果100个请求里，99个是1ms，1个是10s，平均下来是100ms，看起来好像还行？实际上那个10s的请求可能已经让用户暴走了。一定要看分位数（P95, P99），它更能反映尾部用户的真实体验。
3. 链路追踪不是无损耗的：全量采集每一次请求的链路？对于高并发系统，那产生的数据量和性能开销是惊人的。通常需要采样，比如只采集1%的请求。这里就有学问了，是随机采样，还是对慢请求、错误请求提高采样率？需要根据业务调整。别指望上了链路就一劳永逸。
4. 别指望它们自动关联：理想很丰满，Metrics、Logs、Traces通过一个统一的请求ID完美串联。现实是，很多公司这三套数据来自不同的代理、存到不同的系统（Prometheus, ELK, Jaeger），中间还有数据丢失、格式不对齐的问题。“可观测性”的终极难题，往往不是数据采集，而是数据关联。前期如果没规划好统一的上下文传递（比如TraceID），后期关联就是地狱难度。

四、给你的落地建议（抄作业版）

• 新手村/资源紧张：集中火力搞Metrics（用Prometheus + Grafana足矣）。定好核心业务指标，设置合理告警。先解决“不知道出事”的问题。
• 微服务起步/经常被跨服务问题困扰：优先引入Traces（SkyWalking, Jaeger都是好选择）。哪怕只接入了关键服务，也能极大提升排查效率。日志可以先维持现状。
• 问题定位需要深度上下文：在有了TraceID的基础上，规范化和结构化你的Logs。确保每条重要日志都带上TraceID，这样你从链路图上看到问题节点，能一键查到当时的详细日志。
• 终极形态（不差钱/追求效率）：考虑可观测性平台，或者至少把Metrics、Logs、Traces的数据，通过统一的“数据湖”或关联分析工具（比如Grafana Loki/Tempo的协同，或商业方案）进行联动。目标是实现“指标告警 -> 查看关联链路 -> 定位异常节点 -> 查看该节点当时日志”的一键式导航。

说到底，Metrics、Logs、Traces不是三选一的选择题，而是一个在不同阶段有不同侧重点的搭配题。核心思路就一个：用最小的成本和复杂度，解决当前阶段最痛的运维问题。

别看着大厂的全家桶眼热，他们的复杂度你可能根本用不上。就像你感冒了，没必要直接上核磁共振。先买个温度计量量体温（Metrics），真严重了再考虑查血（Logs）和拍个片子（Traces）。

你的系统现在最需要哪一样？心里有答案了吧。行了，不废话了，搞监控去吧。