可观测性不等于多打点：从日志到洞察

1. 可观测性的三个支柱

可观测性（Observability）不是监控（Monitoring）的升级版，而是一种系统设计理念： 通过外部输出来理解系统内部状态的能力。

经典的可观测性模型包含三个支柱：

• 指标（Metrics）：数值型数据，反映系统在某个时间点的状态。如 CPU 使用率、请求 QPS、错误率等。
• 日志（Logs）：事件记录，描述系统发生了什么。如错误日志、访问日志、业务日志等。
• 链路追踪（Traces）：请求在分布式系统中的完整路径，帮助理解请求如何在不同服务间流转。

这三个支柱不是独立的，而是相互补充的： 指标告诉你"有问题"，日志告诉你"发生了什么"，链路追踪告诉你"问题在哪里"。

2. 指标设计：从"能看"到"有用"

很多团队的第一反应是"把所有能采集的指标都采集了"，结果就是： 指标面板密密麻麻，但真正有用的信息被淹没在噪音中。

2.1 黄金指标（Golden Signals）

Google SRE 提出的"黄金指标"是一个很好的起点：

• 延迟（Latency）：请求处理时间，包括成功和失败的请求。
• 流量（Traffic）：系统承载的请求量，如 QPS、并发数。
• 错误率（Errors）：失败请求的比例。
• 饱和度（Saturation）：系统资源的利用率，如 CPU、内存、队列长度。

这四个指标基本覆盖了系统健康度的核心维度。在它们的基础上，再根据业务特点添加业务指标。

2.2 业务指标：连接技术与业务

技术指标告诉你系统是否健康，业务指标告诉你业务是否正常。例如：

• 订单系统的下单成功率、支付成功率。
• 内容系统的内容发布量、用户活跃度。
• 推荐系统的点击率、转化率。

业务指标的设计需要与产品、运营团队协作，确保指标定义清晰、可衡量、可行动。

3. 日志管理：结构化与上下文

日志不是"越多越好"，而是"越有用越好"。好的日志系统需要解决几个问题：

3.1 结构化日志

传统的文本日志难以解析和查询，结构化日志（JSON 格式）可以：

• 快速定位特定字段（如用户 ID、订单号）。
• 支持复杂的查询条件（如"查找所有包含特定错误的日志"）。
• 便于日志聚合和分析。

示例：

• ❌ 文本日志："2025-01-12 10:30:45 ERROR User login failed for user123"
• ✅ 结构化日志：{"timestamp":"2025-01-12T10:30:45Z","level":"ERROR","event":"user_login_failed","user_id":"user123","ip":"192.168.1.100"}

3.2 日志级别与采样

不是所有日志都需要全量采集：

• ERROR / WARN：全量采集，这些是关键问题。
• INFO：采样采集，如 10% 采样率。
• DEBUG：开发环境全量，生产环境关闭或极低采样。

3.3 日志上下文

每条日志都应该包含足够的上下文信息，让你能够：

• 理解日志产生的场景（用户、请求、会话等）。
• 追踪问题的完整链路（通过 trace_id、request_id 等）。
• 快速定位相关日志（通过业务 ID、时间范围等）。

4. 链路追踪：理解分布式系统的行为

在微服务架构中，一个请求可能经过多个服务，链路追踪帮助你理解：

• 请求在哪些服务间流转？
• 每个服务的耗时是多少？
• 哪个服务是性能瓶颈？
• 错误发生在哪个环节？

4.1 Trace 与 Span

链路追踪的基本概念：

• Trace：一个请求的完整生命周期，包含多个 Span。
• Span：Trace 中的一个操作单元，如一次 RPC 调用、一次数据库查询。

每个 Span 包含：

• 操作名称（如 "user_service.get_user_info"）。
• 开始时间和持续时间。
• 标签（Tags）：如 HTTP 方法、状态码、错误信息。
• 日志（Logs）：与 Span 相关的日志事件。

4.2 采样策略

全量追踪的成本很高，需要合理的采样策略：

• 头部采样（Head-based）：在请求开始时决定是否采样，适合低延迟场景。
• 尾部采样（Tail-based）：在请求结束时决定是否采样，可以基于错误、延迟等条件，适合问题诊断。

5. 告警设计：从"有告警"到"告警有用"

告警的目的是让人在正确的时间采取正确的行动。糟糕的告警系统会导致：

• 告警疲劳：大量无效告警让人麻木。
• 告警风暴：一个问题触发数百条告警。
• 告警延迟：真正的问题被淹没在噪音中。

5.1 告警规则设计

好的告警规则应该：

• 可行动：告警后能明确知道要做什么。
• 有阈值：基于历史数据和业务目标设定合理的阈值。
• 有聚合：相同类型的问题应该合并告警，而不是每个实例都发一条。
• 有抑制：已知问题或维护窗口期间应该抑制告警。

5.2 告警分级

根据严重程度和紧急程度，将告警分为不同级别：

• P0（紧急）：影响核心功能，需要立即处理。
• P1（高）：影响部分功能，需要在 1 小时内处理。
• P2（中）：影响较小，可以在工作时间处理。
• P3（低）：信息性告警，可以定期回顾。

6. 可观测性平台的选择

市面上有很多可观测性平台，选择时需要考虑：

6.1 开源方案

• Prometheus + Grafana：指标采集和可视化，生态成熟。
• ELK Stack（Elasticsearch + Logstash + Kibana）：日志收集和分析。
• Jaeger / Zipkin：链路追踪。
• OpenTelemetry：统一的可观测性标准，支持多种后端。

6.2 商业方案

• Datadog：全栈可观测性平台，功能全面但成本较高。
• New Relic：APM 和可观测性，适合大型企业。
• 阿里云 ARMS / 腾讯云 APM：国内云厂商的方案，集成度高。

选择方案时，需要考虑：成本、功能完整性、团队技术栈、数据合规要求等。

7. 实践建议：从 0 到 1 建立可观测性

如果你要从零开始建立可观测性，建议按以下步骤：

阶段一：基础指标

1. 部署 Prometheus，采集基础系统指标（CPU、内存、网络等）。
2. 配置 Grafana，创建基础监控面板。
3. 设置关键告警（如 CPU 使用率 > 80%）。

阶段二：应用指标

1. 在应用中集成指标采集（如 Prometheus Client）。
2. 采集应用级指标（请求数、错误率、延迟等）。
3. 创建业务指标面板。

阶段三：日志系统

1. 统一日志格式（结构化日志）。
2. 部署日志收集系统（如 Filebeat + Elasticsearch）。
3. 建立日志查询和分析流程。

阶段四：链路追踪

1. 在关键服务中集成 OpenTelemetry。
2. 配置采样策略。
3. 建立问题排查流程，利用链路追踪定位问题。

8. 小结：可观测性是一种能力，不是工具

可观测性不是"部署一套监控系统"就完成了，而是一个持续的过程：

• 根据业务发展不断调整指标和告警。
• 从故障中学习，完善可观测性体系。
• 让可观测性成为开发流程的一部分，而不是事后补救。

当你能够通过指标、日志、链路追踪快速理解系统状态，定位问题根因时， 你就真正拥有了可观测性。这不仅能提升系统的可靠性，也能让团队更有信心地迭代和优化。