常见运维监控系统的技术选型

当今监控乃至整个运维行业正处在变更之际，面对诸多变化和不确定性，运维监控的规划应该首先考虑保证技术投资的可持续性，避免锁定在某一具体的架构和方案上，而是立足核心技术要点与诉求，跟随技术潮流，平滑演进，保持技术先进性，在演进过程中分阶段持续输出业务价值。本文将介绍几种常见运维监控系统的技术选型。

监控系统的功能

监控系统是运维系统或平台系统中较为核心的组成部分，它承载了运维工作中数据闭环的部分。从功能角度，监控系统分为数据采集功能、数据上报功能、数据存储功能、告警功能、大屏功能、报表功能等功能模块；从技术场景角度，监控系统又可以分为机房监控、硬件监控、网络监控、操作系统监控、中间件监控、云平台监控、业务监控、拨测监控等垂直技术领域；从业务场景角度，监控系统还可以分为资源类监控、成本类监控、审计类监控、质量类监控、运营类监控、安全类监控等垂直业务领域。

无论从哪个角度划分，监控系统的核心职责是保证平台所有信息的及时采集、正确处理、准确告警和合理展示。

监控系统的工作位置

运维负责支撑业务模块的正常运行，这需要从最底层的云或硬件开始构建运维技术栈，按下图所示，一般来说运维技术栈的职能从下往上依次包括环境（如 IDC 机房）、设备（如云主机、硬盘）、基础软件系统（如 linux）、部署和管理（如 docker、k8s）、中间件（如 mysql 数据库）、业务调度，最终到最上层的业务模块。不同公司、不同业务场景下，运维的技术栈的实现方式会有很大区别，但从功能上不会超出下图所示的范围。

在运维技术栈中，监控系统（如上图右侧所示）需要在垂直维度上负责所有层次、所有组件的工作状态收集和风险预警。监控系统的工作位置贯穿了运维技术栈的所有层次，这对监控系统在技术上的全面性、可靠性和工程上的强度提出很高要求。

监控系统的核心组件

数据采集器

数据采集器一般是支持插件机制的数据采集和数据上报工具。它可以从自己所运行的系统上直接采集相关运维数据，或从其它系统的 API 中获得数据，亦或是从系统或第三方组件中监听监控数据。

数据存储仓库

数据存储仓库通常是时间序列数据库，它负责处理大量的监控数据写入和复杂的监控数据查询。数据存储仓库一般需包含数据压缩、数据过期、聚合运算等必须功能。

用户操作和可视化界面

用户操作界面是用户管理监控系统的入口，它必须使对监控指标和告警的管理易用并可维护；数据可视化界面负责提供监控数据的展示，它必须支持必要的时序数据展示手法，并支持一定程度上灵活的查询能力。

数据处理引擎

数据处理引擎处理数据存储仓库中的时间序列数据，一般要支持流式处理和批量处理。数据处理引擎一个最重要的功能是对监控告警的计算。

监控系统的关键技术

收集器

收集器决定了监控数据的来源，收集器的好坏决定了监控数据的覆盖面、数据质量和及时性。一个好的监控系统应该配备大量针对常见技术场景的收集器，并提供方便的自定义数据接口。标准场景的监控数据占所有监控数据的 70% 左右，大量的标准收集器可以大大降低监控系统的持有成本；自定义监控数据占所有监控数据的 30% 左右，设计良好的自定义监控数据接口可以更好的调度、组织和收集自定义数据源，并为后续的二次开发工作夯实工程基础。

时间序列存储技术

时间序列的管理、存储和处理是监控闭环中的核心环节，在设计或评估一个监控系统时应着重考察时间序列存储的技术方案。时间序列技术的关键点在于可用性、可靠性、压缩比、旧数据清理、指标项管理、多维度聚合等多个方面。

查询语言和查询效率

查询语言是监控数据的查询接口，好的查询语言可以极大释放监控数据的价值，而不好的查询语言会限制对监控数据的进一步加工和使用（有些监控系统不支持通过语句方式查询数据，应该避免选择这样的方案）。数据的查询效率会影响监控系统的使用效率，尤其在告警计算、报表生成、数据统计等使用场景下，低下的查询效率会极大影响对数据使用方式的想象空间。

告警策略的配置方式

对告警策略配置方式的考量，应该以灵活性和可维护性为目标。混合架构、微服服等新技术催生了更现代化的业务系统技术栈，这对告警策略的灵活性提出更高要求，告警策略应该支持条件告警、组合条件告警、同比环比、回归、线性拟合等高级功能，最好能支持基于聚类算法的告警合并（基于聚类算法的告警合并是目前业界普遍认为最有效也是最可落地的告警合并方法）；云原生、容器带来高动态的服务端环境，这样的环境需要可维护性更强的告警策略配置方式，业务环境高频甚至自动变化，缺乏可维护性的告警策略配置方式会导致监控系统的配置无法跟上业务环境的变化，不但耗费大量人力，还容易导致漏配、错配。

API 和二次开编程接口

基础设施可编程逐渐将运维工作软件化，这股软化趋势不断向运维技术栈的上部蔓延。监控系统作为运维系统的中枢需要具有强大的 API 和二次编程接口才能与 CMDB、虚拟化环境、部署系统（CI、CD）、运维自动化系统等其它运维子系统良好配合，协同工作；孤立的监控系统会形成数据孤岛，成为运维工作流中的瓶颈点，影响运维系统的整体规划与技术演进。

常见技术选型

使用原生 Zabbix 方案，通过 Zabbix agent 采集数据；通过 Zabbix server 接收、存储数据并计算告警；通过 Zabbix web UI 或 Grafana 展示数据；通过 shell 脚本收集自定义监控数据，如下图所示：

优点：方案成熟、初期持有成本低

缺点：超过 1000 台服务器时存在性能和管理效率瓶颈；自定义脚本维护成本高；可扩展性差。

Zabbix + 二次开发

基于 Zabbix server 的数据存储和告警计算能力，使用部分 Zabbix agent 内置监控指标；自研数据上报器管理和收集自定义监控指标数据；通过 CMDB 或服务器统一管理告警配置和自定义收集并自动同步给 Zabbix server 和数据上报器；Zabbix server 产生告警后发送至告警中心，由告警中心统一管理告警并发送。如下图：

优点：告警配置和自定义收集统一管理，并可贴合自身业务场景定制，运维体验较好，可维护性强。

缺点：超过 1000 台服务器时存在性能和管理效率瓶颈；数据能力弱；技术投资不具备可持续性，后续运维智能化、数据驱动等技术路线锁死。

Prometheus

使用原生 Prometheus 方案，能过开源社区的 exporter 采集数据，通过 Prometheus 存储数据，通过 AlertManager 计算并发送告告警，通过 Grafafa 展示数据，如下图：

优点：开源社区大量收集器可以直接使用；数据能力较强；数据吞吐能力较强；Prometheus 为新一代监控系统事实标准，技术投资风险低、技术红利较大。

缺点：无可视化管理界面，告警配置、数据查询门槛极高；系统组件多，组件间耦合松，管理维护成本高。

OpsMind

兼容 Prometheus 的核心功能，配合 Prometheus 优秀的二次开发接口，自研分布式存储引擎、告警引擎、指标项管理、数据查询等业务功能，在充分利用核心优势的基础上弥补 Prometheus 在功能性上的不足，如下图：

将 Prometheus 包装为完整的监控解决方案，并加入 AIOps 能力：

1. 提供完善的分布式方案，大大加强系统容量、性能和稳定性

2. 系统管理可视化，基础配置鼓励需求方自助完成，减少机械性工作，加快需求响应时间

3. 数据查询产品化、客制化，数据民主，平台直接输出数据能力和数据价值

4. 告警智能合并，减少漏报和重复告警

5. 提供结合行业特点的监控项和告警梳理服务，借鉴行业最佳监控实践

6. 提供产品维保、技术支持、定制化开发，保证甲方自主可控，保护技术投资的可延续性

目前该方案被一线互联网企业普遍认可和采用，技术投资具备可持续性，跟随业界发展动态，最大程度享受产业技术发展的红利。

技术趋势 

监控系统的中枢作用

监控系统越来越发挥整体运维系统的中枢作用，运维系统逐渐由流程驱动转变为数据驱动。我们应该更加重视监控系统的开放性，使监控系统具有与其它所有运维子系统对接、整合的能力，并对外做出数据、算法等技术输出。

自动识别、自主采集

云原生技术浪潮带来了混合的技术栈和高动态的服务端架构，我们应该重视采集器的自主能力，在面向复杂多变的被监控环境时，采集器尽可能做到对环境的自动识别，对指标的自主采集。

重视高维度数据管理能力

云、容器和微服务的出现使被监控对象的数量增加了两到三个数量级，所以高维度的数据管理能力尤其重要，我们的时间序列管理技术架构应该为 10 亿级别时序数据个数作好充足准备。

数据科学和机器学习的引入

我们的架构应该支持数据科学技术和机器学习技术的引入，AIOps 技术还在快速发展之中，很多算法和数据方法还在不断变化，应该为这类变化保留足够的灵活性。

强调数据可视化

随着监控数据的数据量呈几何级数式增长，传统的数据展示方法很难表达大规模数据的准确涵义，我们应该在线图、直方图、散点图等朴素的展示方式之外积累更多适合运维大数据的数据可视化手法。

立足运维视角，体现业务价值

运维环境承载业务运行，运维视角的数据必然具有业务涵义，比如服务请求数对应业务订单数、服务响应时间对应业务用户体验、资源利用率对应业务成本模型，我们应该基于监控系统的数据能力，深挖监控数据的业务涵义，对外输出监控系统的业务价值。