监控只是起点：日志、追踪与完整的“可观测性”体系

时间：2025-04-10

编辑：tance.cc

监控日志.png

在网站和应用运维的世界里，“监控”是一个我们再熟悉不过的词。我们使用像 观图数据 (Guantu Data) 这样的工具，来检查网站是否在线 (“通不通”)、响应是否够快、SSL 证书是否有效。这非常重要，是保障服务稳定运行的基础。

但随着系统架构日益复杂（尤其是微服务、云原生应用的普及），仅仅知道“出问题了”往往不够。当警报响起时，我们需要更快、更深入地理解：问题到底出在哪里？为什么会发生？影响范围有多大？ 这就引出了一个更宏大、更全面的概念——可观测性 (Observability)。

简单来说，监控告诉我们系统出了什么问题 (What)，而可观测性则旨在帮助我们理解系统为什么会出问题 (Why) 以及 问题发生的具体路径 (Where)。而基础的监控，正是构建这套完整体系的坚实起点。

什么是可观测性 (Observability)？

可观测性源自控制理论，指的是仅通过观察系统外部输出，就能推断其内部状态的能力。在 IT 系统中，这意味着我们能通过收集和分析系统运行时产生的各种数据，来理解其行为、诊断问题、优化性能。

打个比方：

监控 (Monitoring): 就像汽车仪表盘上的告警灯（水温过高、油量低）。它告诉你有问题。
可观测性 (Observability): 则像是拥有了全套诊断工具（温度计、油量传感器读数、发动机数据流、行车记录仪），让你能理解为什么水温高（是冷却液泄漏还是风扇故障？）、油量低的具体情况（还能开多远？）、以及问题发生的前后关联。

可观测性的“三大支柱”：Metrics, Logs, Traces

业界普遍认为，实现可观测性主要依赖于收集和关联以下三类数据，它们被称为“三大支柱”：

是什么: 可聚合的、带时间戳的数值型数据，反映系统在一段时间内的状态和性能。例如：CPU 使用率、内存占用、请求延迟 (如 TTFB)、错误率、在线用户数、网站可用性百分比等。
作用: 提供系统健康状况的宏观视图，适合仪表盘展示、趋势分析和设置告警阈值。当指标异常时，它是第一个发出信号的“哨兵”。
工具示例及关联: 传统监控工具如 Nagios、Zabbix，以及云监控服务如 观图数据（尤其擅长提供网站可用性、响应时间等关键外部指标）、Prometheus 等。观图数据提供的基础可用性和性能指标，是整个可观测性体系的基石。

是什么: 离散的、带时间戳的事件记录，通常是文本形式。例如：应用程序错误堆栈、用户访问记录、数据库慢查询日志、系统内核消息等。
作用: 提供事件发生的具体上下文。当监控指标报警时（例如错误率飙升），日志能告诉你具体的错误信息、发生时间、相关请求参数等细节，是排查问题根源的关键线索。
工具示例: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Graylog, Grafana Loki。

是什么: 记录一个请求在分布式系统中经过的完整路径。一个 Trace 由多个 Span 组成，每个 Span 代表请求在一个服务或组件中的处理过程及其耗时。
作用: 在微服务或复杂调用链中，追踪能清晰地展示请求的端到端流程，快速定位哪个环节是性能瓶颈或错误来源。
工具示例: Jaeger, Zipkin, SkyWalking，以及遵循 OpenTelemetry 标准的各种实现。

三者如何协同，解决实际问题？

想象一个场景：

监控告警 (Metrics): 观图数据发出告警：结算 API 的 P95 响应时间超过 1 秒。(发现问题)
查看日志 (Logs): 运维人员查看结算 API 的应用日志，发现在告警时间段内出现大量“用户积分服务调用超时”的错误日志。(定位原因方向)
分析追踪 (Traces): 运维人员使用追踪系统，筛选出超时的结算请求 Trace，发现这些请求中，调用“用户积分服务”的那个 Span 耗时特别长，达到了 900ms。(精确定位瓶颈)

通过结合这三者，团队就能快速从“知道出问题”到“知道为什么”再到“知道问题在哪”，从而高效地解决问题。

监控：构建可观测性的第一块基石

虽然日志和追踪能提供更丰富的上下文和调用链信息，但度量/监控永远是可观测性体系不可或缺的起点和基础。