Python自动化运维-zabbix-监控系统的实现原理

1. 模块组成

一个监控系统的组成大体可以分为两部分：数据采集部分（客户端，Agent）和数据存储分析告警展示部分（服务器端，Server），如图1-2所示。这两部分构成了监控系统的基本模型。

 

2. 采集协议

按照支持的协议方式，监控系统数据采集可以分为两种：专用客户端采集和公用协议采集（SNMP、IPMI、SSH、Telnet等）

 

3. 采集模式

监控系统数据采集的工作模式可以分为被动模式（从服务器端到客户端采集数据，对应的英文单词是pull）和主动模式（客户端主动上报数据到服务器端，对应的英文单词是push）两种，通常，大多数监控系统都应该能同时支持这两种工作模式，但不同的监控系统由于采集技术不同，仅有部分能够同时支持这两种工作模式。

 

4. 监控指标

监控系统通常都支持一些常见的监控采集指标，如操作系统监控、应用程序监控等。

 

5. 代理架构

对于大规模的监控环境，被监控节点多且监控类型多，监控产生的数据和网络连接开销非常大，数据采集方式除了使用主动采集模式，还需要使用代理架构，通过代理架构分摊服务器端的性能开销。

另外，代理架构还支持跨地域、跨网络的分布式监控。常见的代理架构，即C/P/S（Client/Proxy/Server，客户端/代理端/服务器端，此处的Client和Agent意思等同，都表示客户端，下同）架构（如下图）。

采用中间代理将大大提高监控服务器端的处理速度，从而支撑构建大型分布式监控环境，从架构上支持异地多机房的需求。

对于小型的监控环境，被监控节点不多且处于同一地域或网络环境下，监控系统所需采集的监控数据量较少，采用C/S（Client/Server，客户端/服务器端）架构即可满足监控业务需求，毕竟CPS的模式没有了P会少消耗一些服务器资产。

 

6. 数据存储

在监控客户端采集数据之后，会将数据上传给监控服务器端，监控服务器端程序将接收到的数据进行存储，一般会选以下6种数据存储方式：

（1）本地存储。使用本地磁盘，基于文件的方式存储。

（2）使用时序数据库进行数据存储，如古老的环状数据库（Round Robin Database, RRD）等。近年来，随着时序数据技术的不断发展，出现了比较成熟的时序数据库，如OpenTSDB（底层存储基于HBase）、Graphite、InfluxDB、Prometheus等，与直接使用文件的存储方式相比，这些时序数据库更加高效。目前时序数据库领域相关技术的发展速度较快，应用的生态也逐步完善，基于时序数据库的监控系统会逐渐增多。从长远角度来看，使用时序数据库存储监控数据，是必然的发展趋势。

（3）使用数据库管理系统（Database Management System, DBMS）进行数据存储，如常见的MySQL、Oracle、SQL Server等。使用这种数据库来存储监控数据，当数据量达到一定规模时，其读/写效率均会显著下降，数据库的压力比较大，通常优化方案思路有3种，一是减少数据的存储量；二是优化数据库本身，调整配置参数，优化运行环境；三是使用分布式数据库和数据库集群技术方案。故使用DBMS作为数据存储的监控系统，对数据库本身的掌握程度决定了监控系统能否在大规模环境下良好工作。

（4）使用NoSQL数据库进行数据存储。NoSQL相对于DBMS这种传统的数据库有着一些天然的优势，单机的QPS通常较高。但NoSQL本身并不是为监控系统设计的，在数据结构存在数据结构存储方面存在一些缺陷，故直接采用NoSQL作为监控数据存储的监控系统产品较少。

（5）使用列存储数据库进行数据存储。列存储数据库由于其设计之初专为大数据而有所考虑，故无须担心其存储容量，底层均有良好的解决方案。但由于其部署、运维均较为复杂，故一般监控系统也不会常采用这种技术作为数据库存储。这方面的数据库代表为HBase。

（6）使用全文搜索引擎数据库进行监控数据存储。这方面的代表是Elasticsearch，其作为监控数据库存储监控数据具有天然的优势，支持集群、分布式部署、容灾，并且集群能够提供较高的性能。目前采用全文搜索引擎数据库进行监控数据存储，典型的代表是ELK套件，而Zabbix监控系统也在这方面进行了尝试，在Zabbix 4.0中可以选用Elasticsearch作为数据库存储。

 

7. 告警功能

监控系统的重要功能是根据设定的阈值进行告警，同时也要求在发生故障时有一定的故障自动化处理功能，对于特殊的告警还需要具备告警的升级功能，将不同级别的告警分成不同的梯度发送给不同的告警接收人。

虽然监控系统的重要功能是告警，但过多地发送告警，对于监控系统的使用效果来说，反而会不理想。因为人的精力是有限的，不可能随时随地等待着故障发生而立即处理故障，当告警过多时，我们需要优化监控系统。

在触发和发送告警时，告警模块需要支持故障的有效汇报和集中汇报，尽量避免出现“告警风暴”，防止同一时间大量发送重复、类似的告警，即告警功能支持对告警内容进行分析和自动处理，防止误报、漏报及抖动。

事后还需要对告警信息进行统计分析，以方便对系统的运行情况进行分析统计，从而衡量系统的稳定性、可用性。通常使用SLA服务质量指标来衡量。

 

8. 可扩展性

可扩展性是指监控系统本身具备良好的扩展能力，包括监控方式的扩展、监控能力的扩展、监控数据存储的扩展、分布式的支持等。要求监控系统能够随着不同环境而做出改变和调整，大多数监控系统都具备一定的扩展能力。

对于告警，要求支持多种方式，如短信、邮件、即时通信和其他接口，且具备可定制化能力，可以对第三方告警介质提供可编程接口。

监控系统需要根据实际应用的需求，实时/非实时地采集和展示数据。另外，还包括历史趋势数据的展示和分析，以及容量报表、可用性报告的生成。