Cacti,Nagios,Zabbix,centreon,Ganglia 对比

一、cacti

Cacti 是一套基于 PHP,MySQL,SNMP 及 RRDTool 开发的网络流量监测图形分析工具。 简单的说 Cacti 就是一个 PHP 程序。它经过使用 SNMP 协议获取远端网络设备和相关信息，

（其实就是使用 Net-SNMP 软件包的 snmpget 和 snmpwalk 命令获取）并经过 RRDTOOL 工 具绘图，经过 PHP 程序展示出来。咱们使用它能够展示出监控对象一段时间内的状态或者 性能趋势图。

二、nagios

Nagios 是一款开源的免费网络监视工具，能有效监控 Windows、Linux 和 Unix 的主机状 态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第 一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。

三、zabbix

zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源 解决方案。zabbix 能监视各类网络参数，保证服务器系统的安全运营；并提供柔软的通知机 制以让系统管理员快速定位/解决存在的各类问题。

zabbix 由 2 部分构成，zabbix server 与可选组件 zabbix agent。zabbix server 能够经过 SNMP， zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能， 它能够运行在 Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X 等平台上。

四、ganglia

Ganglia 是一款为 HPC（高性能计算）集群而设计的可扩展的分布式监控系统，它能够监视 和显示集群中的节点的各类状态信息，它由运行在各个节点上的 gmond 守护进程来采集 CPU 、内存、硬盘利用率、I/O 负载、网络流量状况等方面的数据，而后汇总到 gmetad 守 护进程下，使用 rrdtool 存储数据，最后将历史数据以曲线方式经过 PHP 页面呈现。 Ganglia 监控系统有三部分组成，分别是 gmond、gmetad、webfrontend。

 

五、centreon

Centreon 是一款功能强大的分布式 IT 监控系统，它经过第三方组件能够实现对网络、 操做系统和应用程序的监控：首先，它是开源的，咱们能够无偿使用它；其次，它的底层采
用 nagios 做为监控软件，同时 nagios 经过 ndoutil 模块将监控到的数据定时写入数据库中， 而 Centreon 实时从数据库读取该数据并经过 Web 界面展示监控数据；，最后，咱们能够通

过 Centreon 管理和配置 nagios，或者说 Centreon 就是 nagios 的一个管理配置工具，经过

Centreon 提供的 Web 配置界面，能够轻松完成 nagios 的各类繁琐配置。

六、对比图

 

2、
统一运维监控平台设计思路

 

构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将全部业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等归入统一的运维监控平 台中，并经过消除管理软件的差异，数据采集手段的差异，对各类不一样的数据来源实现统一 管理、统一规范、统一处理、统一展示、统一用户登陆、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。

智能的运维监控平台，设计架构从低到高能够分为 6 层，三大模块，以下图：

 

 

 
 

 

图 1

q 数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操做 系统数据等，而后将收集到的数据进行规范化并进行存储。

q 数据展现层：位于第二层，是一个 Web 展现界面，主要是将数据收集层获取到的 数据进行统一展现，展现的方式能够是曲线图、柱状图、饼状态等，经过将数据图 形化，能够帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并做 为运维人员排查问题或解决问题的依据。

q 数据提取层：位于第三层，主要是对从数据收集层获取到的数据进行规格化和过滤 处理，提取须要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。

q 报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、 报警阀值设置、报警联系人设置和报警方式设置等。

q 报警事件生成层：位于第五层，主要是对报警事件进行实时记录，将报警结果存入 数据库以备调用，并将报警结果造成分析报表，以统计一段时间内的故障率和故障 发生趋势。

q 用户展现管理层：位于最顶层，是一个 Web 展现界面，主要是将监控统计结果、 报警故障结果进行统一展现，并实现多用户、多权限管理，实现统一用户和统一权 限控制。

在这 6 层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取

 

模块和监控报警模块，每一个模块完成的功能以下：

q 数据收集模块：此模块主要完成基础数据的收集与图形展现。数据收集的方式有很 多种，能够经过 SNMP 实现，也能够经过代理模块实现，还能够经过自定义脚本 实现。经常使用的数据收集工具备 Cacti、Ganglia 等。

q 数据提取模块：此模板主要完成数据的筛选过滤和采集，将须要的数据从数据收集 模块提取到监控报警模块中。能够经过数据收集模块提供的接口或自定义脚本实现 数据的提取。

q 监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、 报警联系人设置等，并将报警结果进行集中展示和历史记录。常见的监控报警工具 有 Nagios、Centreon 等。

在了解了运维监控平台的通常设计思路以后，接下来详细介绍下如何经过软件实现这样 一个智能运维监控系统。

下图 2 是根据图 1 的设计思路造成的一个运维监控平台实现拓扑图，从图中能够看出， 主要有三大部分组成，分别是数据收集模块、监控报警模块和数据提取模块，其中，数据提 取模块用于其余两个模块之间的数据通讯，而数据收集模块能够有一台或多台数据收集服务 器组成，每一个数据收集服务器能够直接从服务器群组收集各类数据指标，通过规范数据格式，

最终将数据存储到数据收集服务器中。监控报警模块经过数据抽取模块从数据收集服务器获 取须要的数据，而后设置报警阀值、报警联系人等，最终实现实时报警。报警方式支持手机 短信报警、邮件报警等，另外，也能够经过插件或者自定义脚原本扩展报警方式。这样一整 套监控报警平台就基本实现了。

 

 

 

图 2

3、企业运维监控平台选型

一、中小企业监控平台选择 Zabbix 

Zabbix 是一款综合了数据收集、数据展现、数据提取、监控报警配置、用户展现等方面 的一款综合运维监控平台。

Zabbix 学习入门较快，功能也很强大，是一个能够迅速用起来的监控软件，可以知足中 小企业（服务器数 500 台一下）的监控报警需求，所以是中小型企业运维监控的首选平台。

可是，Zabbix 当监控服务器数量较多时，会产生不少问题，如监控数据不及时、报警超 时等等问题，这是由于 Zabbix 对服务器性能要求较高，当监控的服务器数量超过 500 台后， 监控性能急剧降低，此时须要进行分布式监控部署，而且须要提高监控服务器的性能。

安全性方面，Zabbix 客户端的 agent 若是故障，收集到的数据将丢失，同时 Zabbix Server

也是单点，可能还须要对 Zabbix Server 作 HA 保证数据的安全和监控的高可用。

 

二、互联网大企业监控平台选择 Ganglia+Centreon

 

开源监控软件组合应用+二次开发
是大型互联网企业构建监控平台的一个基本策略，

 

对于有海量服务器、多业务系统的复杂监控，没有哪一个软件能独立完成企业的全部监控需求， 所以，多种开源监控软件组合应用+二次开发才是监控平台的最终方向。

推荐 ganglia 是由于 ganglia 客户端软件对服务资源占用很是低，而且扩展插件很是多，

监控扩展也很是容易，同时结合专业的 web 监控平台 centreon，能够实如今数据收集、数 据展现、数据提取、监控报警配置、用户展现等方面的完美配合，所以这里对海量服务器进

行监控咱们推荐 ganglia+centreon 组合。

为何选择 ganglia+centreon 组合，咱们后面课程会陆续进行详细深刻的介绍。

 

3. Zabbix 的运行架构

 
 

一、组件

1）、Zabbix Server：负责接收agent 发送的报告信息的核心组件，全部配置，统计数据及操

做数据均由其组织进行；

2）、Database Storage：专用于存储全部配置信息，以及由zabbix 收集的数据；

3）、Web interface：zabbix 的GUI 接口，一般与Server 运行在同一台主机上；

4）、Proxy：可选组件，经常使用于分布监控环境中，代理Server 收集部分被监控端的监控数据

并统一发往Server 端；

5 )、Agent：部署在被监控主机上，负责收集本地数据并发往Server 端或Proxy 端；

注：zabbix node 也是 zabbix server 的一种 。

 

二、进程

 

默认状况下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。

 

三、zabbix 监控环境中相关术语

 

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

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

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

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

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

l 动做（action）：指对于特定事件事先定义的处理方法，如发送通知，什么时候执行操做；

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

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

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