监控系统的功能概述

在计算机的领域，可以将其分为5种监控类型

• 应用性能监控
• 业务交易监控
• 网络性能监控
• 操作系统监控
• 网络站点监控

多种应用构成了复杂的IT业务系统，如何保证这些资源正常运转，是各公司内IT部门的重要职责。要让这些应用能够稳定地运行，则需要专业的IT人员进行规划，设计，架构，维护和调优。在这个过程中，为了及时掌握基础环境和业务应用系统的可用性，需要获取各个组件的运行状态，如CPU的利用率，系统的负载， 服务的运行，端口的连通，带宽流量，网站访问状态码信息，而这一切离不开监控系统的支撑

监控系统的实现原理

模块的组成

一个监控系统的组成大体上可以分为两部分：数据采集部分（客户端，agent）和数据存储分析告警部分（服务器，server） 。这两部分构成了监控系统的基本模型

采集协议

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

采集模式

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

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

监控指标

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

代理架构

对于大规模的监控环境，被监控节点多且监控类型多，监控产生的数据和网络连接开销非常大，数据采集方式除了使用主动采集模式，还需要使用代理架构，通过代理架构分摊服务器端的性能开销。另外，代理架构还支持跨地域，跨网络的分布式监控。常见的代理架构，即C/P/S(client/proxy/server，客户端、代理端、服务器端)架构即可满足监控业务需求

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

数据存储

在监控客户端采集数据之后，会将数据上传给监控服务器端，监控服务器端程序将接收到的数据进行存储。通常监控系统会采用以下几种数据存储方式

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

(2) 使用时序数据库进行数据存储，如古老的环状数据库。近年来，随着时序数据库技术的不断发展，出现了比较成熟的时序数据库，如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监控系统也在这方面进行了尝试，在zabbix4.0中可以选用Elasticsearch作为数据库存储

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

告警功能

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

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

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

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

可扩展性

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

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

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

zabbix架构

zabbix的通用架构采用客户端/服务器端模式，分布式架构采用客户端/代理端/服务器端模式，zabbix-server将采用到的数据持久地存储到数据库中，用前端的UI友好地展示给用户。下图展示的是客户端采集数据，代理服务器做代理，服务器端处理数据的架构模式

zabbix数据的采集不仅可以使用agent方式，也可以使用其他方式，如采用SNMP,SSH,Telnet,IPMI等多种协议

• zabbix-server的内部处理进程