3. 可观测性三大支柱

在金融Serving系统中，一次转账请求可能跨越网关、账户服务、风控引擎、账务核心和通知服务。当这笔请求变慢或失败时，仅靠单一信号很难定位问题。可观测性正是通过三类互补数据——指标（Metrics）、日志（Logging）和链路追踪（Tracing）——把系统内部状态转化为可查询、可关联、可推理的证据。理解三者的基本概念、数据模型、采集方式与协同关系，是构建故障诊断能力的基础。

一、核心原理：三类信号回答不同问题

Metrics是随时间变化的数值型聚合数据，回答“系统整体是否异常、异常程度如何”。它成本低、适合长期存储和告警，典型如QPS、P99延迟、错误率、线程池活跃数、GC暂停时间。Logging是离散事件的文本或结构化记录，回答“某个时刻具体发生了什么”。它信息丰富、上下文强，适合根因分析和审计。Tracing记录单个请求在分布式系统中的完整调用路径与各段耗时，回答“慢在哪里、错在哪一跳”。

三者的数据模型差异明显：Metrics是“时间序列+标签”，Logging是“时间戳+级别+消息+字段”，Tracing是“TraceID+Span树+时间区间+标签”。金融场景对精度和合规要求高，因此日志需结构化、追踪需采样可控、指标需按业务维度打标。

二、数据模型与采集方式

Metrics通常采用拉取（Pull）或推送（Push）模式采集。Prometheus生态以Pull为主，通过Exporter暴露/metrics端点；金融系统也常用Push Gateway处理短生命周期任务。指标命名应遵循“命名空间_子系统_指标名_单位”规范，标签基数必须受控，避免userId这类高基数字段直接作为标签。

# 典型指标暴露格式
serving_http_requests_total{service="account",method="transfer",status="500"} 12
serving_http_request_duration_seconds_bucket{service="account",le="0.5"} 9821
serving_jvm_gc_pause_seconds_sum{service="risk",gc="young"} 3.42

Logging采集一般通过应用内日志框架输出JSON，再由Filebeat、Fluent Bit或OpenTelemetry Collector采集转发。金融系统需注意脱敏：卡号、身份证、金额等敏感字段必须在落盘前处理。Tracing采集依赖上下文传播，常用W3C Trace Context标准，在HTTP头中传递traceparent，跨线程和跨服务时通过SDK自动注入。

三、协同关系：从告警到根因的闭环

三者的协同价值在于“关联”。当指标告警触发时，运维人员需要快速跳转到对应时间窗口的日志和追踪。实现关联的关键是统一标识：在日志中打印traceId，在指标标签中保留service和endpoint，在追踪中记录http.status_code。这样就能形成“指标发现异常→追踪定位慢调用→日志确认错误原因”的诊断路径。

四、案例与误区复盘

某支付Serving系统在午间高峰出现转账成功率下降。指标显示serving_transfer_error_rate从0.2%升至4.7%，告警触发。通过追踪发现，失败请求的Trace中risk-service的Span状态为ERROR，耗时集中在规则匹配阶段。进一步按TraceID检索日志，发现大量rule_engine_timeout，原因是某条新上线规则导致回溯深度过大。最终通过回滚规则并增加规则缓存解决。