1、可观测性概述：定义、三大支柱
先聊个基本问题——可观测性到底是什么？
我不是说教科书定义。教科书讲「系统外部输出推断内部状态的能力」。嗯，没错，但太绕了。
我自己的理解很简单：系统出了事，你能不能很快地知道「哪里坏了」以及「为什么会坏」。 如果能，这个系统就有可观测性；如果不能，那它就是个黑盒，你再怎么熬夜也找不到根因。
举个例子。几年前我在一个加密货币交易所做架构升级，线上突然出现大量订单延迟。没有日志、没有指标、没有链路追踪，我们几个人对着空白的监控面板干瞪眼。折腾了三个小时才发现是某个 Redis 连接池泄漏了。但如果我们把可观测性做好，十分钟内就能定位到。那次之后，我对团队说：可观测性不是可选项，是生存刚需。
核心观点：可观测性 = 让系统「开口说话」的能力。它包括数据采集、存储、分析和可视化几个环节，但最基础的是三个数据来源——日志、指标、追踪。
为什么需要可观测性？
你可能觉得自己系统挺稳的。但你想想看：一个加密链路涉及签名、哈希、椭圆曲线运算、网络传输、共识验证……每一个环节都可能出问题。出了问题你要能快速切分。可观测性就是你的「眼睛」和「耳朵」。
- 故障定位 —— 3 分钟找到根因，而不是 3 小时。
- 性能优化 —— 知道哪个环节最慢，针对性优化。
- 容量规划 —— 基于历史趋势预测未来资源需求。
- 安全审计 —— 所有关键操作都有据可查，尤其是加密相关操作。
我的习惯：新系统上线前，先问自己一个问题——「如果一个节点挂了，我能不能在一分钟内知道它是因为什么挂的？」如果答案是否定的，说明可观测性还没到位。
三大支柱：日志、指标、追踪
可观测性的业界共识是三大支柱。说白了就是三种不同维度的数据，各有所长，合在一起才能拼出完整画面。
| 支柱 | 核心特点 | 典型数据 | 常见工具 |
|---|---|---|---|
| 日志 | 离散事件记录，带时间戳和详细信息 | 字符串文本（JSON、纯文本） | ELK、Loki、Graylog |
| 指标 | 聚合数值，时间序列，可做阈值告警 | 计数、比率、直方图、分位值 | Prometheus、Graphite、Datadog |
| 追踪 | 请求链路，跨服务调用关系，每个 span 带耗时 | Trace ID、Span ID、父 Span ID | Jaeger、Zipkin、OpenTelemetry |
三大支柱的关系不是替代，而是互补。说一个我踩过的坑：早期我只用指标，看到错误率飙升，却不知道是哪个接口、哪个请求链出的问题。后来补了追踪，才发现是「加密签名」这一步响应时间突然从 5ms 变成 2s，原因是对应的 HSM 硬件负载不均。没有追踪，你根本没法从指标的红海里捞出那个具体的请求。
日志（Logs）—— 系统的「黑匣子」
日志是时间戳 + 结构化/非结构化的文本记录。每次事件发生，系统就写一行。好处是信息最丰富，坏处是数据量大、检索慢。
在加密链路里，我建议关键节点（签名、验签、密钥生成、证书验证）必须输出结构化日志，至少包含：操作类型、用户标识、请求 ID、执行耗时、结果状态。这样后查问题才能按 ID 快速过滤。
// 伪代码示例：加密签名操作的日志结构
{
"timestamp": "2025-03-25T10:32:15.123Z",
"level": "info",
"service": "crypto-service",
"requestId": "req-abc-123",
"operation": "ecdsa_sign",
"keyId": "key-hsm-001",
"durationMs": 12,
"result": "success"
}注意：千万不要在日志中记录敏感私钥或明文密码！曾经有个项目为了调试方便把私钥片段打印进了日志，后来日志被泄漏……后果很严重。加密链路里要特别注意脱敏。
指标（Metrics）—— 系统的「仪表盘」
指标是聚合的数值，以时间序列方式存储。比如每秒请求数、99% 分位延迟、错误率。指标的主要价值在于：可告警、可趋势分析、长期存储成本低。
我个人习惯用 Prometheus + Grafana 这套组合。给加密链路设几个关键 SLI：
- 签名延迟（p50/p99） —— 超过 100ms 就发警告
- 验签成功率 —— 低于 99.9% 立刻排查
- 密钥库连接池使用率 —— 超过 80% 需扩容
你想想看，如果没有指标，你根本不知道系统是在「健康」还是「亚健康」。只有指标能告诉你「嗯，最近三天延迟在缓慢爬升，可能有问题了」。
追踪（Tracing）—— 系统的「行程单」
追踪记录一个请求经过多个微服务或组件时的完整路径。每个跨度（Span）包含：服务名、操作名、开始时间、结束时间、父 Span ID。对于加密链路这种多跳场景（客户端 → 网关 → 认证 → 加密服务 → HSM → 存储），追踪简直是救命稻草。
我记得有一次，用户反馈提币到账慢。指标显示网关延迟正常，加密服务延迟正常，存储延迟也正常。但加上追踪一看，发现「认证服务」在调用加密服务时出现了 200ms 的空转——因为连接池配置错了，每次请求都新建连接。要是没有追踪，这种「每个环节看起来都正常、整体却很慢」的问题根本查不出来。
实现上，我推荐 OpenTelemetry，它一套 SDK 把三种信号都覆盖了。而且它天然支持上下文传播，能自动把 trace 信息注入到日志和指标里。
三者协同：1+1+1 > 3
单一支柱都有盲区。日志告诉你「谁干了什么」，指标告诉你「量有多少」，追踪告诉你「请求怎么走的」。只有把它们放在一起，你才能回答一个完整的问题：「为什么某个用户在某次操作中签名失败了？」
- 从指标看到签名错误率突然升高（时间范围）。
- 从追踪找到那个失败的 trace，看到哪个 span 出错。
- 从日志拿到具体错误信息：证书过期、密钥不存在、签名算法不匹配。
我建议：在加密链路项目里，先把三大支柱的基础架子搭好——日志结构化 + 指标打点 + 追踪注入，不用太复杂。等跑一个月，你看到了真实的数据，自然会知道哪里需要精调。
避坑指南
说几个我踩过的坑，希望你别重走。
- 迷信单一种类数据：我曾经只上指标，结果排查问题时发现只知道「某个服务报错」，但完全不知道是哪个用户、哪次请求、什么参数导致的。后来咬牙加了全链路追踪，问题迎刃而解。
- 日志不结构化：纯文本日志看起来省事，但检索和自动化处理难度极大。我的经验是，从第一天就用 JSON 格式输出，字段定义清晰，哪怕多花一点硬盘空间都值。
- 忽略采样策略：加密链路 QPS 可能很高，全量追踪会产生天量数据。记得用「头部采样 + 尾部采样」结合，保证高延迟和错误请求不丢失，同时控制存储成本。
一个小技巧：在加密服务的关键函数里加一行「耗时打点」和「异常埋点」，配合 trace 和日志，你就能拼出完整的「签名失败故事」。比如：用户A 的证书在 T1 时刻过期，导致签名返回 error code 1003，链路上可以看到请求在 crypto-service 处停止，日志里能找到具体原因。
本章核心要点
捋一捋今天讲的东西：
- 可观测性 = 系统能暴露内部状态，让我们快速定位问题。
- 三大支柱 = 日志（事件细节）、指标（数量趋势）、追踪（请求路径）。
- 协同使用才能发挥最大价值，单点依赖会留下盲区。
- 落地要从结构化日志、关键指标、分布式追踪起步，别贪多求全，先跑通再优化。
嗯，第一篇就到这里。后面我们会深入到加密链路的实际场景，讲怎么一步一步把这些支柱搭起来，以及哪些地方最容易踩坑。你可以在脑子里过一遍：现在的系统，三大支柱分别做到了几分？