本文引用自 Cloud Native Daily:Monitoring vs Observability in 2023 — An Honest Take
监控和可观测性有何不同?它们在解决潜在问题方面分别多有效?
如果您正在运行一个软件系统,您需要了解它的运行情况:它的运行情况如何,是否按预期运行,以及是否有任何需要您注意的问题。一旦发现问题,您就需要获取相关信息以便进行故障排除。
众多工具声称可以帮助您实现这一点,包括监控、APM、可观测性以及介于两者之间的一切。这导致了可观测性领域的一场争夺战,监控供应商声称他们也提供可观测性服务,而“可观测性优先”的参与者则不同意,并指责他们掩盖了可观测性。
因此,让我们客观地看待这个问题并回答几个问题:
- 监控和可观测性有何不同?
- 每个方法在解决根本问题方面效果如何?
- 人工智能(AI)现在对这个领域有何影响?接下来会发生什么?
什么是监控?
监控解决方案执行3个简单的操作:
- 提前定义一些「指标」(metrics)
- 部署代理(agents)来收集指标
- 在仪表盘(dashboard)中显示这些指标
请注意,这里的指标是一个简单的数字,它捕捉了系统可量化的特征。我们可以对指标进行数学运算,以获得不同的聚合视图。监控自计算系统兴起以来已经存在了40年,最初是运维团队跟踪其基础设施运行状况的方式。
监控类型
最初,监控主要用于基础设施,用于追踪基础设施的行为——这就是基础设施监控。随着时间的推移,应用程序变得越来越多、越来越多样化,我们也希望对其进行监控,于是出现了一个叫做 APM(Application performance monitoring,应用程序性能监控)的类别。在现代分布式系统中,我们需要监控多个组件——基础设施、应用程序、数据库、网络、数据流等等,而我们需要的指标因组件而异。例如:
- 基础设施监控:正常运行时间、CPU 利用率、内存利用率
- 应用程序性能监控:吞吐量、错误率、延迟
- 数据库监控:连接数、查询性能、缓存命中率
- 网络监控:往返时间、TCP 重传、连接流失
这些指标是普遍认为与该系统相关的衡量标准,并且大多数监控工具都预先构建了代理,这些代理知道要收集哪些指标以及要显示哪些仪表板。
随着分布式系统中组件数量的成倍增长,指标的数量和种类也呈指数级增长。为了管理这种复杂性,出现了一套独立的工具和流程,它们在传统监控工具的基础上进行了扩展,包含时间序列数据库、SLO 系统和新的可视化功能。
区分监控
尽管如此,监控系统的核心功能保持不变,并且可以通过以下方式明确区分监控系统:
- 它捕获预定义的数据
- 收集的数据是指标(数字)
监控的目标
监控在故障治理体系中,起故障发现作用。
监控工具的目标是当系统中发生意外情况时提醒我们。
这类似于年度体检——我们测量一系列预先定义的值,这些值将为我们提供身体的整体图像,并让我们知道是否有任何特定的子系统(器官)出现异常行为。
就像年度体检一样,监测工具不一定能提供任何关于意外 原因 的额外信息。为此,我们可能需要更深入、更有针对性的测试和调查。
经验丰富的医生或许仍然能够仅凭整体测试来诊断病情,但这并不是该测试的设计目的。监测解决方案也是如此。
什么是可观测性?
与监控不同,可观测性的目标比较模糊,因此更难定义。它的目标是:帮助我们理解某些行为为何会异常。
日志是自 70 年代以来一直在使用的原始可观测性工具。直到 21 世纪初,我们的工作方式是:
- 传统的监控系统在出现问题时发出警报
- 日志可以帮助我们了解原因
然而,在过去的 15 年里,我们的架构变得异常复杂。手动搜索日志来找出问题所在几乎变得不可能。与此同时,随着业务数字化程度的提高,我们对宕机的容忍度也急剧下降,我们再也无法承受花费数小时来理解和修复问题。
可观测性的 traces 在中文表述上没有统一,本文采纳阿里云的表达:链路追踪,称为链路、调用链、跟踪、追踪、分布式跟踪也是可以接受的。
我们需要比现有数据更多的数据,以便更快地解决问题。这催生了可观测性行业的兴起,其目的是帮助我们更轻松地理解系统出现问题的原因。这始于一种名为「链路追踪(traces)」的新数据类型的出现,我们称可观测性的三大支柱为:指标、日志和链路追踪。从那时起,我们不断添加新的数据类型,以提升可观测性。
可观测性的问题
可观测性的根本问题在于:事先并不知道可能需要哪些信息,需要的数据取决于具体问题。生产错误的本质在于它们是不可预测的,并且具有长尾效应:如果它们能够被预见,那么早就被修复了。
这就是可观测性模糊的原因:对于需要捕获什么以及捕获多少,没有明确的范围。因此,可观测性变成了「任何可能帮助我们理解正在发生的事情的数据」。
如今,描述可观测性实现的最佳方式是——「指标之外的一切,加上指标」。
(维基百科)遥测数据:遥测是指传感器在测量现场收集测量对象的数据后,数据通过无线传输(例如无线电、超声波或红外线、电话或计算机网络、简讯和GSM等各种方式传送至远距离的接收设备以供监测人员监测。
CNCF OpenTelemetry:三大支柱,指标、日志和链路。
一个完美的可观测系统会记录生产过程中发生的一切,不留任何数据缺口。值得庆幸的是,这不切实际,成本高昂,而且 99% 的数据根本无关紧要,因此,一个普通的可观测平台需要对采集哪些遥测数据以及采集多少遥测数据做出复杂的选择。不同的供应商对此有不同的看法,而且,根据你询问的对象,可观测性似乎也略有不同。
常见的可观测性描述毫无帮助
可观测性的常见表述,例如“可观测性是能够通过系统的外部输出观察其内部状态”,很模糊,既没有清楚地表明它是什么,也没有指导我们判断我们是否具有足够的可观测性来满足我们的需求。
此外,大多数常用的、旨在区分可观测性和监测性的标记也非常模糊,甚至完全具有误导性。让我们来看几个例子:
1. 「监控是预先定义的数据;可观测性不是」
实际上,如今我们在可观测性解决方案中捕获的几乎所有内容也都是预先确定的。我们预先定义要捕获哪些日志、要捕获哪些分布式跟踪(包括采样机制)、要附加到每个分布式跟踪的上下文,以及何时捕获堆栈跟踪。
我们尚未进入根据生产中实际情况有选择地捕获数据的工具时代。
2. 「监控是简单的仪表板;可观测性是更复杂的分析和关联」
这是另一个在实践中尚未兑现的承诺。
如今,大多数可观测性平台也仅仅提供仪表盘——只不过它们的仪表盘显示的数据比指标多(例如,日志的字符串),或者可以根据用户指令拉取不同的图表和视图。我们还没有能够独立进行任何有意义的关联上下文分析,从而帮助我们更快地理解问题的工具。
能够使用唯一 ID 连接日志和链路追踪并不算复杂的分析或关联,尽管所需的工作量可能并不小。
3. 「监控是被动的,可观测性是主动的」
我们收集的所有可观测性数据都是预定义的,并且我们目前在生产中所做的几乎所有事情(包括与可观测性相关的)都是被动的。主动的部分是我们在测试时所做的。在生产中,如果出现故障或出现意外情况,我们会做出响应并进行调查。
我们最多只能使用可能算得上主动型的 SLO 系统。使用 SLO 系统时,我们会预先定义错误预算,并在超出该范围之前采取行动。然而,SLO 系统与监控工具的耦合度更高,因此监控和可观测性解决方案之间的区别并不十分重要。
4. 「监控侧重于单个组件;可观测性揭示了组件之间的关系」
之所以这样区分,只是为了使可观测性与分布式追踪成为同义词。分布式追踪只是另一种数据类型,用于展示跨组件的关系。如今,分布式追踪需要与其他数据结合使用才能真正发挥作用。
(有关更多信息,请阅读这篇探讨分布式追踪真正效用的文章)
总而言之,我们的类别定义不清,没有明确的界限。然后,我们编造了一些模糊且不太有用的标记,以将该类别与之前存在的监控区分开来。这种说法旨在告诉我们,距离实现「真正的可观测性」总是有一段距离——而且总是需要再买一个工具。因此,我们不断扩展可观测性所需的范围。
这有什么影响?
可观测性的数据类型列表不断增加
所有遥测数据都具有可观测性,因为它可以帮助我们「观察」系统的状态。
日志符合可观测性吗?是的,因为它们可以帮助我们了解生产环境中发生了什么。
分布式跟踪符合吗?是的。
捕获异常堆栈跟踪的错误监控系统呢?是的。
实时调试系统呢?是的。
持续性能分析器呢?是的。
指标呢?同样符合,因为它们也有助于我们了解系统的状态。
可观测性数据量不断增加
捕获多少数据由客户决定,尤其是在监控之外。您想要记录多少日志,想要捕获多少分布式跟踪,想要捕获并存储多少事件,以什么间隔,持续多长时间——所有这些都是悬而未决的问题,对于多少数据是「合理的」,以及在什么情况下捕获的数据可能过多,相关的指导非常有限。公司在可观测性方面的投入可能高达 100 万美元,也可能高达 6500 万美元;这完全取决于谁来构建什么样的业务案例。
工具扩张和支出增加
以上所有因素都导致了可观测性支出的快速增长。如今,大多数公司使用五种或更多的可观测性工具,而监控和可观测性通常是公司基础设施支出中第二大的部分,仅次于云基础设施本身,市场规模约为170 亿美元。
恐惧和损失厌恶是可观测性扩展的潜在驱动力
采用所有这些工具的根本驱动力是人类的恐惧——「如果出现问题,而我没有足够的数据来排除故障怎么办?」这是每个工程团队最可怕的噩梦。这自然会促使团队每年收集越来越多的遥测数据,以获得更安全的感觉。
然而,全球平均修复时间 (MTTR) 似乎在增加
人们可以预期,随着可观测性的广泛采用以及各种可观测性数据的积极捕获和存储,MTTR 将在全球范围内大幅下降。
相反,这一数字似乎还在增加,73% 的公司需要一个多小时来解决生产问题(而两年前这一比例仅为 47%)。
尽管投入了大量资金,但我们似乎最多只是取得了一些渐进的进展。
我们现在在哪里?
到目前为止,我们持续收集越来越多的遥测数据,希望处理和存储成本能够持续下降以支持这一目标。但随着数据量的激增,我们遇到了成本之外的新问题,那就是可用性。人类已经无法直接查看数十个仪表板并快速得出结论。因此,我们创建了不同的数据视图和切分方式,以便用户更轻松地测试和验证他们的假设。但这些工具对于普通工程师来说过于复杂,我们需要经过专门培训的「高级用户」(类似于数据科学家),他们能够熟练地驾驭这些海量数据并识别错误。
如今,许多可观测性公司都采取了类似的方法:捕获更多数据,进行更多分析,并培训能够使用这些工具的高级用户。但这些专业工程师缺乏关于系统各个部分的足够信息,因此无法生成足够好的假设。
与此同时,普通工程师仍然严重依赖日志来调试软件问题,而平均修复时间 (MTTR) 却未取得任何显著改善。因此,所有可观测性工作看起来都像是一项高投入、高成本的活动,却只能让我们在架构复杂度迅速增长的同时,停滞不前。
那么下一步是什么?
推理——可观测性之后的下一个阶段?
为了真正理解下一代工具的本质,我们先来了解一下所有这些工具的根本目标。它旨在确保生产系统健康运行,并按预期运行。如果出现任何问题,我们也能快速了解原因并解决问题。
如果我们从这里开始,我们可以看到工具如何支持我们有三个不同的层次:
- Level 1:「当我的系统出现问题时告诉我」——监控
- Level 2:「告诉我为什么有些事情不对劲(以及如何解决它)」——我们称之为推理
- Level 3:「自己修复,然后告诉我你做了什么」——自动修复
传统的监控工具在 Level 1 上表现还算不错,可以帮助我们发现问题。我们还没有达到 Level 2,即系统能够自动告诉我们问题发生的原因。
因此,我们引入了一套称为可观测性的工具,它位于 Level 1 和 Level 2 之间,通过为我们提供更多数据来帮助理解为什么会出现故障。
推理:可观测性 + AI
我认为可观测性之后的下一步是推理——平台能够合理地解释错误发生的原因,以便我们能够修复它。随着过去几个月人工智能模型的快速发展,这一目标在 2023 年将成为可能。
设想一个解决方案:
- 自动显示需要开发人员立即关注的错误
- 准确地告诉开发人员问题的原因和问题所在:这个 pod、这个服务器、这个代码路径、这一行代码、针对这种类型的请求
- 指导开发人员如何修复它。
- 利用开发者的实际行动不断改进其建议。
这个领域有一些早期的活动,包括像ZeroK这样的公司,但这是一个开放的领域,我们可以预期未来几年将有几家新公司出现。
避免 AIOps 陷阱
在任何围绕 「AI + 可观测性」的讨论中,务必记住,AIOps 此前也曾尝试过,但收效甚微。要了解原因,请阅读:AIOps已死。
对于推理解决方案而言,避免 AIOps 的陷阱至关重要。为此,推理解决方案必须针对 AI 用例进行彻底的架构设计,也就是说,数据收集、处理、存储和用户界面都必须针对 AI 可能引发的根本问题进行彻底的设计。
它可能不会是这样的,即在现有的可观测性工具和现有的可观测性数据之上添加 AI,仅仅因为这是我们在 AIOps 上尝试过但失败了的事情。
请参阅此处以更详细地了解基于 AI 的推理解决方案:www.zerok.ai/post/infere…
结论
我们探讨了监控和可观测性以及它们之间的区别。我们研究了目前可观测性定义不清、界限模糊的问题,这导致了数据、工具和支出的失控蔓延。与此同时,人工智能的最新进展可以通过基于人工智能的新型推理解决方案来解决我们目前在可观测性方面面临的一些问题。