3. 可观测性三大支柱

在银行微服务交易链路中，可观测性不是“多装几个监控工具”，而是围绕同一笔交易建立可度量、可追溯、可定位的证据体系。Metrics、Logging、Tracing 被称为可观测性三大支柱，它们分别回答不同层次的问题：系统整体是否健康、某个时刻发生了什么、一笔交易经过了哪些服务并慢在哪里。理解三者的边界与协同，是后续链路治理、故障定位和容量评估的基础。

一、核心原理：三种信号的本质差异

Metrics（指标）是数值型的时间序列数据，通常由客户端或服务端周期性聚合上报，例如交易成功率、TPS、P99 延迟、线程池活跃数、数据库连接数。它的优势是低存储成本、高查询效率，适合做告警、趋势分析和容量水位判断；缺点是维度有限，难以还原单笔交易的完整上下文。

Logging（日志）是离散事件的文本或结构化记录，记录“在什么时间、哪个服务、哪个实例、发生了什么”。银行场景中常见的有交易流水日志、异常堆栈、风控决策日志、审计日志。日志信息丰富、可读性强，适合排查具体错误和合规审计；但海量日志的采集、存储和检索成本高，且缺乏跨服务的天然关联。

Tracing（链路追踪）以 TraceId 和 SpanId 为核心，把一次请求在多个服务、线程、中间件之间的调用关系串成有向图。每个 Span 记录服务名、操作名、开始时间、耗时、状态和标签。它天然适合回答“这笔转账为什么慢了 800ms”“调用链在哪一跳失败”。缺点是采样策略和埋点质量直接影响效果，且对异步、消息队列、批处理场景需要额外适配。

二、方法流程：从告警到根因的协同排查

在银行生产环境中，三支柱通常按以下流程协同工作，形成闭环：

1. 指标告警先行：监控平台基于 Metrics 发现“转账交易成功率 5 分钟内从 99.9% 跌至 97.2%”，触发 P2 告警。
2. 日志缩小范围：按服务名、时间窗口和错误码检索日志，发现某分行渠道的“账户余额查询”接口大量返回超时异常。
3. 链路还原路径：用日志中的 TraceId 打开 Tracing 系统，看到调用链在“账户服务 → 数据库连接池”这一跳耗时从 20ms 突增至 1.8s。
4. 指标交叉验证：回到 Metrics 查看该实例的数据库连接池活跃数和等待队列，确认连接池被打满。
5. 修复与回归：扩容连接池或限流后，观察三项信号是否同步恢复，并记录复盘结论。

三、银行场景中的定位与对比

银行交易链路对一致性、合规性和可审计性要求极高，三支柱的定位也有明显差异。下表从多个维度进行对比：

四、误区与复盘：银行落地中的常见问题

在实际项目中，三支柱建设容易走入以下误区：

• 只建指标不建链路：告警能发现成功率下降，但无法回答“哪一笔、哪一跳、哪个客户受影响”，排障仍靠人工登录机器查日志。
• 日志没有 TraceId：微服务日志分散在几十个实例中，无法按一笔交易聚合，排查时间被拉长数倍。
• 采样率设置不当：为节省成本把链路采样率降到 0.1%，导致故障期间关键交易没有被采集，反而失去定位能力。银行核心交易建议对异常和慢请求强制采样。
• 指标维度爆炸：把客户号、流水号作为指标标签，导致时间序列数量失控，监控系统自身成为瓶颈。高基数信息应放在日志和链路中。
• 三套系统各自为政：指标、日志、链路使用不同的服务命名和时间标准，无法交叉跳转，协同效率低下。