2. 可观测性三大支柱：日志、指标、追踪
聊加密模块的可观测性，我们得先搞懂一个基础问题：到底看什么？
业内有个共识，叫“可观测性三大支柱”——日志、指标、追踪。这三者各有专攻，又相互补充。我个人的习惯是，把它们比作侦探办案的三件套：日志是口供，指标是监控录像，追踪是行动轨迹还原。
下面我们一个一个拆开看。
2.1 日志（Logs）—— 最直接的“发生了什么”
日志是最古老、最直觉的观测手段。说白了，就是一段带时间戳的文本，记录系统里发生的某个离散事件。
在加密模块里，日志的典型场景包括：
- 密钥生成成功/失败
- 证书验证链断裂
- TLS 握手异常（比如 cipher suite 不匹配）
- HSM（硬件安全模块）调用超时
结构化日志才是现代玩法。 我见过太多团队还在打印纯文本日志，像这样：
2025-04-11 10:23:45 ERROR: key operation failed排查的时候你根本不知道是哪把密钥、哪个操作、哪个用户触发的。
所以我建议，从第一天起就使用结构化日志（JSON 格式是主流）：
{
"timestamp": "2025-04-11T10:23:45.123Z",
"level": "ERROR",
"module": "key-mgmt",
"operation": "key_rotation",
"key_id": "k-abc123",
"error": "HSM_CONNECTION_TIMEOUT",
"duration_ms": 5012,
"trace_id": "tr-7f8e9d"
}看到区别了吗？字段名、值、上下文一目了然。你在 ELK 或 Loki 里做过滤、聚合，效率会高出一个数量级。
trace_id 或 span_id。日志如果没有关联到追踪上下文，查分布式加密调用链时你会想哭的。
2.2 指标（Metrics）—— 聚合后的“系统状态快照”
指标和日志不同，它不关心单次事件，而是关注一段时间内的聚合统计。你可以把它理解为系统的“体温、血压和心率”。
为什么需要指标？因为日志的量太大了。一个高并发的加密网关，每秒可能产生几万条日志。你不可能逐条去看。但如果你只关心“整体健康度”，指标就派上用场了。
加密模块需要重点关注的指标分三类：
| 类别 | 指标示例 | 为什么重要 |
|---|---|---|
| 流量 | 每秒 TLS 握手次数、每秒签名验签数 | 反映加密操作的整体负载 |
| 延迟 | P50/P95/P99 加密操作耗时 | 用户感知的关键；P99 抖动往往意味着资源竞争或算法瓶颈 |
| 错误 | 密钥操作失败率、证书过期率 | 直接反映安全性；很多攻击在初期表现为错误率异常上升 |
举个实际例子。我在做 HSM 集成时，发现 P99 延迟从 50ms 突然跳到 200ms，但平均延迟只涨了 10%。如果只看平均值，根本不会有人注意到。指标设计时，一定要关注分布（特别是尾部延迟），而不是只看平均。
2.3 追踪（Traces）—— 串起全貌的“请求旅程”
分布式系统里，一个加密操作可能跨越多个服务。比如：
- 用户请求签名 →
- API 网关做 TLS 卸载 →
- 身份服务调用证书中心签发证书 →
- 证书中心调用 HSM 做私钥操作
日志只能告诉你每个节点发生了什么，指标只能告诉你每个节点是否健康。但谁先谁后？哪个环节最慢？调用链有没有异常断裂？这就要靠追踪了。
追踪的核心单位是Span（跨度）。一个 Span 记录了一次操作的名称、开始/结束时间、状态、以及父 Span ID。所有 Span 通过 Trace ID 串联起来，形成一棵调用树。
加密模块的追踪要点：
- 每个加密库调用都要创建子 Span。不要只追踪 HTTP 层，要把内部 HSM 调用、密钥加载、算法计算也纳入追踪。
- 带上敏感上下文，但注意不要记录密钥明文。我习惯在 Span 标签里记密钥 ID、算法名称、密钥版本，而不是密钥值本身。
- 用好 Baggage（链路携带的元数据），比如把客户端的 TLS 版本一路传递到后端，方便做端到端根因分析。
一句话总结：日志回答“事件”，指标回答“健康”，追踪回答“路径”。三者缺一不可。
2.4 三大支柱的协作关系
光有单个支柱是不行的。你想想看，如果只有日志，你看到一条 ERROR 日志是“HSM timeout”，但你不知道这是哪个请求的，也不知道其他请求是否受影响。如果只有指标，你看到错误率飙升，但不知道具体是哪段代码路径导致的。如果只有追踪，你看到调用链变慢，但不知道慢的具体错误信息是什么。
正确的做法是让三者联动。比如：
- 指标触发告警 → 查看对应时间段的追踪 → 追踪里携带 trace_id → 关联到具体的日志行 → 定位到根因。
- 反过来，日志里出现新的异常类型 → 在其所在时间段内对比指标变化 → 确认是否引起业务抖动。
下面这张图展示了我常用的“可观测性三支柱数据流动”框架：