之前我们分享了可观测体系整体规划建设战略与落地实践，而进一步深入可观测体系中，在数字化转型和国产化大背景下，监控的对象种类繁多，新技术新对象层出不穷，企业内部监控体系的建设、监控工具支撑都面临极大的挑战：传统的监控系统无法快速满足国产化的要求，也无法快速扩展支撑快速变化的监控需求，各种监控指标混杂一起，难以管理和分析。
为了解决这些问题，支撑一体化的可观测系统建设，实现统一采集、统一管理、统一告警、统一展示，降低运维成本，进行监控指标管理体系的建设和落地将变得不可或缺。本次我们邀请到了两位嘉为蓝鲸产品经理苏文和孟世一，以自身在监控领域多年的耕耘经验，分别为大家带来《可观测指标管理体系建设落地》与《插件功能设计及生态打造》两个主题分享，与大家一同探讨：
- 如何梳理、建设并落地适合企业自己的可观测指标管理体系？
- 什么样的插件功能和生态能够成为指标管理体系的落地有力支撑？
主题一：可观测指标管理体系建设落地
如今，传统监控日益无法满足企业快速发展的需求，越来越多企业开始进行可观测体系的探索，在建设初期可能也会存在很多的问题：可观测体系建设中为什么需要建设指标体系？指标体系究竟“长什么样”？应该如何设计管理？接下来我们就一一解答这些问题。
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使得监控中心具备对各类不同设备的采集能力，并解决了多云区域下跨网远程收集的问题。
2）插件功能模式设计
在了解完插件能力的设计之后，如何将这些插件利用起来，打造监控插件在各类场景下的各种能力呢？接下来我们就一一深入介绍。
① 主机监控插件：主机监控几乎是所有企业都绕不开的监控场景，对于这类典型的场景，我们通过内置监控插件来帮助采集，在部署蓝鲸agent时会自动部署basereport插件，自动采集cpu、内存、io等数据并上报至监控中心，实现内置开箱即用的监控场景。
主机监控是较为典型的场景，但除此之外企业常常也会有打造属于自己的监控插件的诉求，针对这些非典型的场景，监控中心也能够提供强大的在线插件制作能力，根据接入模式的不同区分，提供各类场景下的插件功能的结合。
提供exporter/datadog插件，无缝兼容主流prometheus/datadog，同时也能进行插件进行自定义调整以满足自身需求。
② 脚本插件：一些企业中运维人员会存在通过指标的查询命令进行手动查询的场景，插件制作中心也会能够提供脚本设计能力，运维人员可以将脚本写入后自动化执行采集工作。
③ 自定义插件：除了上述采集场景外，还有一些设备需要不同的协议（snmp、jmx等）进行采集，我们也能够支持进行自定义插件的制作。
同时，基于低代码和低门槛思路的插件功能设计，运维人员也能够自主构建一些运维插件以辅助更好的进行运维工作，对于运维人员自身从传统运维向运维插件开发，甚至向运维工具开发进阶也有着良好的推动作用。
3）插件生态积累&运营
嘉为鲸眼监控中心目前已集成了80余款组件服务插件及120余款网络、硬件设备插件。覆盖适配了硬件层、系统层、软件层、应用层乃至云计算层的绝大部分主流设备、系统及组件服务。同时，当前信创建设如火如荼，嘉为蓝鲸也实现了信创各类设备厂商的兼容适配并持续不断支持信创发展。
除此之外，我们也致力于帮助企业建立标准化的插件积累，打造成熟的插件生态能力。完整的标准化插件包含指引手册与指标清单两部分。当企业具备了成熟的标准化插件以后，能够自主根据业务的发展进行相应的插件生态打造，从而实现可持续优化的插件体系。
指引手册包含各类说明、使用指引等，让小白运维也能够快速上手。
指标清单是从分类、采集、阈值等多个角度针对各类型插件指标梳理的完整清单，这部分并不是简单指标列表，需要具备科学的指标分类、合理的维度设置、完整的指标信息以及核心指标阈值推荐。
