可观测指标管理体系建设落地及插件功能设计和生态打造

2023-03-01
广东
本文字数：5196 字
阅读完需：约 17 分钟

上期直播中，我们分享了可观测体系整体规划建设战略与落地实践，而进一步深入可观测体系中，在数字化转型和国产化大背景下，监控的对象种类繁多，新技术新对象层出不穷，企业内部监控体系的建设、监控工具支撑都面临极大的挑战：传统的监控系统无法快速满足国产化的要求，也无法快速扩展支撑快速变化的监控需求，各种监控指标混杂一起，难以管理和分析。

为了解决这些问题，支撑一体化的可观测系统建设，实现统一采集、统一管理、统一告警、统一展示，降低运维成本，进行监控指标管理体系的建设和落地将变得不可或缺。本期我们邀请到了两位嘉为蓝鲸产品经理苏文和孟世一，以自身在监控领域多年的耕耘经验，分别为大家带来《可观测指标管理体系建设落地》与《插件功能设计及生态打造》两个主题分享，与大家一同探讨：

1. 如何梳理、建设并落地适合企业自己的可观测指标管理体系？

2. 什么样的插件功能和生态能够成为指标管理体系的落地有力支撑？

扫描图片二维码查看直播回放

Tips：如您不方便查看回放，可阅读以下总结文章，全文约 5000 字，预计阅读时间 8-10 分钟。

主题一：可观测指标管理体系建设落地

如今，传统监控日益无法满足企业快速发展的需求，越来越多企业开始进行可观测体系的探索，在建设初期可能也会存在很多的问题：可观测体系建设中为什么需要建设指标体系？指标体系究竟“长什么样”？应该如何设计管理？接下来我们就一一解答这些问题。

1

可观测指标体系设计

为什么需要建设指标体系

在了解指标体系前，我们先来看看为什么需要进行指标体系的建设，结合过往的建设经验，我们总结了六个方面的原因：

● 衡量业务健康情况：指标体系可以反映业务客观事实，看清业务健康现状，有效衡量业务质量，优化应用运行。

● 完善指标全生命周期管理体系：规范指标定义、指标建模、指标接入、指标消费的过程，指导围绕指标全生命周期的管理体系的建设。

● 衡量企业监控落地效果：建立指标的规范和管理方法，更好衡量企业监控的能力完善程度和监测有效性。

● 支撑故障问题的快速定位：围绕指标的全生命周期管理内容，建设指标数据体系，在故障出现时能够快速定位问题所在。

● 明确指标管理规范：清晰定义指标管理流程、分级分层规范，命名规范等，建立指标的全生命周期管理。

● 为运维团队提供数据支持：企业内统一指标体系建设，提供指标查询、检测、健康分析等消费能力，实现指标数据的价值挖掘。

指标体系设计逻辑

了解为什么要设计指标体系后，接下来我们再来看看可观测指标体系应该如何设计。

可观测指标体系的设计对整个可观测性的落地起着至关重要的作用。其设计的核心理念是：以监控对象为骨架、以监控指标为经脉。

那么运维主要监控的对象都有哪些呢？我们以下图的一种拆分方式为例，从应用视角来看，从下往上可以分为数据中心、硬件设备、系统、组件、应用服务、用户体验六个层面，每个层面相应的对象也有不同的指标设计。

● 数据中心层，一般会有动力、环境、安防等方面的指标，以确保数据中心能够正常运转，为上层奠定良好的基础。

● 硬件设备层，通常关注服务器、网络、存储、安全四大类监控对象，以确保硬件层面的设备不出故障，保障应用的稳定运行。

● 操作系统层，主要承担将硬件“转化”为软件所需资源的职责，在这一层中运维主要监控的对象包含虚拟化资源、操作系统、容器的相关指标。

● 组件服务层，主要包含应用运行所需要的一些组件如数据库、中间件等，通常这些组件会以进程的方式存在，需要对这些组件进行监控管理。

● 应用服务层，也就是应用代码级别的内容，在这一层主要关注的是应用之间的调用链关系，以及面向用户的客户端指标，除此之外一些拨测主动检测指标，主要作用于衡量和反映应用的可用性。

● 上述五层更多关注在应用系统的本身以及其相关运行环境的指标设计，而在此之上到业务运营层面时，可能会超出运维的范畴，但依旧是属于可观测体系中的一部分，这部分主要是聚焦于业务，包括应用系统对外提供的服务时的相关数据指标，如交易系统的交易、订单以及用户数据等一些数据指标。用来衡量前端用户的指标，建立业务数据层面的观测能力。

以上的六层式的指标设计仅仅只是一个参考示例，不同的企业由于所提供的业务不同，对应用的观测有不同的侧重点，企业需要根据自身的实际情况，进行合理的调整或更加细致的划分。

当然，可观测指标体系的建立不仅仅只是确定这些指标的内容，同时还需要对指标的定义、建模、接入、消费全生命周期过程持续做好管理，除此之外，指标设计也并不是“拍脑袋”就能决定的，需要建立相应的指标管理规范，包括设计原则，指标分级、分层、命名等，以支撑整个指标生命周期的正常运作。

接下来，将对指标的设计原则、分级规范以及指标生命周期管理过程进行重点介绍。

2

指标设计规范和生命周期

指标设计原则

指标的设计过程中需要遵循一定的设计原则，我们选取了在行业中比较通用的六个原则进行介绍。

● 指标设计要遵循可度量、可采集、可理解、可消费的原则。我们需要选取更加有意义、受到认可、可衡量的指标作为关键性的指标，例如时间戳 Timestamp 指标，通常情况下并不具备一定的实际意义，并不能作为一个很好的指标。这也是指标设计的最核心的原则，在遵循这个原则的基础上，我们增加以下 5 个原则进行补充。

● 指标设计要有明确监控目标和消费场景。在进行指标选取时，需要明确监控目标和消费场景，避免指标冗余、混乱、隔离、不一致以及谬误等。

● 指标设计具有可以赋予数学运算的属性。比如可排序（全序、偏序），可运算（加减乘除与或非），或者可进行数学统计运算。

● 指标最好是具有时序性的。部分指标需要能够随着时间进行积累，衡量整个时间过程，而不是单一的时间点。比如某个服务是否启动，这个布尔值指标，就没有太大的意义；换一个角度，将服务的运行状态作为一个指标，那么这个指标就可以周期性采集探测，具备时序特征，可以反应不同时间的服务状态。

● 指标定义时首选是代表服务可用性的关键指标。可以参考 Google SRE 定义的黄金指标。比如请求量，耗时，缓存命中率，消息队列 Ingress & Egress 的数量，消费速率，积压请求数量等，这些都可以成为自定义指标的首选。

● 对于部分跟业务相关的指标，也可以作为该业务链路的指标。例如在文件下载场景中，请求的耗时跟请求的文件大小是有正相关性的，将每次下载文件的大小作为指标，在该场景中是较好的一个选择。

指标分级规范

指标分级规范也是指标管理规范中的关键环节，通常会分为三级指标：

核心指标：一般指监控对象的死生指标，1-2 个即可。主要用来反映服务的可用性。

关键指标：一般可用于告警的指标，可参考监控度量的四大黄金指标(饱和度、错误、流量、延迟)来定义。与死生指标不同，主要是从侧面反映服务的状态，以便于提前发现问题，提前预警。

常规指标：根据企业的业务场景可能需要关注的性能指标，一般用于告警问题分析的数据支撑，即分析指标。

指标生命周期

一般指标生命周期主要经历四个阶段：指标定义→指标建模→指标接入→指标消费。

指标定义：主要明确指标所属的层级、指标名称描述，维度如何设置，以及指标属于何种级别。

指标建模：指标是依赖于对象的，如果没有对象，那么指标也就没有实际意义，建模的过程可以联动 CMDB 模型对象，然后通过插件关联等方式导入指标，再通过原生指标间的运算获得较为复杂的计算指标，最后完成权重和等级的配置，便于后续分析。

指标接入：完成指标的定义和建模后，要把指标真正应用起来还需要通过指标接入采集到明细的数据，一般有第三方上报、插件采集、协议采集等方式，通过采集任务统一进行管理。

指标消费：有了采集的数据之后，就要发挥数据的价值，支撑消费场景。可观测的核心消费场景主要是进行指标检测，对异常状态进行监控告警；除此之外还能进行健康分析，数据运营等工作，同时也能通过指标接口，为其他第三方系统提供消费。

3

指标体系建设工具设计

了解了可观测指标体系的内容建设和管理规范之后，在实际落地建设时，企业应该如何建设相应的工具体系来承载指标体系呢？

指标体系建设的核心承载工具——监控

在监控中，也可以按照指标的生命周期来进行相应的能力建设。

指标定义 &建模阶段：支持对指标的定义、层级、属性的管理。以及对象和指标模型的统一管理。

指标接入阶段：支持采集插件管理，采集、接入任务管理。

运营消费阶段：支持指标数据消费和运营过程中的的检测告警以及可视化管理等。

指标体系建设的配套工具

正如上文所提到的，指标的管理不仅仅是指标内容的建立，还包括指标的管理规范和治理。不仅仅需要监控工具，还需要相应的建设配套的工具，如 CMDB 的建设主要提供数据治理，对象管理等能力，ITSM 主要保障指标管理过程中的流程规范，保障顺利完成整个落地过程。

主题二：插件功能设计及生态打造

以上我们已经对可观测体系指标建设的一些相关内容做了分享，那么在实践落地方面应该如何着手呢？接下来我们将以嘉为鲸眼可观测产品为例，从数据采集模式设计理念，插件功能模式设计，以及插件生态运营积累三方面介绍实践经验。

1

Agent+Agentless 结合

早期监控的采集模式通常是以 Agent-less 方式进行，主要通过一些采集协议访问目标设备，再使用一系列的查询命令将数据进行上报，进一步进行后续的分析操作。

早期 IT 的安全要求并不高，但随着企业 IT 要求逐渐严格，操作系统安全性的逐渐提高，这种模式在当前场景下已经不再适用，同时 Agent-less 模式本身过于庞大的链路开销和采集的深度无法满足等问题也被运维人员所诟病。

除此之外，由于 Agentless 采集通常都是基于已有的采集协议去进行，不具备更多拓展的空间，甚至有一些操作系统和应用程序已经不再提供访问接口，在这种情况下我们需要采集更多的指标就只能通过 Agent-based，也就是基于 Agent 采集的模式来进行监控工作。

但实际上，在一些 IT 头部企业开始尝试使用 Agent 模式进行采集的探索过程中，发现 Agent-less 仍然具备这一些不可替代性，其中包括在一些网络、存储、硬件服务器等设备不支持 Agent 模式，以及一些高级网络平台无法安装 Agent，虚拟化平台、公有云平台无法直接访问基础设施等问题，依然只能依赖于 Agent-less 监控方法。

在这种环境下，鲸眼监控中心采取二者相结合的模式，通过在节点管理建立 OneAgent 统一管理模式，Agent 支持按需扩展功能以及按需下发指定的功能模块，Agent 既可以支撑 Agent-based 的数据收集模式，又可以作为 Agent-less 的集中监控设备，围绕蓝鲸 Agent 使得监控中心具备对各类不同设备的采集能力，并解决了多云区域下跨网远程收集的问题。