多维度监控：智能监控的数据基础

前言

以组件监控为例，介绍监控产品的路线图

运维监控系统的作用不言而喻，贯穿运维的5项职能：发布、变更、故障处理、体验优化、日常需求，保障上述职能的服务可用性。

从大数据的特性(数据量大、多维度、完备性)1来看，运维监控系统的建设可以分为2个阶段：多维度监控（积累数据）和 智能监控(使用数据），通过多维度监控实现出了故障能看、能查，智能监控提前发现风险、找出故障根源。

组件监控是多维度监控体系的第3层，主要对常见开源组件、中间件的性能指标做监控，比如Nginx的性能指标有Active Connections（当前客户端连接数）、Waiting（等待中的连接数）等，Oracle的性能指标有 SQL硬解析率、表空间使用率等。

通过采集组件的关键性能指标，实时获悉组件的运行状况，提前发现问题，而不是仅监控进程或端口是否存活（进程或端口都正常时，不代表可以提供服务）。

本文以建设组件监控为例，从多维度监控的组成、监控产品要解决的3个问题、组件监控的技术选型、云端下发采集器配置、社区的开放能力来介绍监控产品设计路线图。

1. 多维度监控的组成

从用户访问链路的角度，将监控指标的维度分为用户层、应用层、组件层、主机层、网络层。

用户层，通过服务拨测等方式模拟用户的访问行为，不用等用户投诉上门；应用层，通过调用链等方式追踪应用的调用状态；其他三层较为容易理解就不做介绍了。

通过这5层其他关键指标（如日志、业务KPI曲线等），构筑监控系统的多维度监控能力，为第二阶段的智能监控提供数据支撑。

2. 监控产品要解决的3个问题

除了获取关键的性能指标外，监控产品还需要解决3个问题， 退可做故障关联分析，进可建设运维的智能化场景。

2.1 对IT系统的自主掌控能力

由于对IT系统自主掌控能力的缺乏，"正在更换IT系统" 和 "走向更换IT系统的路上，是部分中、大型企业在"互联网 "浪潮下积极拥抱互联网的现状。

鉴于这种情况，部分行业已明确已表明2，必须加大对IT系统自主掌控的能力。

于是，产品设计时，需考虑能让监控系统的使用者可以参与到监控系统的开发或部分开发.

2.2 拒绝再造一个烟囱

竖井式的结构估计是大部分企业构建IT系统的现状，每个系统间毫无关联，每买一套系统等于多构建一个信息孤岛，附加值极低。

如果想实现退可做故障关联分析，进可建设运维的智能化场景，可在基于PaaS的运维平台上建设4，通过iPaaS打通企业内部的各个IT运营系统。

2.3 组件繁多，完全自研不太现实

行业中应用的组件种类繁多，从数据库、存储、HTTP服务到消息队列等共100 ，完全自研肯定不现实。

好的办法是自研核心、行业支撑不好的组件，剩下的借助行业多年积累的能力，少造一点轮子，为社会省点电。

3. 组件监控的技术选型

在2.3中提到自研第3方开源采集器的思路，这里以开源采集器Prometheus Exporter为例。

Prometheus Exporter的社区很活跃5，支持100 常见开源组件，部分大厂甚至专门编写对应的Prometheus Exporter，比如Oracle编写的Weblogic Exporter，IBM编写的IBM MQ exporter，k8s、etcd甚至内置基于Exporter规范的metrics。

按照这种方案，只需要做一个协议转换即可把指标入库