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

近期交流很多人都在讲可观测性，所以就问了个问题：监控和可观测性的异同是什么？这个问题也让不少人懵圈。监控和可观测性一样吗？似乎也不一样？区别是什么？往往又说不清楚。从词义上理解，监控是一种使用额外的手段和措施采集、展示和跟踪被监控对象的运行状态、指标、历史状况等方法；可观测性则是一种可观测对象从内向外主动暴露其运行状态、指标和数据等的方法。可以说，监控和可观测性的实现思路和方式是不一样，影响也是不一样的。监控和可观测性的思路和方法区分监控和可观测性的最基本方式就是看其实现思路和方法。很多人也提出了很多区别，比如说监控是面向基础设施、面向运维、面向故障告警等的被动系统，而把可观测性当作是一个更大的远远超越了传统监控所能覆盖的范围的、一种新的采集和分析数据、以及利用数据进行软件研发协同的能力的主动系统。这都没有触及核心，虽说对监控和可观测性区别有了一定的认识，但没有从本质上区分监控和可观测性。监控往往是通过外部强制的手段来获取对象的运行状态、指标数据等。一个对象（可能是系统、平台、基础设施、中间件工具等）具备可观测性，一定不需要从外通过工具来采集数据。一个对象的可观测能力，体现了这个对象对外暴露信息的程度。监控和可观测性一个是去采集回来，类似于request-response方法，一个主动发布，有需要都可以接收并用来展示、跟踪、分析、计算等，类似于publish-subscribe方法。所以监控和可观测性的实现思路和方式是有区别的，并不是简单的是新瓶旧酒。从外部采集监控数据，往往是局部的、表面的，因为对一个监控对象来说，外部是很难对监控对象内部的结构有深入的认识，所以监控不能很好的解决体系化、复杂系统的运行状况跟踪、分析问题，遇到异常问题时也比较难进行定位和解决。所以随着分布式系统的发展要求，监控的思路有了变化。我曾在《基于系统融合的统一监控平台设计》也提出过由内向外发布系统的运行状态、运行指标、日志等的思路，可以说可观测性的提出是分布式复杂系统融合过程中的可见、可跟踪、敏捷定位分析等的要求。对于展示、跟踪、分析、告警等系统来说，数据获取方式的不同，也会带来数据和影响的差别。用传统监控采集方式，类似于定向Request-Response，采集什么样的数据完全是采集方决定的（但也可能采集不到），可能存在重复采集、抢夺资源、影响监控对象运行的状况。而可观测方式，数据是被观测对象主动发布publish，由任何需要这些数据的接收端（也可能是监控终端）通过subscribe方式获取，收集而不是采集，不会影响到监控/观测对象的运行，不过获取的数据取决于可观测对象对外暴露的数据能力。所以观测对象的可观测性是需要对象自身来实现的，体现了该对象的可观测性程度。可观测性面向整个体系单一一个应用或系统的可观测能力可能是不够的，特别在复杂的分布式集成体系或融合系统中，依然需要分层、分段、分角色权限来实现数据的收集、关联、分析、计算、展示、下钻等能力。以前监控往往关注的是单体系统或者单一系统的状况，而可观测性通常需要实现自上到下、从左到右、从前到后整个体系全方位的可见性。依然需要以应用为中心实现从前端访问到底层资源的可见性、可关联性、可分析性和可下钻敏捷定位闭环。我在《系统融合之统一监控平台》中从系统融合的统一监控的视角来看待应用系统监控体系的建设，提出了纵向分层、横向分段、侧向管控的思想。如果将数据采集方法改为数据收集方法，就可以不用agent、探针、Daemonset等工具，简化系统的设计和实现。而数据的存储、分析、计算、展示等并没有区别，甚至告警的规则都不需要变。这也是往往说不清楚监控和可观测性区别的一个原因。传统单体系统的监控通常是运维侧来实现，所以更多关注的是资源、运行状态、日志等，单体系统往往也难以打通和其他系统的联系，所以往往无法下钻分析，无法有效关联，往往难以形成闭环。而在当前数字化高度关联、复杂的集成系统或融合系统，则强调自上而下以应用为中心的体系化监控（或可观测能力）建设，从渠道前端到中间服务（包含可复用中台服务）、中间件、后端服务，以及运行这些服务的平台、后端数据库，这些支撑平台和数据库所在的软硬件基础设施等，作为一个整体来看待，从应用终端请求失败可能敏捷一步定位到资源扩容失败，或数据库响应超时等。而无需一步步协调相关团队或部门进行问题分析和定位。这也是企业数字化转型和数字化智能化运维的要求。可观测性是数字化时代的应用系统之间互联互通实现敏捷跟踪、实时分析、响应告警等的要求，是数字化的一部分能力。数字化要求企业各系统之间需要形成联动，不再是一个个独立的单体，因此各业务系统、平台工具系统、资源系统等需要无缝融合，成为一个有机的融合整体，如同变形金刚，按需而变，按需而响应。传统监控Request-Response的方式不够敏捷，所以监控体系的建设思路需要变革。可观测性可覆盖DevOps生命周期很多人把研发效能指标等都纳入可观测性。我觉得都没问题。应用的可观测能力是需要在应用设计开发阶段考虑并实现。不过这跟研发效能指标是两回事。研发效能指标需要研发体系的支撑，应用的可观测性需要运维体系的支撑，这就覆盖率整个DevOps研发运维生命周期过程。可观测性关注的是应用本身，当然支撑应用的整个体系都需要具备可观测性。这样应用出现异常时才能快速知道是应用本身的问题，还是支撑应用的基础设施的问题。很多鼓吹DevOps已死的人就在于把DevOps过程和DevOps支撑体系割裂开来看待。DevOps落地不顺利在于其支撑体系不完善，需要先建设基础的支撑平台（也就很多人鼓吹的平台工程），而可观测性就是这整个体系中指标、日志、链路等的可见、可分析、可跟踪、可响应等能力的集合。可观测性能力需要实现分析、计算、跟踪、响应等能力，但它并不是一个数据分析平台，它最重要的是运行时可见，包括运行状态、运行指标、运行日志、执行链路、运行趋势、影响分析等。可观测性从业务运营视角关注的是业务运行的相关数据；从应用运维视角，关注的是系统运行数据；从研发视角，需要同时关注运营和运维数据，确保业务应用在业务上和技术上的实现都是正确的。而这些数据的评估和校验则需要研发、运维整体的支撑，包括DevOps生命周期过程和支撑DevOps的平台工程体系。监控和可观测性都是一个动态的过程，都需要体验良好的图形界面的展示和交互。所以在终端展示上可观测性和传统监控并没有太大区别。通过角色权限控制，也可以区分或限制用户的可见范围（这是一个难点，特别在云上部署，跨多层系统调度调用，所以很多人也不提这点）。研发人员也可通过终端了解自己参与研发的系统的运行情况，这些数据也是研发效能的指标之一，协助研发人员完善应用功能、性能、可观测性能力等，养成良好的研发习惯，持续提升自己的研发能力。监控和可观测能力并行监控和可观测性的本质区别在于数据采集或收集的方式，也就是数据获取的方式和思想不同了。至于说监控和可观测性的边界和范围，其实并不绝对。也不是说监控就一定面对资源、面向告警的，监控同样可以面向应用，以应用为中心实现监控体系。可观测能力的建设面临着庞大存量系统的压力。数据用采集或者收集还好处理些，存量系统的改造是个难题。很多新兴互联网公司具备后发新技术新理论优势，所以他们在建设可观测能力时相对更容易。也因此，对于很多老公司来说，适合采用新系统新方法，老系统老办法。对于新建系统，可在规划实施之前就考虑好可观测性能力，而对于需要集成的老系统，通常还是需要通过agent、探针等方法来采集相关数据。所以在相当长一段时间内，可能监控和可观测能力并行，但这并不方案企业级监控系统或