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

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

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

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

传统监控的问题排查方法

1、构建仪表盘

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

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

2、使用仪表盘定位故障

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

通过数据来进行故障排查

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

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

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

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

相关文章
|
SQL 存储 监控
深入可观测底层:OpenTelemetry 链路传递核心原理
本文会系统讲解链路传递一些基本概念,同时结合案例讲解链路传递的过程。
3680 1
深入可观测底层:OpenTelemetry 链路传递核心原理
|
运维 安全 Cloud Native
Apsara Stack 技术百科 | 混合云全景智能化观测平台Sunfire
在企业数字化转型的浪潮中,核心业务的上云和迁云无疑是转型过程的重中之重,企业对于数字安全性及等保合规层面的需求也日益强烈,混合云成为诸多大型政府企业客户上云迁云的首选方案。随着企业云上业务的复杂化,云上云下技术栈的多样化,以及云上运维组织规模的扩大化,云上业务的稳定性和连续性面临着巨大的挑战。
4205 0
Apsara Stack 技术百科 | 混合云全景智能化观测平台Sunfire
可观测性简史-可观测性价值精讲ppt-业务系统的护城河
可观测性价值精讲,文末随附可观测性简史,可以快速注册体验可观测性平台,构建业务系统的护城河,指标体系和价值体系
618 1
|
7月前
|
人工智能 运维 监控
云+应用一体化可观测:破局“云上困境”,让运维驱动业务增长
当云计算迈入深入上云新阶段,数智化升级的关键课题已从“简单上云”演进至“精细治云”。随着企业对云计算的依赖日益加深,如何高效管理云端资源及其稳定性成为新的挑战。为此,阿里云推出云+应用一体化可观测方案,通过阿里云应用运维平台(Application Operation Platform,简称“AOP”)构建覆盖应用全生命周期一体化可观测产品体系,推动运维模式由被动响应向主动预防转变,实现故障的快速发现、定界与恢复,保障云上业务稳定运行。 目前,该方案已成功服务超过50家行业头部客户,为政务云平台、金融核心系统、能源调度中枢等关键基础设施提供全天候安全运维保障。
482 0
YOLOv11改进策略【Head/分割头】| 结合CVPR-2024 中的DynamicConv 动态卷积 改进分割头, 优化模型(独家改进)
YOLOv11改进策略【Head/分割头】| 结合CVPR-2024 中的DynamicConv 动态卷积 改进分割头, 优化模型(独家改进)
1027 8
|
Kubernetes 应用服务中间件 nginx
k8s学习--k8s集群使用容器镜像仓库Harbor
本文介绍了在CentOS 7.9环境下部署Harbor容器镜像仓库,并将其集成到Kubernetes集群的过程。环境中包含一台Master节点和两台Node节点,均已部署好K8s集群。首先详细讲述了在Harbor节点上安装Docker和docker-compose,接着通过下载Harbor离线安装包并配置相关参数完成Harbor的部署。随后介绍了如何通过secret和serviceaccount两种方式让Kubernetes集群使用Harbor作为镜像仓库,包括创建secret、配置节点、上传镜像以及创建Pod等步骤。最后验证了Pod能否成功从Harbor拉取镜像运行。
2552 0
|
物联网 5G UED
深入解析载波聚合及其对无线通信性能的提升
深入解析载波聚合及其对无线通信性能的提升
2051 1
|
Ubuntu Linux 网络安全
Linux系统通过fail2ban对暴力破解进行防护
Linux系统通过fail2ban对暴力破解进行防护
590 3
|
存储 SQL 分布式计算
大数据-142 - ClickHouse 集群 副本和分片 Distributed 附带案例演示
大数据-142 - ClickHouse 集群 副本和分片 Distributed 附带案例演示
1412 0
|
网络协议 安全 生物认证
一文带你从了解到精通Nmap扫描器
一文带你从了解到精通Nmap扫描器