共计 3837 个字符，预计需要花费 10 分钟才能阅读完成。
当今监控乃至整个运维行业正处在变更之际，面对诸多变动和不确定性，运维监控的布局应该首先思考保障技术投资的可持续性，防止锁定在某一具体的架构和计划上，而是立足核心技术要点与诉求，追随技术潮流，平滑演进，放弃技术先进性，在演进过程中分阶段继续输入业务价值。本文将介绍几种常见运维监控零碎的技术选型。
监控零碎的性能
监控零碎是运维零碎或平台零碎中较为外围的组成部分，它承载了运维工作中数据闭环的局部。从性能角度，监控零碎分为数据采集性能、数据上报性能、数据存储性能、告警性能、大屏性能、报表性能等功能模块；从技术场景角度，监控零碎又能够分为机房监控、硬件监控、网络监控、操作系统监控、中间件监控、云平台监控、业务监控、拨测监控等垂直技术畛域；从业务场景角度，监控零碎还能够分为资源类监控、老本类监控、审计类监控、品质类监控、经营类监控、安全类监控等垂直业务畛域。
无论从哪个角度划分，监控零碎的外围职责是保障平台所有信息的及时采集、正确处理、精确告警和正当展现。
监控零碎的工作地位
运维负责撑持业务模块的失常运行，这须要从最底层的云或硬件开始构建运维技术栈，按下图所示，一般来说运维技术栈的职能从下往上顺次包含环境（如 IDC 机房）、设施（如云主机、硬盘）、根底软件系统（如 linux）、部署和治理（如 docker、k8s）、中间件（如 mysql 数据库）、业务调度，最终到最上层的业务模块。不同公司、不同业务场景下，运维的技术栈的实现形式会有很大区别，但从性能上不会超出下图所示的范畴。
在运维技术栈中，监控零碎（如上图右侧所示）须要在垂直维度上负责所有档次、所有组件的工作状态收集和危险预警。监控零碎的工作地位贯通了运维技术栈的所有档次，这对监控零碎在技术上的全面性、可靠性和工程上的强度提出很高要求。
监控零碎的外围组件
数据采集器
数据采集器个别是反对插件机制的数据采集和数据上报工具。它能够从本人所运行的零碎上间接采集相干运维数据，或从其它零碎的 API 中取得数据，亦或是从零碎或第三方组件中监听监控数据。
数据存储仓库
数据存储仓库通常是工夫序列数据库，它负责解决大量的监控数据写入和简单的监控数据查问。数据存储仓库个别需蕴含数据压缩、数据过期、聚合运算等必须性能。
用户操作和可视化界面
用户操作界面是用户治理监控零碎的入口，它必须使对监控指标和告警的治理易用并可保护；数据可视化界面负责提供监控数据的展现，它必须反对必要的时序数据展现手法，并反对肯定水平上灵便的查问能力。
数据处理引擎
数据处理引擎解决数据存储仓库中的工夫序列数据，个别要反对流式解决和批量解决。数据处理引擎一个最重要的性能是对监控告警的计算。
监控零碎的关键技术
监控零碎在技术上涵盖面广、技术栈深，容易存在技术危险。在设计或评估一个监控零碎时，咱们要分外关注以下关键技术：
收集器
收集器决定了监控数据的起源，收集器的好坏决定了监控数据的覆盖面、数据品质和及时性。一个好的监控零碎应该装备大量针对常见技术场景的收集器，并提供方便的自定义数据接口。规范场景的监控数据占所有监控数据的 70% 左右，大量的规范收集器能够大大降低监控零碎的持有老本；自定义监控数据占所有监控数据的 30% 左右，设计良好的自定义监控数据接口能够更好的调度、组织和收集自定义数据源，并为后续的二次开发工作夯实工程根底。
工夫序列存储技术
工夫序列的治理、存储和解决是监控闭环中的外围环节，在设计或评估一个监控零碎时应着重考查工夫序列存储的技术计划。工夫序列技术的关键点在于可用性、可靠性、压缩比、旧数据清理、指标项治理、多维度聚合等多个方面。
查询语言和查问效率
查询语言是监控数据的查问接口，好的查询语言能够极大开释监控数据的价值，而不好的查询语言会限度对监控数据的进一步加工和应用（有些监控零碎不反对通过语句形式查问数据，应该防止抉择这样的计划）。数据的查问效率会影响监控零碎的应用效率，尤其在告警计算、报表生成、数据统计等应用场景下，低下的查问效率会极大影响对数据应用形式的设想空间。
告警策略的配置形式
对告警策略配置形式的考量，应该以灵活性和可维护性为指标。混合架构、微服服等新技术催生了更现代化的业务零碎技术栈，这对告警策略的灵活性提出更高要求，告警策略应该反对条件告警、组合条件告警、同比环比、回归、线性拟合等高级性能，最好能反对基于聚类算法的告警合并（基于聚类算法的告警合并是目前业界普遍认为最无效也是最可落地的告警合并办法）；云原生、容器带来高动静的服务端环境，这样的环境须要可维护性更强的告警策略配置形式，业务环境高频甚至主动变动，不足可维护性的告警策略配置形式会导致监控零碎的配置无奈跟上业务环境的变动，岂但消耗大量人力，还容易导致漏配、错配。
API 和二次开编程接口
基础设施可编程逐步将运维工作软件化，这股软化趋势一直向运维技术栈的上部蔓延。监控零碎作为运维零碎的中枢须要具备弱小的 API 和二次编程接口能力与 CMDB、虚拟化环境、部署零碎（CI、CD）、运维自动化零碎等其它运维子系统良好配合，协同工作；孤立的监控零碎会造成数据孤岛，成为运维工作流中的瓶颈点，影响运维零碎的整体规划与技术演进。
常见技术选型
Zabbix
应用原生 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 技术还在疾速倒退之中，很多算法和数据办法还在一直变动，应该为这类变动保留足够的灵活性。
强调数据可视化
随着监控数据的数据量呈几何级数式增长，传统的数据展现办法很难表白大规模数据的精确涵义，咱们应该在线图、直方图、散点图等奢侈的展现形式之外积攒更多适宜运维大数据的数据可视化手法。
立足运维视角，体现业务价值
运维环境承载业务运行，运维视角的数据必然具备业务涵义，比方服务申请数对应业务订单数、服务响应工夫对应业务用户体验、资源利用率对应业务老本模型，咱们应该基于监控零碎的数据能力，深挖监控数据的业务涵义，对外输入监控零碎的业务价值。
