1、cacti
Cacti 是一套基于 PHP,MySQL,SNMP 及 RRDTool 开发的网络流量监测图形分析工具。 简单的说 Cacti 就是一个 PHP 程序。它通过使用 SNMP 协议获取远端网络设备和相关信息，
（其实就是使用 Net-SNMP 软件包的 snmpget 和 snmpwalk 命令获取）并通过 RRDTOOL 工 具绘图，通过 PHP 程序展现出来。我们使用它可以展现出监控对象一段时间内的状态或者 性能趋势图。
2、nagios
Nagios 是一款开源的免费网络监视工具，能有效监控 Windows、Linux 和 Unix 的主机状 态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第 一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
3、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 等平台上。
4、ganglia
Ganglia 是一款为 HPC（高性能计算）集群而设计的可扩展的分布式监控系统，它可以监视 和显示集群中的节点的各种状态信息，它由运行在各个节点上的 gmond 守护进程来采集 CPU 、内存、硬盘利用率、I/O 负载、网络流量情况等方面的数据，然后汇总到 gmetad 守 护进程下，使用 rrdtool 存储数据，最后将历史数据以曲线方式通过 PHP 页面呈现。 Ganglia 监控系统有三部分组成，分别是 gmond、gmetad、webfrontend。
5、centreon
Centreon 是一款功能强大的分布式 IT 监控系统，它通过第三方组件可以实现对网络、 操作系统和应用程序的监控：首先，它是开源的，我们可以免费使用它；其次，它的底层采
用 nagios 作为监控软件，同时 nagios 通过 ndoutil 模块将监控到的数据定时写入数据库中， 而 Centreon 实时从数据库读取该数据并通过 Web 界面展现监控数据；，最后，我们可以通
过 Centreon 管理和配置 nagios，或者说 Centreon 就是 nagios 的一个管理配置工具，通过
Centreon 提供的 Web 配置界面，可以轻松完成 nagios 的各种繁琐配置。
6、对比图
二、
统一运维监控平台设计思路
构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平 台中，并通过消除管理软件的差别，数据采集手段的差别，对各种不同的数据来源实现统一 管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。
智能的运维监控平台，设计架构从低到高可以分为 6 层，三大模块，如下图：
图 1
q 数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操作 系统数据等，然后将收集到的数据进行规范化并进行存储。
q 数据展示层：位于第二层，是一个 Web 展示界面，主要是将数据收集层获取到的 数据进行统一展示，展示的方式可以是曲线图、柱状图、饼状态等，通过将数据图 形化，可以帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并作 为运维人员排查问题或解决问题的依据。
q 数据提取层：位于第三层，主要是对从数据收集层获取到的数据进行规格化和过滤 处理，提取需要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。
q 报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、 报警阀值设置、报警联系人设置和报警方式设置等。
q 报警事件生成层：位于第五层，主要是对报警事件进行实时记录，将报警结果存入 数据库以备调用，并将报警结果形成分析报表，以统计一段时间内的故障率和故障 发生趋势。
q 用户展示管理层：位于最顶层，是一个 Web 展示界面，主要是将监控统计结果、 报警故障结果进行统一展示，并实现多用户、多权限管理，实现统一用户和统一权 限控制。
在这 6 层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取
模块和监控报警模块，每个模块完成的功能如下：
q 数据收集模块：此模块主要完成基础数据的收集与图形展示。数据收集的方式有很 多种，可以通过 SNMP 实现，也可以通过代理模块实现，还可以通过自定义脚本 实现。常用的数据收集工具有 Cacti、Ganglia 等。
q 数据提取模块：此模板主要完成数据的筛选过滤和采集，将需要的数据从数据收集 模块提取到监控报警模块中。可以通过数据收集模块提供的接口或自定义脚本实现 数据的提取。
q 监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、 报警联系人设置等，并将报警结果进行集中展现和历史记录。常见的监控报警工具 有 Nagios、Centreon 等。
在了解了运维监控平台的一般设计思路之后，接下来详细介绍下如何通过软件实现这样 一个智能运维监控系统。
下图 2 是根据图 1 的设计思路形成的一个运维监控平台实现拓扑图，从图中可以看出， 主要有三大部分组成，分别是数据收集模块、监控报警模块和数据提取模块，其中，数据提 取模块用于其他两个模块之间的数据通信，而数据收集模块可以有一台或多台数据收集服务 器组成，每个数据收集服务器可以直接从服务器群组收集各种数据指标，经过规范数据格式，
最终将数据存储到数据收集服务器中。监控报警模块通过数据抽取模块从数据收集服务器获 取需要的数据，然后设置报警阀值、报警联系人等，最终实现实时报警。报警方式支持手机 短信报警、邮件报警等，另外，也可以通过插件或者自定义脚本来扩展报警方式。这样一整 套监控报警平台就基本实现了。
图 2
三、企业运维监控平台选型
1、中小企业监控平台选择 Zabbix
Zabbix 是一款综合了数据收集、数据展示、数据提取、监控报警配置、用户展示等方面 的一款综合运维监控平台。
Zabbix 学习入门较快，功能也很强大，是一个可以迅速用起来的监控软件，能够满足中 小企业（服务器数 500 台一下）的监控报警需求，因此是中小型企业运维监控的首选平台。
但是，Zabbix 当监控服务器数量较多时，会产生很多问题，如监控数据不及时、报警超 时等等问题，这是因为 Zabbix 对服务器性能要求较高，当监控的服务器数量超过 500 台后， 监控性能急剧下降，此时需要进行分布式监控部署，并且需要提升监控服务器的性能。
安全性方面，Zabbix 客户端的 agent 如果故障，收集到的数据将丢失，同时 Zabbix Server
也是单点，可能还需要对 Zabbix Server 做 HA 保证数据的安全和监控的高可用。
2、互联网大企业监控平台选择 Ganglia+Centreon
开源监控软件组合应用+二次开发
是大型互联网企业构建监控平台的一个基本策略，
对于有海量服务器、多业务系统的复杂监控，没有哪个软件能独立完成企业的所有监控需求， 因此，多种开源监控软件组合应用+二次开发才是监控平台的最终方向。
推荐 ganglia 是因为 ganglia 客户端软件对服务资源占用非常低，并且扩展插件非常多，
监控扩展也非常容易，同时结合专业的 web 监控平台 centreon，可以实现在数据收集、数 据展示、数据提取、监控报警配置、用户展示等方面的完美配合，因此这里对海量服务器进
行监控我们推荐 ganglia+centreon 组合。
为什么选择 ganglia+centreon 组合，我们后面课程会陆续进行详细深入的介绍。
3. Zabbix 的运行架构
1、组件
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 的一种 。
2、进程
默认情况下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。
3、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 接口；