日志、指标与可观测性

系统出问题时，最昂贵的不是修复，而是不知道问题在哪里。可观测性让团队能从现象走到原因：发生了什么、频率如何、影响哪些用户、调用链在哪一步失败。

三类信号各有职责

信号	擅长回答的问题	例子
日志	某一次请求发生了什么	参数校验失败、下游超时
指标	整体趋势是否异常	错误率、延迟、队列积压
追踪	一次调用跨服务经过哪里	网关、业务服务、数据库耗时

不要只记录“出错了”。日志应该包含时间、级别、请求标识、业务对象标识和安全的上下文；敏感字段必须脱敏或根本不记录。

指标从用户动作和系统容量两侧建立

技术指标帮助发现资源瓶颈，业务指标帮助判断用户是否真正受影响。

技术：请求量、错误率、延迟分位数、CPU、连接池、队列长度
业务：下单成功率、支付完成率、任务积压、内容发布量

每个告警都应有可执行的处理说明。没有行动路径的告警只会制造噪音，最终被忽略。

让一次故障可被串起来

入口生成请求标识，传递给下游服务、日志和错误响应。结合服务名、版本和部署环境，就能区分“某个版本导致”与“某个依赖整体变慢”。

{
  "level": "error",
  "requestId": "req_abc123",
  "event": "payment.timeout",
  "orderId": "order_42",
  "retryable": true
}

从故障中完善系统

每次重要故障后，记录触发条件、检测方式、实际影响、临时处置和长期改进。改进可能是测试、限流、缓存、告警阈值或产品提示，而不只是“多打一行日志”。可观测性最终服务于更快恢复与更少重复故障。