如何评估可观测性建设的成效?有哪些关键指标?

科技   2024-10-24 07:35   北京  
【摘要大家都在谈可观测性,却有很多问题模糊不清:为什么建设可观测性?要解决什么样的问题?通过监控手段不能解决吗?可观测性和监控的本质区别在哪里?预期实现什么样的目标?有哪些子目标?……本文带您一一解读。

【作者】汪照辉,专注于容器云、微服务、DevOps、数据治理、数字化转型等领域,对相关技术有独特的理解和见解。擅长于软件规划和设计,提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容,受到了广泛关注和肯定。


背景分析

社区有人问如何评估可观测性建设成效,有什么关键指标?(见:可观测建设的目标究竟是什么?这是一个非常非常好的问题,它有助于我们深入思考和理解可观测性。要评估或评价一件事物,首先需要理解和明确其目标和关键价值。为什么建设可观测性?要解决什么样的问题?通过监控手段不能解决吗?可观测性和监控的本质区别在哪里?预期实现什么样的目标?有哪些子目标?等等。把目标进行分解,就可能是比较好的评价指标。将现状和目标进行比较,找到差距,可能为正也可能为负,也就是建设成效超过了目标或尚未达到目标要求,从而可以比较好的理解建设成效和下一步的建设方向。

一、深入理解可观测性

在讨论可观测性建设成效之前,我还是想强调下可观测性的理念,对可观测性的理解以及如何建设可观测性。因为这是基础,如果对可观测性的理解和认知出现偏差,虽然不至于谬以千里,但会使可观测性建设的目标出现偏差,导致很多额外的重复建设和工作量,带来大量的成本和浪费。

首先要明白为什么现在都提“可观测性”而不是“监控“?它的提出为了解决云分布式复杂环境中应用程序异常问题定位和调试、不借助外部工具(如监控采集工具)理解程序运行状况和处理逻辑等事情。所以本质上,可观测性和监控是不一样的,其实现的理念和思路有本质不同。所以在建设可观测性能力上侧重也是不同的。

在可观测性能力建设上,虽然需要建设企业统一的可观测平台,但更核心的应该是研发人员可观测性认知和习惯的培养。因为要实现可观测性首先需要在应用程序内部完成程序日志、指标、链路跟踪信息的收集并发布给统一的可视化可观测平台。这就是为什么说可观测性是一种文化、一种习惯的原因了。而监控就不需要应用程序研发人员做这么多工作,而是借助filebeat、zabbix、Prometheus、各种agent、sidecar等采集应用程序的日志、指标,构建可视化跟踪链路等。监控往往存在重复的数据采集和处理,无法做到一次数据收集发布,实现其他需要这些数据的系统独立接收共享的能力。这就是发布订阅pub-sub模式和请求应答req-reply模式的区别,其实就是可观测性数据收集实现和监控数据采集实现的区别。

二、理解可观测性建设的目标

通过提升对可观测性的认知,可以更好理解如何落地可观测性。可观测性指的是不借助外部工具的情况下应用的可理解性,也就是说,就应用程序本身来说,是否具备可理解性。

可观测性建设通常分系统级或企业级。系统级的可观测性只考虑该系统的可观测能力,而不需要考虑企业级的规范化和标准化要求等。所以系统级限于其范围小,实现相对容易,有一个可视化组件来收集、处理并展示系统所有组件的日志、运行指标、调用链路、事件处理等信息。

企业级可观测性建设通常在企业内部有个可视化的工具平台,企业所有的系统都按照一定的规范和标准将日志、指标、链路跟踪、事件处理等信息收集并发送给企业级可观测平台,这个可观测平台未来可能会发展为一个综合的企业级的系统态势感知平台。有人对可观测平台定义为面向云原生环境的,具备多为数据(指标、链路、日志等)统一采集存储、统一数据监测告警、多维数据关联分析及多种AIOps能力的运维平台软件。我觉得这个理解是有问题的。可观测性平台可以用来辅助运维,但它不完全是一个运维平台;另外也不能使用传统监控数据采集的方式和手段。虽然对于存量系统不妨沿用传统监控数据采集方式,但增量系统一定不能用老办法,否则就不是可观测性,而是监控了。所以其核心在于对可观测性的认知有误,没有真正理解可观测性。

快速异常定位、辅助运维是可观测性平台的核心价值之一。通过平台的可视化能力,让研发人员和运维人员能够很容易理解系统的运行状况和处理逻辑,比如通过调用链视图可以对业务请求的完整链路有清晰的认知和理解,在复杂的分布式如微服务、ESB、云原生环境中快速地发现异常,所见即所得,敏捷响应和处理异常。所以可观测性建设的一个关键点是可视化能力,通过可视化使系统运行和内部处理逻辑可见,可被理解。

辅助流程优化和重构是可观测性平台的另外一个核心价值。可观测性平台有助于研发和架构人员甚至业务人员理解业务处理流程,发现流程设计和处理中不尽合理之处,通过迭代优化或流程重构消除隐患,提升效率等。

可观测性最核心的价值是可观测性文化和习惯的建设。这是最难的地方,不过也是很多人刻意避开的地方,但这才是可观测性建设的核心目标。只有在企业内部真正形成一种习惯,在程序研发中自觉不自觉地遵循可观测性实现的规范和标准等,企业的可观测性能力建设才能持续。可观测平台可以快速建成,但系统的可观测能力是随着业务的发展和业务系统的迭代持续改进和完善的过程。如果没有可观测性的意识,在程序代码完成之后就往往需要借助监控数据采集工具进行数据的采集和分析展示,但该应用对其开发人员之外的人来说是个黑盒。能采集到的数据有限,对应用处理逻辑的理解就有限,所以该应用的可观测性就非常差。其根本在于没有可观测性的意识,不具备可观测性的文化和习惯。

三、可观测性评估及关键指标

理解了可观测性的建设目标,那么就可以随着可观测性的建设对其成效进行评估和改进。对目标进行分解,就可以定义可观测性的评估指标。不同的企业实际情况可能会有差别,可选择对企业影响大的指标作为关键指标进行评估,举例说,可观测性规范和标准、研发人员可观测性意识、可观测性平台能力等可以作为关键指标。

中国信通院发布了一个《可观测性建设成熟度模型》标准(如下图),不过其还是用的传统监控数据采集的思想,更类似于一个一体化监控平台的模型。不过也可以参考,一体化的监控和可观测性平台可能未来就会成为企业级的系统态势平台(包括业务运营态势、系统运行态势、安全态势、资源容量态势等)。


▲中国信通院《可观测性建设成熟度模型》架构图

对可观测性建设成效评估通常可以基于实际的建设目的和目标构建评估模型(部分可以参考信通院的模型)。可观测性的建设目的通常是为了实现系统的可理解性,在复杂的云原生等分布式系统中快速定位、调试异常程序,快速修复,实时可见并理解系统运行状况、运行逻辑等;可观测性建设的目标可以是构建企业级的可观测性平台,在公司内部形成可观测性文化和习惯等。

我在回答问题时列了几条:

1、日志、指标、链路等工具体系是否建设完成,或完成的程度,能否满足复杂分布式程序异常调试、异常定位需求,能否能够理解运行中的程序的运行状况、趋势、运行逻辑等 所以关键指标可能是:

(1)系统可理解性

(2)异常定位难易程度

(3)工具的可用程度

2、可观测性可以看作是一种文化,简单说就是在研发团队内部形成一种习惯,在编码时自觉去实现程序的可观测能力。因此:

(1)内部对可观测性的理解程度,也就是认知能力

(2)研发人员践行可观测文化的主动性

(3)对研发人员实现可观测性基础设施的建设程度,也就是规范化和标准化等能力

去深入分析,可以定义更多指标。因此不限于列的几条,可以根据实际的情况来定义和分解,构建适合自己公司现状和未来发展的评估模型。不过指标虽然重要,但更重要的可能是一种自觉的习惯,因此可观测性文化也应该是模型的一部分。

四、可观测性能力成熟度

可观测性能力成熟度划分为4个级别:感知级、探索级、洞察级、卓越级。怎么定义成熟度级别关系不大,不过这里缺了可观测性文化建设这块核心能力。仅有平台是不够的,必须培养可观测性认知和习惯,也就是企业的可观测性文化——IT DevOps文化的一部分。

可观测性能力成熟度其实可以看作是可观测性建设的阶段——可观测性实施路线图,分步实现企业的可观测性能力,也就是构建完整的可观测平台和可观测研发文化。分多少级别在于企业可观测性实施路线图的规划,能力强可以一步到位,若积累和基础弱、投入有限则可以多划分几个阶段,一步一个台阶实现完整的可观测平台和文化是没问题的。

基于以上的讨论,可观测性建设成效评估需要关注可观测性文化的建设,不能只看可观测性平台建设;关键评估指标不同企业可能不一样,不同阶段关注的也不一样,因此最好基于实际进行定义和跟踪评估。可能必要的培训是需要的,特别习惯和文化的建设不是短期任务,需要认知的持续提升和工具体系的积累完善。

有任何问题可点击“阅读原文”到社区原文下留言

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


 资料/文章推荐:


欢迎关注社区 “智能化运维”技术主题 ,将会不断更新优质资料、文章。地址:https://www.talkwithtrend.com/Topic/125353

下载 twt 社区客户端 APP


长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点,不代表社区立场

twt企业IT社区
talkwithtrend.com社区(即twt社区)官方公众号,持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群,让您时刻和国内企业IT同行保持信息同步。
 最新文章