1.Zabbix入门基础

监控是整个运维乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供详实的数据用于追查定位问题。

严格意义上来说，线上的服务器没有监控，是不允许上线的。

• 老牌监控:

MRTG（`Multi

Route Trffic Grapher）是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的Tobias Oetiker与Dave

Rand`所开发，以GPL授权。

MRTG最好的版本是1995年推出的，用perl语言写成，可跨平台使用，数据采集用SNMP协议，MRTG将手机到的数据通过Web页面以GIF或者PNG格式绘制出图像。

Grnglia是一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用RRDtool存储数据。具有可视化界面，适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统，可以轻松的处理2000个节点的集群环境。

Cacti（英文含义为仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具，它通过snmpget来获取数据使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板。在历史数据展示监控方面，其功能相当不错。

Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能）

Nagios是一个企业级监控系统，可监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机状态以及服务，同时提供异常告警通知功能等。

Nagios可运行在Linux和UNIX平台上。同时提供Web界面，以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等

Nagios的功能侧重于监控服务的可用性，能根据监控指标状态触发告警。目前Nagios也占领了一定的市场份额，不过Nagios并没有与时俱进，已经不能满足于多变的监控需求，架构的扩展性和使用的便捷性有待增强，其高级功能集成在商业版Nagios

XI中。

Smokeping主要用于监视网络性能，包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持，特点是绘制图非常漂亮，网络丢包和延迟用颜色和阴影来标示，支持将多张图叠放在一起，其作者还开发了MRTG和RRDtll等工具。

Smokeping的站点为：http://tobi.oetiker.cn/hp

开源监控系统OpenTSDB用Hbase存储所有时序（无须采样）的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里。

OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web化、图形化等。

• 王牌监控

Zabbix是一个分布式监控系统，支持多种采集方式和采集客户端，有专用的Agent代理，也支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库，然后对其进行分析整理，达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说，它的总体功能做的非常优秀。

从以上各种监控系统的对比来看，Zabbix都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。

小米的监控系统：open-falcon。open-falcon的目标是做最开放、最好用的互联网企业级监控产品。

OWL是TalkingData公司推出的一款开源分布式监控系统OWLgithub地址

• 三方监控

现在市场上有很多不错的第三方监控，比如：监控宝、监控易、听云、还有很多云厂商自带监控，但是在这里我们不打算着重介绍，如果想了解三方监控可自行上官网咨询。

• 安装配置简单。

• 可视化web管理界面

• 免费开源

• 支持中文

• 自动发现

• 分布式监控

• 实时绘图

zabbix架构 如图所示：

image.png

Zabbix工作流程

1.数据采集: Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集

2.数据存储: Zabbix存储在MySQL上，也可以存储在其他数据库服务

3.数据分析: 当我们事后需要复盘分析故障时，zabbix能给我们提供图形以及时间等相关信息，方面我们确定故障所在。

4.数据展示: web界面展示、(移动APP、java_php开发一个web界面也可以)

5.监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）

6.报警处理:当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急，等。根据故障的级别，配合相关的人员进行快速处理。

默认情况下zabbix包含5个程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server，另外一个zabbix_java_gateway是可选，这个需要另外安装。下面来分别介绍下他们各自的作用。

• zabbix_agentd：客户端守护进程，此进程收集客户端数据，例如cpu负载、内存、硬盘使用情况等。

• zabbix_get：zabbix工具，单独使用的命令，通常在server或者proxy端执行获取远程客户端信息的命令。通常用户排错。例如在server端获取不到客户端的内存数据，我们可以使用zabbix_get获取客户端的内容的方式来做故障排查。

• zabbix_sender：zabbix工具，用于发送数据给server或者proxy，通常用于耗时比较长的检查。很多检查非常耗时间，导致zabbix超时。于是我们在脚本执行完毕之后，使用sender主动提交数据。

• zabbix_server：zabbix服务端守护进程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server

备注：当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据。

• zabbix_proxy：zabbix代理守护进程。功能类似server，唯一不同的是它只是一个中转站，它需要把收集到的数据提交/被提交到server里。

• zabbix_java_gateway：zabbix2.0之后引入的一个功能。顾名思义：Java网关，类似agentd，但是只用于Java方面。需要特别注意的是，它只能主动去获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy。

image.png

1、主机（host）：要监控的网络设备，可由IP或DNS名称指定；

2、主机组（host group）：主机的逻辑容器，可以包含主机和模板，但同一个组织内的主机和模板不能互相链接；主机组通常在给用户或用户组指派监控权限时使用；

3、监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是zabbix进行数据收集的核心，相对某个监控对象，每个item都由”key”标识；

4、触发器（trigger）：一个表达式，用于评估某监控对象的特定item内接收到的数据是否在合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从”OK”转变为”Problem”，当数据再次恢复到合理范围，又转变为”OK”；

5、事件（event）：触发一个值得关注的事情，比如触发器状态转变，新的agent或重新上线的agent的自动注册等；

6、动作（action）：指对于特定事件事先定义的处理方法，如发送通知，何时执行操作；

7、报警升级（escalation）：发送警报或者执行远程命令的自定义方案，如每隔5分钟发送一次警报，共发送5次等；

8、媒介（media）：发送通知的手段或者通道，如Email、Jabber或者SMS等；

9、通知（notification）：通过选定的媒介向用户发送的有关某事件的信息；

10、远程命令（remote command）：预定义的命令，可在被监控主机处于某特定条件下时自动执行；

11、模板（template）：用于快速定义被监控主机的预设条目集合，通常包含了item、trigger、graph、screen、application以及low-level discovery rule；模板可以直接链接至某个主机；

12、应用（application）：一组item的集合；

13、web场景（web scennario）：用于检测web站点可用性的一个活多个HTTP请求；

14、前端（frontend）：Zabbix的web接口；

image.png

常用的监控架构平台

• server-agentd模式

由zabbix server向zabbix agent发出指令获取数据，即zabbix agent被动的去获取数据并返回给zabbix

server，zabbix server周期性的向agent 索取数据，这总模式的最大问题就是会加大zabbix

server的工作量，在数百台服务器的环境下zabbix server不能及时获取到最新数据，但这也是默认的工作方式。

这个是最简单的架构了，常用于监控主机比较少的情况下。

• server-proxy-agentd模式:

这个常用于比较多的机器，使用proxy进行分布式监控，有效的减轻server端的压力。