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


告警策略的配置方式
对告警策略配置方式的考量 , 应该以灵活性和可维护性为目标 。 混合架构、微服服等新技术催生了更现代化的业务系统技术栈 , 这对告警策略的灵活性提出更高要求 , 告警策略应该支持条件告警、组合条件告警、同比环比、回归、线性拟合等高级功能 , 最好能支持基于聚类算法的告警合并(基于聚类算法的告警合并是目前业界普遍认为最有效也是最可落地的告警合并方法);云原生、容器带来高动态的服务端环境 , 这样的环境需要可维护性更强的告警策略配置方式 , 业务环境高频甚至自动变化 , 缺乏可维护性的告警策略配置方式会导致监控系统的配置无法跟上业务环境的变化 , 不但耗费大量人力 , 还容易导致漏配、错配 。
API和二次开编程接口
基础设施可编程逐渐将运维工作软件化 , 这股软化趋势不断向运维技术栈的上部蔓延 。 监控系统作为运维系统的中枢需要具有强大的API和二次编程接口才能与CMDB、虚拟化环境、部署系统(CI、CD)、运维自动化系统等其它运维子系统良好配合 , 协同工作;孤立的监控系统会形成数据孤岛 , 成为运维工作流中的瓶颈点 , 影响运维系统的整体规划与技术演进 。
常见技术选型Zabbix
使用原生Zabbix方案 , 通过Zabbixagent采集数据;通过Zabbixserver接收、存储数据并计算告警;通过ZabbixwebUI或Grafana展示数据;通过shell脚本收集自定义监控数据 , 如下图所示:

常见运维监控系统的技术选型
文章图片
优点:方案成熟、初期持有成本低
缺点:超过1000台服务器时存在性能和管理效率瓶颈;自定义脚本维护成本高;可扩展性差 。
Zabbix+二次开发
基于Zabbixserver的数据存储和告警计算能力 , 使用部分Zabbixagent内置监控指标;自研数据上报器管理和收集自定义监控指标数据;通过CMDB或服务器统一管理告警配置和自定义收集并自动同步给Zabbixserver和数据上报器;Zabbixserver产生告警后发送至告警中心 , 由告警中心统一管理告警并发送 。 如下图:

常见运维监控系统的技术选型
文章图片
优点:告警配置和自定义收集统一管理 , 并可贴合自身业务场景定制 , 运维体验较好 , 可维护性强 。
缺点:超过1000台服务器时存在性能和管理效率瓶颈;数据能力弱;技术投资不具备可持续性 , 后续运维智能化、数据驱动等技术路线锁死 。
Prometheus
使用原生Prometheus方案 , 能过开源社区的exporter采集数据 , 通过Prometheus存储数据 , 通过AlertManager计算并发送告告警 , 通过Grafafa展示数据 , 如下图:

常见运维监控系统的技术选型
文章图片
优点:开源社区大量收集器可以直接使用;数据能力较强;数据吞吐能力较强;Prometheus为新一代监控系统事实标准 , 技术投资风险低、技术红利较大 。
缺点:无可视化管理界面 , 告警配置、数据查询门槛极高;系统组件多 , 组件间耦合松 , 管理维护成本高 。
OpsMind
兼容Prometheus的核心功能 , 配合Prometheus优秀的二次开发接口 , 自研分布式存储引擎、告警引擎、指标项管理、数据查询等业务功能 , 在充分利用核心优势的基础上弥补Prometheus在功能性上的不足 , 如下图:

常见运维监控系统的技术选型
文章图片
将Prometheus包装为完整的监控解决方案 , 并加入AIOps能力:
1.提供完善的分布式方案 , 大大加强系统容量、性能和稳定性
2.系统管理可视化 , 基础配置鼓励需求方自助完成 , 减少机械性工作 , 加快需求响应时间
3.数据查询产品化、客制化 , 数据民主 , 平台直接输出数据能力和数据价值
4.告警智能合并 , 减少漏报和重复告警
5.提供结合行业特点的监控项和告警梳理服务 , 借鉴行业最佳监控实践
6.提供产品维保、技术支持、定制化开发 , 保证甲方自主可控 , 保护技术投资的可延续性
目前该方案被一线互联网企业普遍认可和采用 , 技术投资具备可持续性 , 跟随业界发展动态 , 最大程度享受产业技术发展的红利 。
技术趋势在监控系统技术演进过程中 , 我们必须持续关注并适度跟随以下技术趋势:
监控系统的中枢作用
监控系统越来越发挥整体运维系统的中枢作用 , 运维系统逐渐由流程驱动转变为数据驱动 。 我们应该更加重视监控系统的开放性 , 使监控系统具有与其它所有运维子系统对接、整合的能力 , 并对外做出数据、算法等技术输出 。