监控和可观测性的异同究竟是什么?

【导读】监控和可观测性的异同是什么？这个问题让不少人懵圈。监控和可观测性一样吗？似乎也不一样？区别是什么？往往又说不清楚。【作者】汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。

近期交流很多人都在讲可观测性，所以就问了个问题：监控和可观测性的异同是什么？这个问题也让不少人懵圈。监控和可观测性一样吗？似乎也不一样？区别是什么？往往又说不清楚。从词义上理解，监控是一种使用额外的手段和措施采集、展示和跟踪被监控对象的运行状态、指标、历史状况等方法；可观测性则是一种可观测对象从内向外主动暴露其运行状态、指标和数据等的方法。可以说，监控和可观测性的实现思路和方式是不一样，影响也是不一样的。
监控和可观测性的思路和方法

区分监控和可观测性的最基本方式就是看其实现思路和方法。很多人也提出了很多区别，比如说监控是面向基础设施、面向运维、面向故障告警等的被动系统，而把可观测性当作是一个更大的 远远超越了传统监控所能覆盖的范围的、一种新的采集和分析数据、以及利用数据进行软件研发协同的能力的主动系统。这都没有触及核心，虽说对监控和可观测性区别有了一定的认识，但没有从本质上区分监控和可观测性。监控往往是通过外部强制的手段来获取对象的运行状态、指标数据等。一个对象（可能是系统、平台、基础设施、中间件工具等）具备可观测性，一定不需要从外通过工具来采集数据。一个对象的可观测能力，体现了这个对象对外暴露信息的程度。监控和可观测性一个是去采集回来，类似于 request-response 方法，一个主动发布，有需要都可以接收并用来展示、跟踪、分析、计算等，类似于 publish-subscribe 方法。所以监控和可观测性的实现思路和方式是有区别的，并不是简单的是新瓶旧酒。从外部采集监控数据，往往是局部的、表面的，因为对一个监控对象来说，外部是很难对监控对象内部的结构有深入的认识，所以监控不能很好的解决体系化、复杂系统的运行状况跟踪、分析问题，遇到异常问题时也比较难进行定位和解决。所以随着分布式系统的发展要求，监控的思路有了变化。我曾在《基于系统融合的统一监控平台设计》也提出过由内向外发布系统的运行状态、运行指标、日志等的思路，可以说可观测性的提出是分布式复杂系统融合过程中的可见、可跟踪、敏捷定位分析等的要求。对于展示、跟踪、分析、告警等系统来说，数据获取方式的不同，也会带来数据和影响的差别。用传统监控采集方式，类似于定向 Request-Response ，采集什么样的数据完全是采集方决定的（但也可能采集不到），可能存在重复采集、抢夺资源、影响监控对象运行的状况。而可观测方式，数据是被观测对象主动发布 publish ，由任何需要这些数据的接收端（也可能是监控终端）通过 subscribe 方式获取，收集而不是采集，不会影响到监控 / 观测对象的运行，不过获取的数据取决于可观测对象对外暴露的数据能力。所以观测对象的可观测性是需要对象自身来实现的，体现了该对象的可观测性程度。
可观测性面向整个体系

单一一个应用或系统的可观测能力可能是不够的，特别在复杂的分布式集成体系或融合系统中，依然需要分层、分段、分角色权限来实现数据的收集、关联、分析、计算、展示、下钻等能力。以前监控往往关注的是单体系统或者单一系统的状况，而可观测性通常需要实现自上到下、从左到右、从前到后整个体系全方位的可见性。依然需要以应用为中心实现从前端访问到底层资源的可见性、可关联性、可分析性和可下钻敏捷定位闭环。
我在 《系统融合之统一监控平台》中从系统融合的统一监控的视角来看待应用系统监控体系的建设，提出了纵向分层、横向分段、侧向管控的思想。如果将数据采集方法改为数据收集方法，就可以不用 agent 、探针、 Daemonset 等工具，简化系统的设计和实现。而数据的存储、分析、计算、展示等并没有区别，甚至告警的规则都不需要变。这也是往往说不清楚监控和可观测性区别的一个原因。传统单体系统的监控通常是运维侧来实现，所以更多关注的是资源、运行状态、日志等，单体系统往往也难以打通和其他系统的联系，所以往往无法下钻分析，无法有效关联，往往难以形成闭环。而在当前数字化高度关联、复杂的集成系统或融合系统，则强调自上而下以应用为中心的体系化监控（或可观测能力）建设，从渠道前端到中间服务（包含可复用中台服务）、中间件、后端服务，以及运行这些服务的平台、后端数据库，这些支撑平台和数据库所在的软硬件基础设施等，作为一个整体来看待，从应用终端请求失败可能敏捷一步定位到资源扩容失败，或数据库响应超时等。而无需一步步协调相关团队或部门进行问题分析和定位。这也是企业数字化转型和数字化智能化运维的要求。可观测性是数字化时代的应用系统之间互联互通实现敏捷跟踪、实时分析、响应告警等的要求，是数字化的一部分能力。数字化要求企业各系统之间需要形成联动，不再是一个个独立的单体，因此各业务系统、平台工具系统、资源系统等需要无缝融合，成为一个有机的融合整体，如同变形金刚，按需而变，按需而响应。传统监控 Request-Response 的方式不够敏捷，所以监控体系的建设思路需要变革。
可观测性可覆盖DevOps生命周期

很多人把研发效能指标等都纳入可观测性。我觉得都没问题。应用的可观测能力是需要在应用设计开发阶段考虑并实现。不过这跟研发效能指标是两回事。研发效能指标需要研发体系的支撑，应用的可观测性需要运维体系的支撑，这就覆盖率整个DevOps研发运维生命周期过程。可观测性关注的是应用本身，当然支撑应用的整个体系都需要具备可观测性。这样应用出现异常时才能快速知道是应用本身的问题，还是支撑应用的基础设施的问题。很多鼓吹DevOps已死的人就在于把DevOps过程和DevOps支撑体系割裂开来看待。DevOps落地不顺利在于其支撑体系不完善，需要先建设基础的支撑平台（也就很多人鼓吹的平台工程），而可观测性就是这整个体系中指标、日志、链路等的可见、可分析、可跟踪、可响应等能力的集合。
可观测性能力需要实现分析、计算、跟踪、响应等能力，但它并不是一个数据分析平台，它最重要的是运行时可见，包括运行状态、运行指标、运行日志、执行链路、运行趋势、影响分析等。可观测性从业务运营视角关注的是业务运行的相关数据；从应用运维视角，关注的是系统运行数据；从研发视角，需要同时关注运营和运维数据，确保业务应用在业务上和技术上的实现都是正确的。而这些数据的评估和校验则需要研发、运维整体的支撑，包括DevOps生命周期过程和支撑DevOps的平台工程体系。监控和可观测性都是一个动态的过程，都需要体验良好的图形界面的展示和交互。所以在终端展示上可观测性和传统监控并没有太大区别。通过角色权限控制，也可以区分或限制用户的可见范围（这是一个难点，特别在云上部署，跨多层系统调度调用，所以很多人也不提这点）。研发人员也可通过终端了解自己参与研发的系统的运行情况，这些数据也是研发效能的指标之一，协助研发人员完善应用功能、性能、可观测性能力等，养成良好的研发习惯，持续提升自己的研发能力。
监控和可观测能力并行

监控和可观测性的本质区别在于数据采集或收集的方式，也就是数据获取的方式和思想不同了。至于说监控和可观测性的边界和范围，其实并不绝对。也不是说监控就一定面对资源、面向告警的，监控同样可以面向应用，以应用为中心实现监控体系。可观测能力的建设面临着庞大存量系统的压力。数据用采集或者收集还好处理些，存量系统的改造是个难题。很多新兴互联网公司具备后发新技术新理论优势，所以他们在建设可观测能力时相对更容易。也因此，对于很多老公司来说，适合采用新系统新方法，老系统老办法。对于新建系统，可在规划实施之前就考虑好可观测性能力，而对于需要集成的老系统，通常还是需要通过 agent 、探针等方法来采集相关数据。所以在相当长一段时间内，可能监控和可观测能力并行，但这并不方案企业级监控系统或可观测体系的构建，最终还是要实现企业内系统之间关系的实时动态可见、可关联、可分析、可响应等。可观测性并不是非要重新构建一套可观测系统，或者取代监控系统，而是在系统建设过程中调整监控或可观测数据的获取方式，融合相关的应用、应用支撑平台、基础设施等实现运行时可见、可控、可分析、可响应、可评价等能力， 可以是从局部到整体建设的一个过程。

原题：监控和可观测性
点击阅读原文可到社区原文下留言交流

觉得本文有用，请转发、点赞或点击在看，让更多同行看到

•