这是我参与2022首次更文挑战的第1天,活动详情查看:2022首次更文挑战
一、概述
1.1 背景
监控系统在企业的运维中是非常重要的一个环节。在每个企业的数据中心内,或多或少的都会使用一些开源或商业的监控系统,从监控对象的角度来看,这些监控系统可以分为网络监控、存储监控、服务器监控和应用监控等,监控系统在监视这块往往需要做到面面俱到。而我们项目中目前缺乏相关监控系统,在面对多个节点时,我们往往无法及时获取各个节点上的系统运行数据。例如有次数据库备份未删除事件导致了某个centos节点的内存空间被占满,相关人员却并不能及时得知。而本身开发一套针对系统及其运行环境的系统需要一定的时间成本,因此,急需调研一款合适的监控系统并对其进行部署测试,期望能满足我们的监控功能。
1.2 定位
作为一套监控系统,结合我们的业务,我们希望能够满足以下几个功能:
✮ 监控系统对 centos 实行动态实时监控,输出相应图表界面;
✮ 监控系统对 windows实行动态实时监控,输出相应图表界面;
✮ 监控系统对 mysql 数据库实行动态实时监控,输出相应图表界面;
✮ 监控系统对 JVM 实行动态实时监控,输出相应图表界面;
✮ 监控系统针对相关指标超出预警提供警报功能。
1.3 方案调研
经过调研,目前业界主流的监控方案有两种:基于 Zabbix 监控和基于 Prometheus的监控方案。相对我们的业务场景来说,Zabbix比较重量级,是老牌的监控系统,但是其对容器支持程度低,且集成后使用 Zabbix进一步定制难度很高,但是 Prometheus 定制灵活度高,起步后的使用难度远小于 Zabbix 。
目前团队人员对两种监控系统都未接触,因此,并不存在现有技术积累,针对综合性能和后期扩展考虑,当前使用 Prometheus 作为监控系统比较合适。
二者的综合对比如下表所示:
方案 | 发现时间 | 开发语言 | 性能 | 社区支持 | 容器支持 | 部署难度 |
---|---|---|---|---|---|---|
Prometheus | 2016 | Go | 支持万为单位 | 相对不如zabbix,但是使用人数与日俱增 | 支持k8s集群监控,目前容器监控最好的解决方案 | 一个核心的server组件,启动方便 |
Zabbix | 2012 | C+php | 上限为1w个节点 | 应用广泛,比较成熟 | 对容器支持性差 | 多种系统,多种监控信息采集方式 |
二、Prometheus系统
2.1简介
Prometheus 是由前Google工程师从2012年开始在Soundcloud以开源软件的形式进行研发的系统监控和告警工具包,自此以后,许多公司和组织都采用了Prometheus 作为监控告警工具。在2016年正式加入 CNCF 基金会项目,Prometheus 作为一代云原生监控系统,目前已经有超过 650+贡献值参与到研发工作中,并超过 120项的第三方集成。
2.2架构
Prometheus 的生态组件架构分为三层:
(1) 采集层:采集的数据分为短作业和长作业两种进行拉取。
(2) 存储计算层:从pushGateway或Exporter拉取数据并存入时序数据库中。
(3) 应用层:告警和数据可视化两种功能。
其架构组件如下图所示:
2.3 场景
适合场景:
- Prometheus 适用于记录文本格式的时间序列,它既适用于以机器为中心的监控,也适用于高度动态的面向服务架构的监控。在微服务的世界中,它对多维数据收集和查询的支持有特殊优势。
不适合场景:
- Prometheus 非常重视可靠性,即使在出现故障的情况下,你也可以随时查看有关系统的可用统计信息。如果你需要百分之百的准确度,例如按请求数量计费,那么 Prometheus 不太适合你,因为它收集的数据可能不够详细完整。这种情况下,你最好使用其他系统来收集和分析数据以进行计费,并使用 Prometheus 来监控系统的其余部分。
2.4方案制定
目前,Prometheus 监控系统的核心在于数据采集,对数据可视化的图表美观程度并不是长项。而一般情况下,使用开源时许数据库 Prometheus作为监控和性能指标信息存储方案,使用 Grafana作为可视化组件进行展示。Grafana 是用于可视化大型测量数据的开源程序,它提供了强大和优雅的方式去创建、共享和浏览数据,并且拥有很多模板图表进行数据展示。通过 Prometheus 和 Grafana 可以很好的实现数据的采集、展示和告警功能。当然针对专业的告警,例如具备发短信和打电话功能,可以使用专业的告警系统,例如睿象云。不过,通过当前这套系统的方案可以满足当前业务需求。