111 lines
14 KiB
Markdown
111 lines
14 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
03 相互对比：可观测性和传统监控有什么区别？
|
||
你好，我是翁一磊。
|
||
|
||
上节课，我们了解了可观测性的基本概念，这节课我们重点介绍在进行调试或者问题排查的时候，使用可观测性工具和使用传统监控工具有什么不同。通过这种对比，相信你可以更好地理解可观测性和传统监控的区别。
|
||
|
||
传统监控的问题排查方法
|
||
|
||
构建仪表盘
|
||
|
||
从运维的角度来看，肯定少不了通过仪表盘来对系统进行监控。传统的监控系统主要用于收集和汇总一定时间间隔内的性能指标，运维同学需要依靠这些指标的变化趋势来分析系统的性能，基于过往的经验判断系统是否正常，哪里可能有问题；或者通过设定监控指标的阈值进行告警。
|
||
|
||
将这些指标以图表形式展现出来，各种各样图表的组合以及自定义的视图便构成了一个个仪表盘。我们通常会为每一个系统服务设置一个静态的仪表盘，通过它了解系统的运行状态。
|
||
|
||
然而，当我们在审视仪表盘的各项视图，或是收到告警的时候，我们知道某项指标超出了阈值（比如生产环境的集群 CPU 平均使用率超过了 90%），但却不能完全了解系统究竟发生了什么。换句话说，不知道是什么导致了 CPU 的平均使用率过高。
|
||
|
||
另一方面，当我们想使用仪表盘来进一步分析问题的时候，会受制于这些仪表盘的预设条件，只能查看预设的维度；如果想分析其他的维度，可能就进行不下去了。因为这个维度的标签很可能并没有提前被添加进来，也就不能提供数据的聚合了。
|
||
|
||
使用仪表盘定位故障
|
||
|
||
让我们再来看一个更加具体的例子。如果你是运维工程师，你应该会很熟悉下面这样的场景。
|
||
|
||
这是一个工作日的早晨，你坐到办公桌前，打开电脑，首先要做的事情就是看一下目前系统的整体情况。于是你开始浏览一组配置好的仪表盘，或者一个大屏，希望可以快速地看到系统的各个方面、各种组件以及它们的健康状态。
|
||
|
||
你查看着仪表盘上的各个图表和相关指标，突然发现仪表盘左下角某个区域的曲线超过了设定的基线，根据你的经验，你会感觉这是数据库的问题，因为之前也发生过类似的症状。于是你快速地查看了一下数据库的状态，想要确认你的怀疑。果不其然，你的怀疑被证实了，紧接着你马上处理和解决了问题。
|
||
|
||
类似地，你的脑海中可能还记录了很多发现问题模式的组合。随着时间的推移，你已经学会了通过观测仪表盘中的各种特定指标来预测问题的来源。你可以问问自己，在排查故障的全过程中，当你在系统的各个组件之间跳转的时候，你在多大的程度上依赖这些模式的组合甚至说是你的直觉？通常，我们重视这种直觉，多年来也确实证实它可以给我们带来很多便利和好处。
|
||
|
||
使用传统监控排查故障的局限性
|
||
|
||
然而现如今，随着容器化的趋势、容器编排平台（例如 Kubernetes）的兴起、系统架构向微服务的转变、混合持久化（多种数据库，消息队列）的普遍使用，同时服务网格的引入、自动弹性伸缩实例的流行，甚至是无服务器（Serverless）的出现以及无数相关的 SaaS 服务的涌现，要将这些不同的工具串在一起形成一个现代系统体系结构，可能意味着一个请求在到达你控制的代码时，已经执行了多次跳转。
|
||
|
||
在云原生系统中，进行调试最困难的不再是理解代码的运行方式，而是找到有问题的代码在系统中的位置。这时候，通过仪表盘来查看哪个节点或服务速度较慢是不太可能的，因为这些系统中的分布式请求经常在不同的节点中循环，要在这些系统中找到性能瓶颈非常具有挑战性。当某个组件或者服务变慢了，一切都变慢了。
|
||
|
||
更有挑战性的是，因为云原生系统通常作为平台运行，代码可能存在于你甚至无法控制的系统中（比如云上的云原生服务或是 PaaS 资源）。
|
||
|
||
在现代世界中，每个请求都有可能跨越任意数量的服务和机器，这让与这些请求相关的几十个指标产生分裂，如果我们想推断在这个过程中各种请求跳转发生了什么，就必须将这些相关的指标都连接起来。而如果继续通过传统的设定阈值的方式进行故障定位，除非你能提前了解可能会在哪些节点出现问题，否则你将完全不知道故障是如何发生的，甚至都没法设定相关的阈值。
|
||
|
||
传统监控只能解决 Known-Unknowns的问题
|
||
|
||
这种传统的监控方法是完全被动的，但是许多团队接受并且一直在使用这种最简单的方法排除故障。所以你会发现，有时候自己总是在被动响应、不停地四处灭火。
|
||
|
||
由于业务架构微服务化，加上日益普及的敏捷开发模式，业务的迭代速度变得非常快，这会导致仪表盘中配置的各种指标随着时间快速失效。结果就是，以往的告警和经验模式逐渐失去作用。每次出现故障，复盘的结果就是再增加一些指标或是一些告警，然而这些告警将来可能再也不会被触发。
|
||
|
||
因为本质上来说，依赖传统的监控系统，解决的是 Known-Unknowns 的问题（即你能够感知、但是不理解的问题）。比如说 CPU 使用率达到 90% 触发了告警，但却不清楚是什么原因导致了 CPU 的使用率如此之高。对于越来越多第一次发生的事情，你不可能知道这些本来你就不知道的情况，即 Unknown-Unknowns（即你既不理解、也没有感知的问题）。
|
||
|
||
从过去的经验来看，我们面对的系统往往是一个单一的应用，系统的所有组件可能都是我们自己部署的，我们对它们非常熟悉和了解。你可以把不同来源的数据通过直觉整合起来，形成自己对问题的判断。
|
||
|
||
在过去很长一段时间里，我们都认为它是最正常的运维行为。然而，监控毕竟是一种被动反应性方法，它最适合检测已知的问题和过去遇到过的情况。但是，随着系统复杂性的不断增加，系统性能问题的背后，涉及越来越繁多的相关性和可能性，很多问题超出了任何个人或团队能够直观理解的范畴，所以是时候引入突破这种被动和限制性的工具和方法了。
|
||
|
||
通过可观测性进行问题排查
|
||
|
||
这时候可观测性就该出场了。可观测性的概念我们前面也讲过，它的重点就是通过查看和分析高维度和高基数数据，发现埋藏在复杂系统架构中的隐藏问题，而且不需要事先预测问题可能发生在哪里，以及问题发生的模式，这是可观测性和监控的第一个区别。
|
||
|
||
针对应用软件监测，而不仅仅是基础设施
|
||
|
||
可观测性和监控的第二个区别是，关注的维度不一样。监控更加关注基础设施的资源情况，因为监控工具实在太多了。中大型的企业可能要部署多套监控软件，针对不同基础设施、不同的产品组件（例如中间件、数据库等）来使用不同的产品或工具。这种就造成了资源浪费，还会出现学习曲线太长，认知成本、协同成本、系统更新成本太高等一系列问题。
|
||
|
||
将一切整合起来的可观测性就和原来的监控不同了：可观测平台瞄准的恰恰是应用软件本身。可观测性的目标是保障应用软件的可靠性和稳定性，解决的是应用软件在运行时的调试问题。我相信除了运维需要通过可观测性解决系统的问题之外，开发人员也都希望自己能够随时随地调试自己的代码，尤其是生产环境，从而确保系统的可靠性（有关团队合作的一些最佳实践，在后面的课程中我会进一步详细说明）。
|
||
|
||
对于应用程序代码，最重要的指标是用户的体验。底层系统可能基本上是健康的，但用户请求仍然可能因为多种原因而失败。如前几讲所述，分布式系统使这些类型的问题更难检测和理解。所以，使用高基数字段（用户 ID、购物车 ID 等）作为观察特定客户体验的一种方式的能力变得至关重要。尤其是在持续交付的现代世界中，随着新版本代码的不断部署，软件关注点总是在变化和变化。可观测性提供了一种提出适当问题的方法，可以实时解决这些问题。
|
||
|
||
全面收集和关联数据
|
||
|
||
可观测性和监控的第三个区别，体现在数据收集的全面性（不仅仅是指标数据）和关联性上。
|
||
|
||
不论你是运维工程师，还是开发工程师，都可以通过工具或者产品构建自己在线系统的可观测性，我们的最终目标都是用实时的数据来调试自己的线上环境。
|
||
|
||
构建自身系统完整的可观测性需要的能力非常广泛，一般情况下，对于大部分企业来说，这是一个包括数据收集、集成、展示在内的综合性系统工程。它可能涵盖的技术从底层操作系统，到各种语言环境网络协议，甚至还涉及前端用户访问数据，eBPF，Profiling 等等，这是一个非常庞大的知识结构。而且，仅仅收集数据也是不够的，利用数据所提供的可视化、交互性来真正意义上让可观测性落地才是核心。
|
||
|
||
所以从构建可观测性的角度来说，它不仅包括数据收集，还包括数据的一致性和关联关系，这样才能更好地让不同维度的数据通过可视化友好地进行交互。而传统的监控主要还是关注基础设施层面的资源状态和使用情况。
|
||
|
||
通过数据来进行故障排查
|
||
|
||
有了数据，我们就要在这个基础上进行故障排查了。
|
||
|
||
如果只是站在运维监控的角度，可观测性似乎是一个数据量更大更全的、但反而让运维不知道从哪开始的监控系统。但我认为，可观测性强调的是从应用和业务维度，用各种数据垂直且实时地描述这个应用的全貌，它采用的不是传统的分层逻辑，不是用不同的独立的监控系统分开关注每一层的情况（例如基础设施、中间件、数据库、应用服务端代码、客户端等等）。
|
||
|
||
可观测性和传统监控的差异，也解释了为什么很多传统运维的仪表盘在分布式架构中用处越来越小，因为对于复杂系统来说，很多之前没有发生过的问题，单靠仪表盘并不能有效地发现根本原因。而可观测性强调的是高维度和高基数的数据，通过这些数据的关联，可观测允许我们从任何一个角度分析问题，而不是依靠直觉和经验。
|
||
|
||
举个例子，针对一个内存溢出（即我们常说的 OOM）的问题，临时增加内存可能可以解决问题，但这种方式并没有找到问题的根源，下一次这个问题很可能还会出现；根本的解决方法，还是通过可观测性找到导致内存溢出的根本原因，知道是哪个进程有问题，甚至是哪段代码导致的这个问题。
|
||
|
||
可观测性提供了一种不同的诊断方法，它能够帮助你研究任何系统，无论这个系统多么复杂，不需要依靠经验或“直觉”。有了可观测性工具，我们不再只能依赖团队中最有经验的工程师，而是可以全面收集和关联数据，通过探索性的问题来询问系统和应用，通过数据分析和发现来进一步开放式地查询和下钻，直到找到问题或故障的根本原因。
|
||
|
||
小结
|
||
|
||
这节课就讲到这里，我们小结一下。
|
||
|
||
基于监控的调试方法（包括使用指标和仪表盘，结合专家知识对生产环境中的问题进行分类）是软件行业多年以来的一种普遍实践。在数据量有限的单一应用架构时代，考虑到传统系统较为简单，依靠人类的经验和直觉来检测系统问题是高效和有意义的。然而，现代应用基础系统的复杂性和大规模，已经让这种方法越来越站不住脚了。
|
||
|
||
相比较而言，可观测性工具将高基数、高维度的遥测数据放在一起展现，方便我们轻松地进行切片、放大、缩小，或跟随“面包屑”找到最终答案。此外，通过在一个工具中保持这种上下文，问题的分析依靠的就是明确的数据，而不再是经验和直觉了。可观测性将关键知识从最有经验的工程师的头脑中转移到共享现实中，任何工程师都可以根据需要进行探索。
|
||
|
||
在下一节中，我将为你讲解开源和厂商中立的 OpenTelemetry 项目，以及如何通过它来建立可观测性。
|
||
|
||
思考题
|
||
|
||
在这节课的最后，留给你一道思考题。
|
||
|
||
你在平时的工作中，有没有依靠直觉和经验来解决问题的经历？后来问题重现了吗，有没有彻底解决？如果有，你又是如何找到根本原因的？
|
||
|
||
另外，我也想给你推荐一本有关可观测性的书籍，_Observability Engineering_，这个专栏也参考了书中的一些内容。当然，国内外对可观测性的理解和实践都有所不同，我也更多地在专栏中加入了我自己的理解与感悟。有英文功底的同学可以从这里下载电子版进行阅读，相信这本书可以让你了解到可观测性更多维度的知识。
|
||
|
||
如果你有什么新的收获，也欢迎在留言区和我交流，我们下节课见！
|
||
|
||
|
||
|
||
|