1.2 监控系统的实现原理

1.2.1 模块组成

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

1.2.2 采集协议

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

1.2.3 采集模式

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

一般来说，被动模式对监控控制端服务器的开销较大，适合小规模的监控环境；主动模式对监控控制端服务器的开销较小，适合大规模的监控环境。

1.2.4 监控指标

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

1.2.5 代理架构

对于大规模的监控环境，被监控节点多且监控类型多，监控产生的数据和网络连接开销非常大，数据采集方式除了使用主动采集模式，还需要使用代理架构，通过代理架构分摊服务器端的性能开销。另外，代理架构还支持跨地域、跨网络的分布式监控。常见的代理架构，即C/P/S（Client/Proxy/Server，客户端/代理端/服务器端，此处的Client和Agent意思等同，都表示客户端，下同）架构，如图1-5所示。采用中间代理将大大提高监控服务器端的处理速度，从而支撑构建大型分布式监控环境，从架构上支持异地多机房的需求。

对于小型的监控环境，被监控节点不多且处于同一地域或网络环境下，监控系统所需采集的监控数据量较少，采用C/S（Client/Server，客户端/服务器端）架构即可满足监控业务需求。

1.2.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作为数据库存储。

以上我们看到在不同的场合下监控系统对数据的存储要求会不同，因此，有些监控系统产品直接将数据库存储的选项交给了使用者来决定，会同时支持多种方式的数据库存储。

1.2.7 告警功能

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

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

在触发和发送告警时，告警模块需要支持故障的有效汇报和集中汇报，尽量避免出现“告警风暴”，防止同一时间大量发送重复、类似的告警，即告警功能支持对告警内容进行分析和自动处理，防止误报、漏报及抖动。对于大多数监控系统来说，这一点都是一个值得挑战和研究的课题。举一个实际的例子，当机房网络发生故障时，按照常规，用户会收到无数条告警信息，内容是每台设备的故障。但如果将告警聚合，我们希望收到的信息是“某机房存在网络故障，受影响的设备IP地址是X.X.X.X，受影响的业务是XXX”。

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

1.2.8 可扩展性

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

对于告警，要求支持多种方式，如短信、邮件、即时通信和其他接口，且具备可定制化能力，可以对第三方告警介质提供可编程接口。这一点在很多场合都非常重要，例如，将告警结果发送到专用的告警分析系统。

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

1.2.9 总结归纳

以上我们共同学习了监控系统的组成、监控架构的设计、监控指标的采集、监控数据的存储、监控告警的发送和分析，并探讨了监控系统的可扩展性。通过对这些方面的探讨，我们对监控有了一个全面的认识。

在一个监控系统中，构成要素为监控服务器端程序、数据存储、被采集节点等相关模块，其告警分析和自动故障处理功能由服务器端执行。在数据采集完成之后，需要对采集到的数据进行分析和处理，判断是否有异常、是否符合告警条件。那么如何配置告警条件呢？通常是根据实际的经验值、业务需求来设置告警阈值的。当达到告警条件时，则发送告警信息给管理人员。然而，对于有些故障，我们希望程序能自动处理，减少人工干预，让程序自动修复，只在出现严重故障、程序无法判断时，才发送告警通知管理人员处理。

一个监控系统往往需要集成资产管理系统，如图1-6所示，资产管理功能可以从逻辑上展示业务用途的信息，通过对其进行数据分析，做到对投资与回报的反馈展示，为资产的合理规划与使用提供依据。

从工作模式来看，监控系统的数据采集可以分为两种：主动监控和被动监控。一个理想的监控系统采集端支持的采集方式越多，其扩展能力越强大，适用的环境场合越多。

监控系统需要具有对外提供API的能力，方便第三方应用系统对监控数据进行操作管理。通常能对外提供API功能的软件，意味着其扩展能力更强大，因而会更加受到用户的喜爱。API的方式一般可以分为RESTful、SOAP等，在API中使用的数据类型可以为JSON、XML等。从目前的趋势来看，RESTful已经成为绝大多数API首选的方式。

监控系统需要对故障数据进行分析汇总，从故障数据中分析出现的概率，进而可以积累数据经验，避免以后出现类似的问题。例如，通过分析统计机器硬件导致故障的概率有多大、哪些部件最容易出问题、出问题的影响概率有多大、立即解决问题的概率有多大等问题，在此基础上进行分析汇总，就可以整理出有效的相应故障对策和技术应急方案。