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

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 可观测性和传统监控的三大区别

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

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

传统监控的问题排查方法

1、构建仪表盘

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

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

2、使用仪表盘定位故障

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

通过数据来进行故障排查

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

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

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

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

相关文章
|
2月前
|
运维 监控 Cloud Native
|
1月前
|
弹性计算 Prometheus 监控
阿里云可观测 2024 年 5 月产品动态
阿里云可观测 2024 年 5 月产品动态。
|
2月前
|
Prometheus 监控 数据可视化
阿里云可观测 2024 年 4 月产品动态
阿里云可观测 2024 年 4 月产品动态。
|
2月前
|
SQL 运维 监控
阿里云可观测 2024 年 3 月产品动态
阿里云可观测 2024 年 3 月产品动态
|
2月前
|
SQL 监控 测试技术
阿里云可观测 2024 年 2 月产品动态
阿里云可观测 2024 年 2 月产品动态
|
2月前
|
人工智能 Prometheus 算法
阿里云可观测 2023 年 12 月产品动态
阿里云可观测 2023 年 12 月产品动态
|
2月前
|
自然语言处理 运维 监控
阿里云可观测 2023 年 11 月产品动态
阿里云可观测 2023 年 11 月产品动态
|
7月前
|
消息中间件 运维 Prometheus
阿里云可观测 2023 年 10 月产品动态
阿里云可观测 2023 年 10 月产品动态
|
9月前
|
SQL Prometheus 监控
阿里云可观测 2023 年 9 月产品动态
阿里云可观测 2023 年 9 月产品动态
1208 6
|
11月前
|
Prometheus 监控 Cloud Native
阿里云可观测 2023 年 7 月产品动态
阿里云可观测 2023 年 7 月产品动态
阿里云可观测 2023 年 7 月产品动态