之前我们分享了可观测体系整体规划建设战略与落地实践,而进一步深入可观测体系中,在数字化转型和国产化大背景下,监控的对象种类繁多,新技术新对象层出不穷,企业内部监控体系的建设、监控工具支撑都面临极大的挑战:传统的监控系统无法快速满足国产化的要求,也无法快速扩展支撑快速变化的监控需求,各种监控指标混杂一起,难以管理和分析。
为了解决这些问题,支撑一体化的可观测系统建设,实现统一采集、统一管理、统一告警、统一展示,降低运维成本,进行监控指标管理体系的建设和落地将变得不可或缺。本次我们邀请到了两位嘉为蓝鲸产品经理苏文和孟世一,以自身在监控领域多年的耕耘经验,分别为大家带来《可观测指标管理体系建设落地》与《插件功能设计及生态打造》两个主题分享,与大家一同探讨:
如今,传统监控日益无法满足企业快速发展的需求,越来越多企业开始进行可观测体系的探索,在建设初期可能也会存在很多的问题:可观测体系建设中为什么需要建设指标体系?指标体系究竟“长什么样”?应该如何设计管理?接下来我们就一一解答这些问题。
① 为什么需要建设指标体系?
在了解指标体系前,我们先来看看为什么需要进行指标体系的建设,结合过往的建设经验,我们总结了六个方面的原因:
② 指标体系设计逻辑
了解为什么要设计指标体系后,接下来我们再来看看可观测指标体系应该如何设计。
可观测指标体系的设计对整个可观测性的落地起着至关重要的作用。其设计的核心理念是:以监控对象为骨架、以监控指标为经脉。
那么运维主要监控的对象都有哪些呢?我们以下图的一种拆分方式为例,从应用视角来看,从下往上可以分为数据中心、硬件设备、系统、组件、应用服务、用户体验六个层面,每个层面相应的对象也有不同的指标设计。
上述五层更多关注在应用系统的本身以及其相关运行环境的指标设计,而在此之上到业务运营层面时,可能会超出运维的范畴,但依旧是属于可观测体系中的一部分,这部分主要是聚焦于业务,包括应用系统对外提供的服务时的相关数据指标,如交易系统的交易、订单以及用户数据等一些数据指标。用来衡量前端用户的指标,建立业务数据层面的观测能力。
以上的六层式的指标设计仅仅只是一个参考示例,不同的企业由于所提供的业务不同,对应用的观测有不同的侧重点,企业需要根据自身的实际情况,进行合理的调整或更加细致的划分。
当然,可观测指标体系的建立不仅仅只是确定这些指标的内容,同时还需要对指标的定义、建模、接入、消费全生命周期过程持续做好管理,除此之外,指标设计也并不是“拍脑袋”就能决定的,需要建立相应的指标管理规范,包括设计原则,指标分级、分层、命名等,以支撑整个指标生命周期的正常运作。
接下来,将对指标的设计原则、分级规范以及指标生命周期管理过程进行重点介绍。
① 指标设计原则
指标的设计过程中需要遵循一定的设计原则,我们选取了在行业中比较通用的六个原则进行介绍。
② 指标分级规范
指标分级规范也是指标管理规范中的关键环节,通常会分为三级指标:
③ 指标生命周期
一般指标生命周期主要经历四个阶段:指标定义→指标建模→指标接入→指标消费。
指标定义:主要明确指标所属的层级、指标名称描述,维度如何设置,以及指标属于何种级别。
指标建模:指标是依赖于对象的,如果没有对象,那么指标也就没有实际意义,建模的过程可以联动CMDB模型对象,然后通过插件关联等方式导入指标,再通过原生指标间的运算获得较为复杂的计算指标,最后完成权重和等级的配置,便于后续分析。
指标接入:完成指标的定义和建模后,要把指标真正应用起来还需要通过指标接入采集到明细的数据,一般有第三方上报、插件采集、协议采集等方式,通过采集任务统一进行管理。
指标消费:有了采集的数据之后,就要发挥数据的价值,支撑消费场景。可观测的核心消费场景主要是进行指标检测,对异常状态进行监控告警;除此之外还能进行健康分析,数据运营等工作,同时也能通过指标接口,为其他第三方系统提供消费。
了解了可观测指标体系的内容建设和管理规范之后,在实际落地建设时,企业应该如何建设相应的工具体系来承载指标体系呢?
① 指标体系建设的核心承载工具——监控
在监控中,也可以按照指标的生命周期来进行相应的能力建设。
指标定义&建模阶段:支持对指标的定义、层级、属性的管理。以及对象和指标模型的统一管理。
指标接入阶段:支持采集插件管理,采集、接入任务管理。
运营消费阶段:支持指标数据消费和运营过程中的的检测告警以及可视化管理等。
② 指标体系建设的配套工具
正如上文所提到的,指标的管理不仅仅是指标内容的建立,还包括指标的管理规范和治理。不仅仅需要监控工具,还需要相应的建设配套的工具,如CMDB的建设主要提供数据治理,对象管理等能力,ITSM主要保障指标管理过程中的流程规范,保障顺利完成整个落地过程。
以上我们已经对可观测体系指标建设的一些相关内容做了分享,那么在实践落地方面应该如何着手呢?接下来我们将以嘉为鲸眼可观测产品为例,从数据采集模式设计理念,插件功能模式设计,以及插件生态运营积累三方面介绍实践经验。
早期监控的采集模式通常是以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使得监控中心具备对各类不同设备的采集能力,并解决了多云区域下跨网远程收集的问题。
在了解完插件能力的设计之后,如何将这些插件利用起来,打造监控插件在各类场景下的各种能力呢?接下来我们就一一深入介绍。
① 主机监控插件:主机监控几乎是所有企业都绕不开的监控场景,对于这类典型的场景,我们通过内置监控插件来帮助采集,在部署蓝鲸Agent时会自动部署BaseReport插件,自动采集CPU、内存、IO等数据并上报至监控中心,实现内置开箱即用的监控场景。
主机监控是较为典型的场景,但除此之外企业常常也会有打造属于自己的监控插件的诉求,针对这些非典型的场景,监控中心也能够提供强大的在线插件制作能力,根据接入模式的不同区分,提供各类场景下的插件功能的结合。
提供Exporter/DataDog插件,无缝兼容主流Prometheus/DataDog,同时也能进行插件进行自定义调整以满足自身需求。
② 脚本插件:一些企业中运维人员会存在通过指标的查询命令进行手动查询的场景,插件制作中心也会能够提供脚本设计能力,运维人员可以将脚本写入后自动化执行采集工作。
③ 自定义插件:除了上述采集场景外,还有一些设备需要不同的协议(SNMP、JMX等)进行采集,我们也能够支持进行自定义插件的制作。
同时,基于低代码和低门槛思路的插件功能设计,运维人员也能够自主构建一些运维插件以辅助更好的进行运维工作,对于运维人员自身从传统运维向运维插件开发,甚至向运维工具开发进阶也有着良好的推动作用。
嘉为鲸眼监控中心目前已集成了80余款组件服务插件及120余款网络、硬件设备插件。覆盖适配了硬件层、系统层、软件层、应用层乃至云计算层的绝大部分主流设备、系统及组件服务。同时,当前信创建设如火如荼,嘉为蓝鲸也实现了信创各类设备厂商的兼容适配并持续不断支持信创发展。
除此之外,我们也致力于帮助企业建立标准化的插件积累,打造成熟的插件生态能力。完整的标准化插件包含指引手册与指标清单两部分。当企业具备了成熟的标准化插件以后,能够自主根据业务的发展进行相应的插件生态打造,从而实现可持续优化的插件体系。
指引手册包含各类说明、使用指引等,让小白运维也能够快速上手。
指标清单是从分类、采集、阈值等多个角度针对各类型插件指标梳理的完整清单,这部分并不是简单指标列表,需要具备科学的指标分类、合理的维度设置、完整的指标信息以及核心指标阈值推荐。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。