观点文章｜浅谈云原生软件系统可观测性

CodeWisdom-观点文章

浅谈云原生软件系统可观测性

云原生（Cloud Native）现在已经成为一个很时髦的概念。但凡跟云有一点关系的软件技术似乎不提云原生就落伍了。云原生的主要意思是“云上的原住民”，也就是软件从设计、实现、部署到运行都充分适应云的特点，就跟在某地土生土长、适应本地一切风土人情和生活习惯的本地人一样。与之相对的是那种半路迁移到云上去的软件系统，例如打个war包部署到云虚拟主机上的Web软件系统，这种系统虽然在云上运行但其体系结构以及实现和部署方式都无法充分适应云的特点（例如高度分布式、灵活伸缩、高可用等）。关于云原生的概念有很多解读，比较公认的理解是“微服务+容器化+DevOps+持续交付”。

这两年热起来的另一个与云原生相关的概念是可观测性（Observability）。以微服务体系结构为主要特征的云原生软件系统通过细粒度的服务拆分以及服务的独立开发、交付、部署和伸缩能力极大地降低了单个服务开发的复杂性以及整体系统的可用性和可伸缩性。然而， 复杂性并没有消失而是从单个服务上升到了服务间交互层面上。此外，云原生软件系统的运行环境具有高度的动态性、复杂性和不确定性。这些都使得云原生软件系统运维管理成为巨大的挑战，而可观测性正是与之密切相关的一种技术趋势，特别是对于所谓的智能化运维（AIOps）而言。

本文将从云原生软件生态系统的角度谈谈可观测性的问题，其中有不少是“形而上学”的抽象思考。因此，为了方便理解，本文通篇都以大规模城市运行管理来进行类比，就像我们经常用造桥、造房子比喻软件开发一样（当然现在我们也认识到软件开发跟造桥、造房子其实很不一样）。

云原生软件生态系统

大约从十多年前开始，学术界开始经常提到“软件生态系统”的概念，例如安卓软件生态系统、互联网开放平台生态系统等，甚至同属一个领域的软件产品线应用产品及相关软件资产也构成了一个生态系统。这些例子都符合生态系统（Ecosystem）的概念，即共享一个环境的众多有机体相互独立同时又相互依存或是竞争，构成一个动态变化、自主生长、持续演化的完整系统。

大规模云原生软件系统也是一种典型的生态系统。如下图所示，云原生软件系统由众多的业务服务组成，此外还包括文件存储、数据库、网关、服务注册与发布、消息中间件等基础设施服务。从规模上看，企业云原生软件系统（微服务系统）一般包含几十到几百个服务，而大规模互联网在线服务系统可能会包含几千个服务甚至更多。这些服务由不同的软件开发团队负责开发和维护，一些基础设施服务还有可能来自开源社区或其他外部来源。不同的服务之间相互依存并构成了一个有机的整体，例如上层业务服务依赖于下层基础设施服务、业务服务之间通过各种同步和异步通信手段相互调用。另一方面，不同的服务可以独立开发和演化，在运行时相互隔离并可以独立伸缩，表现出较强的独立性。

云原生软件系统之所以会逐渐成为一种复杂生态系统也与系统边界的问题相关。传统的软件系统和软件开发项目都会定义清晰的系统边界。同一个企业内不同的软件产品和软件项目之间可能存在一些公用的软件开发框架或组件，但边界大体上还是清楚的。与传统的软件系统不同，云原生软件系统是一种在云上部署的线上服务系统，其中所实现的各种服务直接体现企业的业务和技术能力并支撑企业的业务运行。因此，系统中所包含的服务随着企业业务的发展而不断增加或调整，同时服务与服务之间也会根据企业的业务需要而不断整合。例如，前几年一度很火的“中台”很大程度上就是将共性的技术或业务能力沉淀为共享的服务，从而支持各种应用服务的快速开发和演化。这些特点使得云原生软件系统内部的应用和系统边界逐渐模糊，新的应用和业务模式不断在已有的服务基础上自然扩展和生长出来。在此过程中，不同业务和产品部门从自己的角度出发自主推动这一演化过程，企业在很大程度上也会鼓励这种自主创新。以上这些都突出体现了生态系统动态变化、自主生长、持续演化的特点。因此，我们可以看到一些互联网企业的在线服务平台已经实现了不同领域业务部门之间的服务广泛连接和互联互通，并产生了包含数万个服务的大规模服务化生态系统。

这一现象可以类比于大规模城市的发展。城市是一种典型的复杂生态系统。生活于同一个城市中的人以及相关的各种组织共享同样的城市环境以及交通、能源、通信、商业等方面的基础设施。这些人和组织相互依存、相互影响，共同构成了城市生产和生活的繁荣景象。另一方面，虽然城市的整体发展规划明确了各方面基础设施的建设目标以及不同区域的功能定位，但一个城市的繁荣很大程度上还是要依靠各个组织和个人充分发挥自身的聪明才智和自主发展意识。同时，城市的发展也是一种渐进式的生长过程。例如，地铁的延伸以及教育和医疗资源的配套会带动居住社区的发展，并进一步带动周边商业服务的发展，而这种变化又会在一定程度上改变城市的交通流量以及水电煤等方面的能源供给需求。

什么是可观测性

可观测性是一个来自于控制理论的概念，被认为是与可控制性相对的一个概念，即通过可观测性了解被控制对象内部的状态、通过可控制性操控被控制对象的行为。维基百科上对于可观测性的解释是“a measure of how well internal states of a system can be inferred from knowledge of its external outputs”[1]，也就是通过关于一个系统的外部输出的知识推断系统的内部状态的能力。

云原生软件系统是一种复杂的分布式系统，其中包含大量的服务，而每个服务又可以动态创建和销毁大量的服务实例。此外，这些服务实例运行在大量的分布式节点之上，涉及计算、存储、网络等各种资源以及操作系统、虚拟机等各种系统软件，整体运行环境十分复杂。因此，如果想了解软件系统的内部运行状况、及时发现各种异常和问题、快速进行问题诊断和故障根因定位，我们必须要依靠各种可观测性手段。对于分布式系统而言，目前公认的可观测性三大支柱是指标（Metrics）、日志（Logging）和链路跟踪（Tracing）。其中，指标是一种可以进行聚合计算（aggregatable）的度量值，例如服务请求失败率、平均响应时间、每秒查询率（QPS，即Queries-Per-Second）等，有些随时间变化的指标还可以作为时序数据进行分析；日志是一种带有时间戳的离散事件，一般由软件系统内部的日志输出语句产生，可以记录异常抛出、收到请求以及内部处理状态变化等有意义的事件；链路轨迹记录外部请求所引发的服务调用链，即请求是如何在系统内部不同服务之间流动的。需要注意的是，指标和日志都需要关注多个不同层次。指标在资源、服务和业务层三个层次上都存在，例如：资源层指标包括CPU和内存占用率、网络带宽等；服务层指标包括接口调用成功率、平均响应时间等；业务层指标包括平均订单量、平均成功交易量等。日志在基础设施层和应用层都存在，前者的例子包括操作系统、虚拟机、容器以及容器编排管理系统（如Kubernetes）所产生的日志，后者则是由应用开发人员所写的日志语句产生的日志。

Peter Bourgon在“Metrics, tracing, and logging”一文中描绘了三者之间的关系[2]，如下图所示。指标、日志、链路轨迹三者之间存在重叠的部分：日志可以与指标相结合，从日志中抽取特定的事件并得到各种聚合数值，例如单位时间内某类事件发生的数量；链路轨迹可以与指标相结合，产生以请求为基础的度量指标，例如服务调用成功率与平均响应时间等；链路轨迹可以与日志相结合，例如在服务调用链上查看由于相关服务调用产生的日志。当然，也可以把三者都结合起来，例如以请求（Request）为单位对各种类型的日志事件进行聚合计数。

可观测性与监控（Monitoring）密切相关但又有所不同。一般认为监控可以用来发现问题，而可观测性则可以帮助我们分析和定位问题。监控一般有着明确的手段和目标，即针对系统某个方面部署相应的监控手段并根据监控结果发现特定类型的问题。设置这些监控往往需要我们对可能发生的问题及其表现形式有比较清晰的认识。而可观测性则是一个系统的一种全面的能力，要求系统能够充分暴露与系统内部状态相关的信息并以一种高效的方式支持对相关信息的访问。因此，系统在设计和实现时就要考虑如何融入可观测性能力，例如采用分布式链路追踪框架、规范化日志输出内容和格式等。当然，各种监控数据也都可以作为可观测性能力的一部分。

还是以大规模城市运行管理来进行类比。很多城市都在道路上安装了交通违章探头，这些探头一般都有着明确的目的，例如发现超速或者闯红灯的违章车辆；而相应的手段也比较明确，例如通过监控视频检测后再人工确认。这种监控一般都会条块分割，各成体系，难以相互打通。例如，公安交管部门出于查处交通违章的目的设置了交通违章探头，出于路况监控的目的设置了交通流量探头；消防部门出于消防设施保障的目的设置了消防水龙头及水压监测传感器。这些监控手段手段和目的都很单一，难以相互融合。与之相比，现在的一些智慧城市建设已经着眼于建立一个统一的监控数据平台，打破各个信息孤岛，实现城市监控数据的大范围按需融合，这就已经是在从传统的监控到系统的可观测性发展了。

为什么可观测性对于

云原生软件系统很重要

可观测性对于软件系统以及软件工程领域都是一个比较新的概念。为什么在传统的单体软件系统中这个概念没有引起大家的注意呢？这主要是由于系统规模、复杂性以及生态化等多个方面的差异造成的。

首先，传统的单体软件系统规模和复杂度没那么高，开发人员可以通过IDE一次性加载全部或部分代码，并使用断点设置、单步调试等方法定位缺陷的根因和位置。云原生软件系统包含大量分布式的服务，难以一次性加载并进行调试，而且大量的服务间跨进程调用也使得单步调试无法进行。

其次，传统的单体软件系统运行环境的复杂性和不确定性没那么高，故障或问题一般都与代码自身或数据相关，较容易在开发环境下重现问题并进行调试。云原生软件系统往往涉及复杂的大规模分布式运行环境而且其中的服务实例可以动态创建和销毁，因此运行时故障或问题可能与非常复杂的环境因素相关，难以在开发环境中重现。

再次，传统的单体软件系统运行时监控和观测手段较为单一，依赖于代码插桩的动态分析手段开销较大因此在生产环境中使用较少，与此同时软件的模块和组件结构不清晰、隐式交互难以捕捉等问题也限制了可观测性手段的作用。云原生软件系统中各个服务实现了物理隔离，服务间通过跨进程通信进行交互，因此服务间边界清晰、服务间交互以一种显式和外化的方式实现。此外，云原生软件系统持续在线运行，同时有着完善的基础设施支持（例如服务网格，即Service Mesh），因此较容易实现分布式链路追踪、指标和日志监控体系等可观测性手段。

最后，传统的单体软件系统可以以一种自顶向下的方式掌握整体体系结构设计并通过静态分析（例如分析模块和组件间依赖关系）和演化分析（例如分析模块和组件间的演化耦合）实现架构看护，从而确保软件实现与高层架构设计保持一致。作为一种复杂的生态系统，云原生软件系统的持续演化难以通过一种自顶向下的方式进行掌控，各个局部的应用及相关服务以一种相对独立和自主的方式演化。例如，一些大规模微服务系统中出现长达四五百跳的服务调用链路以及依赖环路，这并不是因为开发人员技术能力和经验不足，而是由于“只见树木、不见森林”的局部视野带来的问题。此外，各个服务独立开发、部署和运行，因此传统的静态分析和演化分析手段无法有效捕捉到服务之间的依赖和交互关系。

工业界对于云原生软件系统可观测性数据的分析和利用能力在不断提高。四年多前，我们针对工业界微服务系统故障分析与调试开展经验研究时发现[3]大部分企业的分析手段还如下图所示那样，停留在基于命令行工具（例如关键字匹配）的日志分析、日志事件统计等基本分析层面上，少数企业开始使用Zipkin等工具进行链路轨迹的可视化分析。

当前，很多企业都在深入探索云原生软件系统可观测性数据分析方法，其中的一个基本出发点是如何更好地融合指标、日志和链路轨迹三类不同的数据。例如，可以通过在日志中注入Trace ID将链路轨迹与日志关联起来。在分析方法方面，比较常见的一种做法是开发一个融合数据分析平台，通过不同类型数据之间的时空关联以及各种可视化分析手段进行故障分析和根因定位。例如，如下图所示的字节跳动技术团队的分享[4]介绍了如何以链路轨迹作为纽带将指标、日志等不同类型的可观测性数据融合在一起进行故障根因定位：首先通过服务失败率这一指标数据及相关的告警规则发现问题，然后将服务失败与相关的链路轨迹进行关联，接下来工程师查看链路轨迹中的嵌套服务调用并定位源头节点，最后定位到源头节点上的相关日志。此外，还有一些平台在聚合日志分析的基础上，支持工程师通过正则表达式等方式进行日志事件筛选并在此基础上定义各种度量指标。

云原生软件系统可观测性的未来

云原生软件系统可观测性这一概念及相关技术的兴起也许代表着我们看待软件系统的方式发生了一次重要的变化。以前我们虽然也经常说软件系统是一个复杂系统，但一般我们都相信我们可以掌控它的全部运行规律，例如通过阅读代码完全理解软件的运行逻辑、利用本地调试掌握软件的实际运行过程并定位故障位置。云原生软件系统巨大的服务数量、生态化的自主演化、高度动态的运行环境使得我们不再奢望能掌握它的全部运行规律，而是转而对运行态的“活”系统展开观测，通过实时、鲜活的观测数据来“推测”系统的内部状态和行为。甚至于就连系统的演化情况可能也需要通过观测数据来“侧面”了解。例如，系统因为快速上线的促销活动而增加了新的服务或改变了原有的服务调用关系，运维团队可能需要通过观测到的链路轨迹数据的变化来发现（还需要将正常变更与故障导致的变化相区分）；测试团队需要通过观测数据去推测支撑关键业务场景的核心服务链，并对其进行重点测试；系统的最新服务依赖关系和体系结构只能依靠观测数据来动态生成。

去年5月份准备GOPS 全球运维大会（深圳）的报告时，正好看到解放日报上刊登的一篇新闻报道《上海城市运行数字体征系统将上线》[5]，其中包含下面这段内容以及相应的配图。

对城市生命体进行“24小时×365天”的“全时智慧体检”。相较于传统的静态城市运行体征，即将上线的上海城市运行数字体征系统是“活”的，以“实时、鲜活”的多维、多源、多态数据为基础…通过数字体征来呈现城市正在发生什么、需要关注和处置什么…更好地研判城市运行的趋势和规律，及时发现潜在的风险，助推城市管理，将被动处置变为“治未病”…

这段描述与云原生软件系统的可观测体系有异曲同工之处。像上海这样的大规模城市正是一个大规模、复杂生态系统，其演化过程和运行状态由城市中千千万万个具备自主性的个人和组织以及复杂的物理环境共同决定，难以通过自顶向下的规划和设计完全掌控或者通过模拟环境来精确理解。我们能做的只是通过各种各样的观测手段，例如交通、建设、市政、公交、电信、公安等部门的数据以及各种摄像头、传感器的数据，去构建一个城市运行数字体征系统去了解城市运行状况、及时发现甚至预判问题。

与之相比，云原生软件系统的可观测性体系建设还处于初级阶段。目前的企业智能化运维平台还只能初步将指标、日志、链路轨迹数据关联起来，距离深度的数据融合乃至“数字体征系统”的建设还有很远的距离。相关问题以及未来的发展方向可能包括以下几个方面。

首先，我们的观测手段还不够丰富，收集的“活”数据还不够丰富，数据质量还不够高。例如，一些包含遗留服务和技术栈的系统的分布式链路追踪覆盖还不全面；目前的应用日志位置选择以及日志格式和术语使用等方面都缺少统一的标准，导致日志数据质量不高。

其次，观测数据量极大，需要更加高效的采样、压缩和存储技术支持。大规模云原生软件系统的观测数据（特别是日志和链路轨迹数据）规模庞大但同时价值密度较低，需要采用有效的采样和压缩技术提高数据的价值，同时通过高效的存储技术支持各种数据分析需求。

再次，我们的数据融合分析方法和技术还比较初级。对于云原生软件系统的数字体征分析需要融合多维、多源、多态数据，例如不同指标之间的融合分析、指标与日志和链路轨迹的融合分析等。这些方面有一些初步的研究工作，但还不够成熟，所融合的数据类型还比较少、规模还比较小。

最后，观测数据的分析利用还停留在较低的层面上。目前观测数据分析的主要用途仍然是异常检测和根因定位，相当于城市运行管理中的应急处理（例如治安案件处理、火灾告警等）。然而，不管是城市治理还是云原生软件系统运维管理都还有很多中长期问题需要解决。例如，如果一个路口总是发生车祸或者某条道路总是堵车，那就不是应急处理的问题了，而是要检讨交通配套、道路设计等方面是否存在问题。与之相似，如果某个云原生软件系统总是频繁出现某类问题，那么也需要分析一下是否存在架构退化问题（例如循环依赖、链路过长、可用性设计问题）。此外，系统的业务需求状况、服务资产治理（例如重复功能实现）也都可能会越来越依赖于观测数据分析。

总结

越来越多的云原生软件系统会逐步演化成为复杂生态系统，新业务和特性不断生长，系统复杂度不断提高。可观测性已经成为云原生软件系统的一个重要属性。基于可观测性的智能化运维（AIOps）也将继续向纵深发展，在关注应急处理的基础上越来越重视系统的长期健康演化和可持续发展，系统业务及技术运转状况的分析和理解越来越依赖于运行时数据分析。为此，我们需要在当前以应急处理为目的的指标、日志、链路轨迹等观测数据基础上，面向云原生软件系统数字化体征分析的需要实现更加丰富多元的监控数据采集。与此同时，融合数据分析成为新的挑战，需要考虑如何融合指标、日志、链路轨迹等多维、多源、多态运维数据，通过关联分析等手段获得更加全面、准确的运维分析视图。

未来，随着“人机物融合”以及“软件定义一切”的趋势发展，云原生软件技术很有可能会进一步渗透到物理世界与社会空间，与现实世界进一步融为一体。而云原生软件系统的触角也会从云数据中心扩展到边缘和终端设备上，支撑现实世界的正常运转。因此，云原生软件系统的可观测性以及智能化运维未来可能会成为一个越来越重要的问题。

参考文献

[1] Observability. https://en.wikipedia.org/wiki/Observability.

[2] Peter Bourgon. Metrics, tracing, and logging. https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html.

[3] Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chao Ji, Wenhai Li, Dan Ding: Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study. IEEE Trans. Software Eng. 47(2): 243-260 (2021).

[4] 字节跳动技术团队. 分布式链路追踪在字节跳动的实践. https://mp.weixin.qq.com/s/a0Pm26-8toNKz0brrRVG4Q

[5] 解放日报：上海城市运行数字体征系统将上线. http://www.xinhuanet.com/info/2021-05/12/c_139940069.htm

作者简介

彭鑫，复旦大学计算机科学技术学院副院长、软件学院副院长、教授、博士生导师。中国计算机学会软件工程专委会副主任、开源发展委员会常务委员，《Journal of Software: Evolution and Process》联合主编，《ACM Transactions on Software Engineering and Methodology》编委，《软件学报》编委，《Empirical Software Engineering》编委，IEEE软件维护与演化国际会议（ICSME）执委（2017-2020）。2016年获得NASAC青年软件创新奖。主要研究方向包括软件开发大数据分析、软件智能化开发、云原生与智能化运维、人机物融合泛在计算系统、机器人软件工程等。研究工作获得ICSM 2011最佳论文奖、ACM SIGSOFT杰出论文奖（ASE 2018/2021）、IEEE TCSE杰出论文奖（ICSME 2018/2019/2020）、IEEE Transactions on Software Engineering年度最佳论文奖（2018）。带领复旦大学CodeWisdom研究团队开展软件开发大数据分析以及软件智能化开发与运维方面的研究与实践，研究成果在多家大型企业进行了实践应用。

CodeWisdom

Codewisdom平台由复旦大学软件工程实验室运营，提供智能化软件开发平台及线上沙龙相关资讯，关注可了解更多智能化软件开发的最新消息~