可观测性与传统监控的区别和联系-可观测性的起源

observability-vs-monitoring

核心要点

在服务器运维和稳定性保障领域，传统监控长期承担着发现异常、发送告警和支撑排障的职责。随着云原生、微服务、多云和混合云架构普及，系统之间的依赖关系变得更复杂，可观测性（Observability）逐渐成为技术团队讨论的重点。

两者不是互相否定的关系。传统监控解决“已知风险是否发生”，可观测性解决“复杂系统发生异常时，能不能继续追问和定位”。理解这个区别，才能避免把可观测性简单理解成“换一套监控平台”。

可观测性是软件开发和系统构建中的一个核心理念，关注的是对系统内部状态和运行行为的度量与推断。它通常涵盖日志记录、性能指标、链路追踪、事件等多个维度，目标是让技术团队能够从系统外部输出中理解内部状态。

可观测性的概念最早可追溯至 1960 年，由 Kálmán 在论文中提出，用于描述数学控制系统的特性。在控制论领域，可观测性被定义为从系统外部输出推断其内部状态的能力度量。这个理念后来被引入软件开发和系统运维领域。

尽管传统监控与可观测性的核心目标相同，都是及时、准确地掌握系统运行状况、提升控制能力，但两者在实践中效果不同。随着技术架构演进，传统监控的局限主要体现在四个方面。

传统监控依赖预设指标、告警策略和仪表盘。这种方式适合已知问题，但对未知故障支持有限。团队为了覆盖更多风险，往往不断增加监控和告警，最终可能形成告警风暴。

在传统监控中，告警信息经常孤立存在。值班人知道某个指标异常，却不一定能快速判断它对用户体验、业务流程和上下游依赖的实际影响。这会导致应急资源分配不准、协同效率低下。

传统监控往往在系统开发完成后才被补上，采集方式多是外挂式脚本、日志匹配或进程探测。开发和维护职责分割后，系统内部状态没有在设计阶段主动暴露，后续排障就会非常被动。

传统监控主要关注基础设施和 Metrics。面对单体系统或变化较慢的基础设施时，这种方式很有效。但在云原生和微服务环境中，应用之间的依赖关系更复杂，仅靠基础设施指标很难全面反映系统状态。

可观测性强调在系统设计之初就考虑内部状态和行为的暴露，通过 Metrics、Logging、Tracing、Events 等多种数据维度实时展现系统运行状态。这样，观测能力不再是事后补救，而是系统能力的一部分。

在可观测体系下，应用开发者承担更多主体责任，维护者和 SRE 则使用这些数据进行故障发现、定位和恢复。这种面向应用的方式，更适合云原生和微服务模型。

可观测性不仅要具备指标、日志、链路追踪等数据，还要建立跨业务、跨系统、跨资源的数据关联和探索能力。它的目标是支撑复杂系统中的问题发现、诊断、定位和恢复。

可观测性和传统监控并不是割裂的。它们背后解决的是同一个问题：及时、准确地掌握系统运行状况，提升对系统运行的控制能力。

可以把传统监控视为可观测性的一部分。监控提供基础信号和告警入口，可观测性在此基础上做更深的数据关联、更广的上下文整合和更强的问题探索。

在可观测性领域，快猫星云提供云原生监控分析平台，帮助企业把指标、日志、链路、事件和告警响应流程组织起来。它的价值不只是展示数据，而是帮助运维、SRE 和研发团队更快掌握系统状态、定位问题并保障业务稳定运行。

用大白话总结：可观测性的出现，核心是为了解决大规模微服务下的定位问题。

单体时代，软件之间联动少，很多系统只要提供几个关键监控指标，出故障时 On-call 工程师根据告警就能定位到进程或机器。微服务时代，一个业务流程可能涉及很多服务，每个服务都可能出问题。真实事故里，经常是定位具体服务花了半小时，止损只花了 5 分钟。

可观测性的价值就在这里：它强调全局视角、数据串联和分析路径，让团队从纷繁复杂的监控数据中更快定位问题，提高故障处理效率。

Q1：可观测性是不是传统监控的新名字？ A：不是。它继承传统监控的目标，但扩展了数据类型、上下文关联和探索能力，更适合微服务和云原生系统。

Q2：已经有监控系统，还需要可观测性吗？ A：如果现有系统能快速回答影响面、上下游依赖、请求路径和变更关联，可能暂时够用。如果事故中经常靠人工在多个工具间拼线索，就需要补可观测性能力。

Q3：建设可观测性应该从哪里开始？ A：不要先追求大而全。可以从一个核心业务链路开始，补齐关键指标、日志、链路追踪、服务标签、告警路由和故障响应闭环。