可观测性和传统监控的三大区别

简介: 可观测性和传统监控的三大区别

本文作者翁一磊 观测云产品技术总监。来自专栏《深入浅出可观测性》主要介绍在进行调试或者问题排查的时候,使用可观测性工具和使用传统监控工具有什么不同。

通过这种对比,相信你可以更好地理解可观测性和传统监控的区别。

传统监控的问题排查方法

1、构建仪表盘

从运维的角度来看,肯定少不了通过仪表盘来对系统进行监控。传统的监控系统主要用于收集和汇总一定时间间隔内的性能指标,运维同学需要依靠这些指标的变化趋势来分析系统的性能,基于过往的经验判断系统是否正常,哪里可能有问题;或者通过设定监控指标的阈值进行告警。

将这些指标以图表形式展现出来,各种各样图表的组合以及自定义的视图便构成了一个个仪表盘。我们通常会为每一个系统服务设置一个静态的仪表盘,通过它了解系统的运行状态。

2、使用仪表盘定位故障

然而,当我们在审视仪表盘的各项视图,或是收到告警的时候,我们知道某项指标超出了阈值(比如生产环境的集群 CPU 平均使用率超过了 90%),但却不能完全了解系统究竟发生了什么。换句话说,不知道是什么导致了 CPU 的平均使用率过高。

另一方面,当我们想使用仪表盘来进一步分析问题的时候,会受制于这些仪表盘的预设条件,只能查看预设的维度;如果想分析其他的维度,可能就进行不下去了。因为这个维度的标签很可能并没有提前被添加进来,也就不能提供数据的聚合了。


传统监控排查故障的局限性

在现代世界中,每个请求都有可能跨越任意数量的服务和机器,这让与这些请求相关的几十个指标产生分裂,如果我们想推断在这个过程中各种请求跳转发生了什么,就必须将这些相关的指标都连接起来。而如果继续通过传统的设定阈值的方式进行故障定位,除非你能提前了解可能会在哪些节点出现问题,否则你将完全不知道故障是如何发生的,甚至都没法设定相关的阈值。

其实,传统监控只能解决 Known-Unknowns(即你既不理解、也没有感知的问题)的问题。

在过去很长一段时间里,我们都认为它是最正常的运维行为。然而,监控毕竟是一种被动反应性方法,它最适合检测已知的问题和过去遇到过的情况。但是,随着系统复杂性的不断增加,系统性能问题的背后,涉及越来越繁多的相关性和可能性,很多问题超出了任何个人或团队能够直观理解的范畴,所以是时候引入突破这种被动和限制性的工具和方法了。


通过可观测性进行问题排查

这时候可观测性就该出场了。它的重点就是通过查看和分析高维度和高基数数据,发现埋藏在复杂系统架构中的隐藏问题,而且不需要事先预测问题可能发生在哪里,以及问题发生的模式,这是可观测性和监控的第一个区别

可观测性和监控的第二个区别是,关注的维度不一样。

监控更加关注基础设施的资源情况,因为监控工具实在太多了。中大型的企业可能要部署多套监控软件,针对不同基础设施、不同的产品组件(例如中间件、数据库等)来使用不同的产品或工具。这种就造成了资源浪费,还会出现学习曲线太长,认知成本、协同成本、系统更新成本太高等一系列问题。

将一切整合起来的可观测性就和原来的监控不同了:可观测平台瞄准的恰恰是应用软件本身。可观测性的目标是保障应用软件的可靠性和稳定性,解决的是应用软件在运行时的调试问题。我相信除了运维需要通过可观测性解决系统的问题之外,开发人员也都希望自己能够随时随地调试自己的代码,尤其是生产环境,从而确保系统的可靠性。

对于应用程序代码,最重要的指标是用户的体验。底层系统可能基本上是健康的,但用户请求仍然可能因为多种原因而失败。如前几讲所述,分布式系统使这些类型的问题更难检测和理解。所以,使用高基数字段(用户 ID、购物车 ID 等)作为观察特定客户体验的一种方式的能力变得至关重要。尤其是在持续交付的现代世界中,随着新版本代码的不断部署,软件关注点总是在变化和变化。可观测性提供了一种提出适当问题的方法,可以实时解决这些问题。

可观测性和监控的第三个区别,体现在数据收集的全面性(不仅仅是指标数据)和关联性上。

不论你是运维工程师,还是开发工程师,都可以通过工具或者产品构建自己在线系统的可观测性,我们的最终目标都是用实时的数据来调试自己的线上环境。

构建自身系统完整的可观测性需要的能力非常广泛,一般情况下,对于大部分企业来说,这是一个包括数据收集、集成、展示在内的综合性系统工程。它可能涵盖的技术从底层操作系统,到各种语言环境网络协议,甚至还涉及前端用户访问数据,eBPF,Profiling 等等,这是一个非常庞大的知识结构。而且,仅仅收集数据也是不够的,利用数据所提供的可视化、交互性来真正意义上让可观测性落地才是核心。

所以从构建可观测性的角度来说,它不仅包括数据收集,还包括数据的一致性和关联关系,这样才能更好地让不同维度的数据通过可视化友好地进行交互。而传统的监控主要还是关注基础设施层面的资源状态和使用情况。

通过数据来进行故障排查

有了数据,我们就要在这个基础上进行故障排查了。

可观测性和传统监控的差异,也解释了为什么很多传统运维的仪表盘在分布式架构中用处越来越小,因为对于复杂系统来说,很多之前没有发生过的问题,单靠仪表盘并不能有效地发现根本原因。而可观测性强调的是高维度和高基数的数据,通过这些数据的关联,可观测允许我们从任何一个角度分析问题,而不是依靠直觉和经验。

可观测性提供了一种不同的诊断方法,它能够帮助你研究任何系统,无论这个系统多么复杂,不需要依靠经验或“直觉”。

有了可观测性工具,我们不再只能依赖团队中最有经验的工程师,而是可以全面收集和关联数据,通过探索性的问题来询问系统和应用,通过数据分析和发现来进一步开放式地查询和下钻,直到找到问题或故障的根本原因。

相关文章
|
机器学习/深度学习 并行计算 测试技术
MLX vs MPS vs CUDA:苹果新机器学习框架的基准测试
如果你是一个Mac用户和一个深度学习爱好者,你可能希望在某些时候Mac可以处理一些重型模型。苹果刚刚发布了MLX,一个在苹果芯片上高效运行机器学习模型的框架。
1129 1
|
2月前
|
人工智能 弹性计算 IDE
阿里云 云开发机DevBox 上线!不给你的本地IDE配一台吗?
阿里云云开发机DevBox上线!告别繁琐本地环境配置,1分钟启动云开发环境。 预置多款常用语言、框架和AI工具(如Python、Java、Flask等),本地IDE一键直连快速启动,开发即刻开始!
|
4月前
|
机器学习/深度学习 数据采集 运维
高压电线电力巡检六类目标的图像识别数据集分享(适用于目标检测任务)
本数据集是一个专注于高压电线电力巡检的高质量图像识别数据集,包含2000张高质量图像,覆盖六类典型巡检目标。所有图像均已完成YOLO格式标注,并按照训练集、验证集和测试集进行了合理划分,可直接用于深度学习模型的训练、验证和测试。
|
11月前
|
弹性计算 关系型数据库 数据库
阿里云服务器免费试用相关政策介绍:试用资格、规则与优惠解析
阿里云服务器可以试用吗?不仅是云服务器产品,包括无影云电脑、云数据库 RDS、统型负载均衡 CLB、对象存储 OSS、文件存储 NAS等云产品都是可以试用的。本文将系统梳理阿里云服务器试用的核心规则、适用场景及操作要点,以供参考。
|
存储 消息中间件 监控
Redis Stream:实时数据流的处理与存储
通过上述分析和具体操作示例,您可以更好地理解和应用 Redis Stream,满足各种实时数据处理需求。
1431 14
可观测性简史-可观测性价值精讲ppt-业务系统的护城河
可观测性价值精讲,文末随附可观测性简史,可以快速注册体验可观测性平台,构建业务系统的护城河,指标体系和价值体系
694 1
|
网络协议 Java 应用服务中间件
Tomcat中的WebSocket是如何实现的?
【10月更文挑战第7天】本文介绍了WebSocket在Tomcat中的实现,包括其全双工通信、单个TCP连接、协议升级和事件驱动的特点。通过Spring Boot项目整合WebSocket,展示了如何配置依赖、创建WebSocket处理类和配置类。详细解析了WebSocket的原理,包括ServerEndpointExporter的注册过程和请求处理流程。总结了WebSocket与HTTP请求处理的区别,并提供了进一步学习的资源。
Tomcat中的WebSocket是如何实现的?
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
642 3
|
监控 机器人 Shell
Nightingale——夜莺监控系统部署企业微信机器人告警系【四】
Nightingale——夜莺监控系统部署企业微信机器人告警系【四】
742 1
Nightingale——夜莺监控系统部署企业微信机器人告警系【四】