可观测性三大支柱

本文目录导读：

1. 指标（Metrics）
2. 日志（Logs）
3. 链路追踪（Traces）
4. 三大支柱的协同工作（1+1+1 > 3）
5. 三大支柱对比表

可观测性的三大支柱是 指标（Metrics）、日志（Logs） 和 链路追踪（Traces），这三大支柱共同为理解系统内部状态、诊断问题和优化性能提供了全面的视角。

以下是每个支柱的详细解释：

指标（Metrics）

指标是可聚合的、数值型的时间序列数据，它们反映了系统在特定时间点的状态或行为，通常用于监控系统的健康状态、性能和容量。

• 核心特征： 数值型、时间戳、可聚合、维度（标签）。
• 解决的问题： “系统现在怎么样？趋势如何？有没有异常？”
• 典型例子：
  • RED（Rate, Error, Duration） 指标： 请求速率、错误率、请求持续时间。
  • USE（Utilization, Saturation, Errors） 指标： 资源使用率、饱和度、错误数（如 CPU、内存、磁盘、网络）。
  • 业务指标： 订单数、注册用户数、活跃用户数。
  • 基础架构指标： CPU 使用率、内存使用率、磁盘 I/O、网络流量。
• 优点：
  • 高效存储和查询： 数据量相对小，适合长期存储和趋势分析。
  • 实时告警： 可以快速定义阈值和规则，设置告警。
  • 宏观视角： 快速了解系统的整体健康状况。
• 常用工具： Prometheus, Grafana, Datadog, New Relic, InfluxDB。

日志（Logs）

日志是带时间戳的、不可变的、通常是文本格式的事件记录，它详细描述了系统中发生的具体事件，包括用户请求、系统报错、调试信息等。

• 核心特征： 时间戳、结构化或非结构化文本、详细上下文、不可逆。
• 解决的问题： “到底发生了什么？为什么会这样？”（这是问题排查的最后一公里）
• 典型例子：
  • ERROR 2024-05-21 10:00:00 Failed to connect to database: timeout
  • INFO 2024-05-21 10:00:01 User id=12345 logged in from IP=192.168.1.1
  • WARN 2024-05-21 10:00:02 Request /api/orders took 1500ms, exceeding threshold 1000ms
• 优点：
  • 细节丰富： 包含最完整的上下文信息，是排查问题的核心依据。
  • 灵活性高： 可以记录几乎任何类型的信息。
  • 易于理解： 人类可读，便于分析。
• 缺点：
  • 数据量大： 存储成本高，查询速度可能较慢（特别是在非结构化情况下）。
  • 难以聚合： 非结构化的日志难以进行数值分析和趋势聚合。
• 常用工具： ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Splunk, Datadog Logs, Graylog。

链路追踪（Traces）

链路追踪用于追踪一个请求在分布式系统中的完整生命周期，它记录了一个请求从一个服务到另一个服务的传播路径，以及每个服务处理该请求所花费的时间。

• 核心特征： 分布式上下文传播、服务间调用关系、耗时分析。
• 解决的问题： “请求的瓶颈在哪里？哪个服务调用失败？请求的执行路径是什么样子的？”（尤其在微服务架构中至关重要）
• 核心概念：
  • Span（跨度）： 服务中的一个操作单元（如一次数据库查询、一次 RPC 调用），包含开始时间、结束时间、状态、属性等。
  • Trace（追踪）： 由同一个请求触发的所有 Span 构成的树状结构，一个 Trace 由一个全局唯一的 Trace ID 标识。
• 典型例子：
  • 一个用户请求 get_order_details，经过 API Gateway -> User Service -> Order Service -> Payment Service -> Database，Trace 记录了每个环节的耗时和调用关系。
• 优点：
  • 端到端可见性： 清晰展示请求在分布式系统中的完整路径和瓶颈。
  • 问题定位： 可以快速定位导致性能下降或错误的那个具体的服务或操作。
  • 依赖关系映射： 自动生成服务依赖关系图。
• 常用工具： Jaeger, Zipkin, OpenTelemetry, AWS X-Ray, Google Cloud Trace, Datadog APM。

三大支柱的协同工作（1+1+1 > 3）

仅仅拥有三大支柱中的一两个是不够的,它们的真正价值在于相互关联，一个高效的观察性系统需要将这三种数据类型连接起来。

典型的排查场景：

1. 告警（指标）触发： 你在 Grafana 上看到一个 请求错误率 的指标告警，指出 用户下单接口 的错误率飙升至 50%。
2. 定位服务（链路追踪）： 你点击告警，跳转到具体的 Trace 查询页面，查找一个失败的订单请求，Trace 显示请求成功从 API Gateway 到达 Order Service，但在调用 Payment Service 时失败了（耗时 30 秒，状态码 500）。
3. 深入排查（日志）： 你复制这个失败 Trace 的 Trace ID，到日志系统（如 Kibana）中搜索，你找到 Payment Service 中对应的日志行，显示 ERROR: 数据库连接池耗尽。
4. 根本原因： 指标（数据库连接池使用率）可能也早已告警，但你通过追踪和日志找到了确切的根因——Payment Service 的数据库连接池配置过小，导致在突发流量下崩溃。

三大支柱对比表

在现代分布式系统（尤其是微服务、云原生架构）中，仅仅拥有三大支柱中的两个是不够的，一个优秀的可观测性平台应该能够无缝地关联指标、日志和链路追踪，让你能够从一个粗粒度的告警（指标）迅速下钻到具体的请求链（追踪），并最终通过日志中的细节找到根本原因，这正是拥抱 OpenTelemetry 等标准的原因，它旨在标准化这三种数据的生成和关联。