嘉宾简介：
高俊峰(南非蚂蚁)，Linux资深技术专家，畅销书籍《循序渐进Linux》、《高性能Linux服务器构建实战》作者，曾就职于新浪、万网，具有多年的自动化运维和管理经验，擅长Linux、集群应用、MySQL、Oracle等方面的系统管理、性能调优，规划设计，实战经验丰富。
目前关注于Hadoop数据平台以及和Hadoop相关的生态系统的运维、监控、部署、优化等技术。
前言
大家好，我是爱维Linux的南非蚂蚁，今天跟大家一起分享如何构建统一的运维监控平台。
谈到运维，监控应该是运维的重中之重。也有很多人说监控是运维的第三只眼睛，一个好的监控平台对运维工作来说，有很大的帮助。那么，如何构建一个完善的监控平台，就是我们今天要讨论的话题。
从我个人的理解来说，运维的核心工作其实是监控和故障处理这两个方面的内容。所以，首先要对业务系统有一个精确、完善的监控，这样能够保证在第一时间发现问题并通知相关人员解决。
其实出现问题了并不可怕，可怕的是我们很久都没有发现问题，而是被客户发现我们的业务系统出了故障，这就是个很严重的问题了。这些故障其实靠业务系统监控平台就可以完成。
统一监控报警平台设计思路
构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平台中。
并通过消除管理软件的差别，数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。
智能运维监控平台六大层
智能的运维监控平台，设计架构从低到高可以分为6层，三大模块，请看下图：
- 数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操作系统数据等，然后将收集到的数据进行规范化，并进行存储。
- 数据展示层：位于第二层，是一个web展示界面，主要是将数据收集层获取到的数据进行统一展示，展示的方式可以是曲线图、柱状图、饼状态等，通过将数据图形化，可以帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并作为运维人员排查问题或解决问题的依据。
- 数据提取层：位于第三层，主要是将数据收集层获取到的数据进行规格化和过滤处理，提取需要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。
- 报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、报警阀值设置、报警联系人设置和报警方式设置等。
- 报警事件生成层：位于第五层，主要是将报警事件进行实时记录，并将报警结果存入数据库以备调用，并将报警结果形成分析报表，以统计一段时间内的故障率和故障发生趋势。
- 用户展示管理层：位于最顶层，是一个web展示界面，主要是将监控统计结果、报警故障结果进行统一展示，并实现多用户、多权限管理，实现统一用户和统一权限控制。
智能运维监控平台三大模块
在这6层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取模块和监控报警模块，每个模块完成的功能如下：
- 数据收集模块：此模块主要完成基础数据的收集与图形展示，数据收集的方式有很多种，可以通过SNMP实现，也可以通过代理模块实现，还可以通过自定义脚本实现，这里采用数据收集工具Ganglia来实现。
- 数据提取模块：此模板主要完成数据的筛选过滤和采集，将需要的数据从数据收集模块提取到监控报警模块中。可以通过数据收集模块提供的接口或者自定义脚本实现数据的提取。
- 监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、报警联系人设置等，并将报警结果进行集中展现和历史记录，常见的监控报警工具有Nagios、Centreon等。
平台总览
下面根据上面的设计架构图的思路形成一个运维监控平台实现拓扑图，请看下图：
从图中可以看出，主要有三大部分组成，分别是数据收集模块、数据抽取模和监控报警模块。
其中，数据抽取模块用于其它两个模块之间的数据通信，而数据收集模块可以有一台或多台数据收集服务器组成，每个数据收集服务器可以直接从服务器群组收集各种数据指标，经过规范数据格式，最终将数据存储到数据收集服务器中。
监控报警模块通过数据抽取模块从数据收集服务器获取需要的数据，然后对数据设置报警阀值、报警联系人等，最终实现实时报警，报警方式支持手机短信报警、邮件报警等，另外，也可以通过插件或者自定义脚本来扩展报警方式。这样一整套监控报警平台就基本实现了。
Ganglia作为数据收集模块
Ganglia是一款为HPC(高性能计算)集群而设计的可扩展的分布式监控系统，它可以监视和显示集群中的节点的各种状态信息。
它由运行在各个节点上的gmond守护进程来采集cpu、mem、硬盘利用率、I/O负载、网络流量情况等方面的数据，然后汇总到gmetad守护进程下，使用rrdtools存储数据，最后将历史数据以曲线方式通过php页面呈现。
Ganglia特点如下：
- 灵活的分布式、分层体系结构，使Ganglia支持上万个监控节点的数据收集，并且性能表现稳定，同时，Ganglia也可以根据地域环境、网络结构的不同，分地域、分层次的灵活部署Ganglia数据收集点，而对于数据收集节点可以动态添加或删除，对Ganglia整体监控不产生任何影响。因此，可以灵活的扩展Ganglia数据收集节点。
- Ganglia收集到的数据更加精确，它不但可以收集实时数据，以图表的形式展示出来，而且还允许用户查看历史统计数据，因此，用户可以通过这些数据，做出性能调整、升级、扩容等决策，从而保证应用系统能够满足不断增长的业务需求。
- Ganglia可以通过组播、单播的方式收集数据，在监控的节点较多时通过组播方式收集数据可以大大降低数据收集的负载，提高监控和数据收集性能。而对于不能使用组播收集数据的网络环境，还可以通过单播的方式收集数据，因此Ganglia在数据收集方式上非常灵活。
- Ganglia可收集各种度量的数据，Ganglia默认情况下可收集cpu、memory、disk、I/O、process、network六大方面的数据，同时Ganglia提供了C或者Python接口，用户通过这个接口可以自定义数据收集模块，并且这些模块可以被直接插入到Ganglia中以监控用户自定义的应用。
Ganglia通过gmond完成自定义监控，现成可利用的模块有很多，地址如下：
https://github.com/ganglia/gmond_python_modules
基于以上Ganglia这些优点，使它非常适合作为监控报警平台的数据收集模块。虽然Cacti/Zabbix也可以实现数据的收集和图形报表的展示，但是当监控节点越来越多时，Cacti和Zabbix的缺点就慢慢暴露出来了，数据收集的准确性、实时性就很难得到保障了。
因此，要构建一个高性能的监控报警平台，Ganglia是首选的数据收集模块。我们之前在线上监控三地机房10000多台服务器，性能表现稳定，数据报警延时基本在10s左右。
Centreon作为监控报警模块
有了Ganglia收集数据还是不够的，运维人员不可能天天盯着数据报表。
因此，还需要对收集到的数据进行监控和报警：
对每个需要监控的主机或服务，设置一个报警阀值，当收集到的数据超过这个阀值时，在第一时间能自动报警并通知到运维人员，而如果收集到的数据没有超过指定的报警阀值，运维人员就可以去做别的事情，而不用时刻盯着数据报表，这是构建智能监控报警平台必须要实现的一个功能。
对主机或服务的状态值进行监控，当达到指定阀值时进行报警，要实现这个功能并不是什么难的事情，可以写个简单的脚本就能实现，但是这样太原始了，没有层次，维护性差，并且当需要监控报警的主机或服务越来越多时，脚本的性能就变得很差，管理也非常不方便，更别说有什么可视化效果了，因此，就需要有一个专业的监控报警工具来实现这个功能。
Centreon是一款功能强大的分布式IT监控系统，它通过第三方组件可以实现对网络、操作系统和应用程序的监控，它的特点如下：
- 它是开源的，我们可以免费使用它。
- 底层与Nagios紧密集成，它的底层采用nagios作为监控软件(目前官方已经开发出了自己的底层监控)，同时nagios通过ndoutil模块将监控到的数据定时写入数据库中，而Centreon实时从数据库读取该数据并通过Web界面展现监控数据。
- 可以通过Centreon管理和配置nagios，或者说Centreon就是nagios的一个管理配置工具，通过Centreon提供的Web配置界面，可以轻松完成nagios的各种繁琐配置。
- 支持多种插件，Centreon还支持NRPE、SNMP、NSClient等插件，可以通过这些插件构建分布式的监控报警系统。
Centreon通过第三方组件可以实现对网络、操作系统和应用程序的监控与报警。
在数据层，Centreon通过ndoutil模块将监控到的数据定时写入数据库中。
在展示层，Centreon提供了Web界面来配置、管理需要监控的主机或服务，并提供多种报警通知方式，同时还可以展现监控数据和报警状态，并可查询历史报警记录。
Ganglia与Centreon的无缝整合
Nagios和Ganglia都是很好的数据中心监控工具，虽然它们的功能有重叠部分，但是两者对监控的侧重点并不相同：
- Ganglia侧重于收集数据，并随时跟踪数据状态。通过Ganglia不但可以看到数据的历史状态，也可以预计数据的未来发展趋势，为我们的应用程序修正和硬件采购提供决策。
- Nagios更侧重于监控数据并进行过载报警。
综合Ganglia和Nagios的优缺点，同时运行这两个工具可以相互弥补它们的不足：
- Ganglia暂时没有内置报警通知机制，而Nagios这方面是强项。
- Nagios没有内置代理和分布式监控机制，而Ganglia设计之初就考虑到了这些。
- Nagios没有直观的报表展示(虽然可通过PNP插件实现)，而Ganglia报表功能很强大。
- Ganglia内置了基于很多开发接口，通过这些接口，可以将Ganglia统计到的数据纳入Nagios监控之下。
确定了以Ganglia作为数据收集模块，Centreon作为监控报警模块的方案。
这样，一个智能监控报警平台两大主要功能模块已经基本实现了，但现在的问题是：如何将收集到的数据传送给监控报警模块呢?这就是数据抽取模块要完成的功能。
数据抽取模块要完成的功能
从数据收集模块中定时采集指定的数据，然后将采集到的数据与指定的报警阀值进行比较。如果发现采集到的数据大于或小于指定的报警阀值，那么就通过监控报警模块设置的报警方式进行故障通知。
这个过程，只有采集数据是在数据收集模块中完成，其他操作，例如，采集数据时间间隔、报警阀值设置、报警方式设置、报警联系人设置等都在监控报警模块中完成的。
从数据抽取模块完成的功能可以看出，此模块主要用来衔接数据收集模块和监控报警模块，进而完成Ganglia和Centreon的无缝整合。
要实现数据抽取模块的功能，没有现成的方法可用，需要在ganglia基础上做二次开发，较简单的方法是通过程序在ganglia上开发一个数据提取接口，然后将数据抽取到nagios中，初步方案是通过python程序来实现。
当然也有现成的方案，推荐两个现成的数据提取脚本：
PHP版本：
http://www.iivey.com/ganglia/check_ganglia_metric.php.txt
Python版本：
http://www.iivey.com/ganglia/check_ganglia_metric.py.txt
统一监控系统架构图
下面看看整个监控平台的系统架构：
Cluster1-N均为分布式集群，也可以认为是机房数据中心。每个数据中心的Node server都运行一个Gmond守护进程，进行数据收集，将收集到的数据汇总到Ganglia proxy主机，Ganglia proxy主机上运行着Gmetad守护进程。
同时Ganglia proxy和Node server都加载通过C或者Python编写的Ganglia插件，扩展Ganglia监控功能。
Manager Server是管理主机，主要用于收集各个数据中心的监控数据，通过数据抽取模块将Nagios和Ganglia整合到一起。
考虑到数据的安全性及服务可用性，Manager Server建议做一个备机，平时主机和备机同时工作，进行数据收集，主机故障时，自动切换到备机，保证管理主机高可用。
监控数据和报表通过Web方式展示出来，将Nagios和Ganglia的web进行整合，并作二次开发，通过一个统一的界面展示监控状态和报表信息。
Ganglia数据流向图
在Ganglia分布式监控系统中，gmond和gmetad之间是如何传输数据呢?接下来介绍一下Ganglia是如何实现数据的传输和收集的，请看下图：
基本流程如下：
- gmond收集本机的监控数据，发送到其他机器上，并收集其他机器的监控数据，gmond之间通过udp通信，传递文件格式为XDL。
- gmond节点间的数据传输方式除支持单播点对点传送外，还支持多播传送。
- gmetad周期性的去gmond节点或者gmetad节点pull数据，gmetad只有tcp通道，gmond与gmetad之间的数据都以XML格式传输。
- gmetad既可以从gmond也可以从其他的gmetad得到xml数据。
- gmetad将获取到的数据更新到rrds数据库中。
- Nagios通过数据抽取模块监控ganglia获取到的数据并进行报警。
- 通过web监控界面，从Gmetad取数据，并且读取rrd数据库，生成图片显示出来。
至此，ganglia内部结构完全剖析。
这样，一个完整的运维监控平台就构建起来了。我们通过这种架构做运维监控平台，已经稳定运行3年多，监控1万2千多台服务器。
问答环节
问题1：gmetad是单机吗?1万台主机的监控gmetad需要什么配置?
回答：gmetad是数据收集核心，不建议单机，至少两台做成主备模式，1w台主机分布在3个机房，gmetad做成分布式结构，本身ganglia也支持分布式数据汇总，这个看刚才的数据流向图就可以看到。
问题2：告警策略，只有大于XX或小于XX吗?还有其他策略吗?
回答：告警策略都集成在了Centreon里面，设置策略很灵活，大于、小于、等于，重试次数、间隔等，都可以设置，这个根据自己需要来定义即可。
问题3：中间件，数据库的监控内容是什么?
回答：监控内容需根据业务需求进行自定义，通常监控内容有三种类型：
- 系统底层数据。
- 业务系统无逻辑关系数据。
- 业务系统有逻辑关系数据。
定义监控内容，加入到监控报警平台即可。
问题4：Gmond收集本机的监控数据，发送到其他机器上，并收集其他机器的监控数据，gmond之间通过udp通信，传递文件格式为XDL，这个怎么理解?
回答：gmond支持单播和组播收集和发送数据，单播仅仅是上报数据到上级节点，组播是互相收集数据，然后上报，传递文件格式是xdl的，通过telnet gmond端口可以看到发送的数据格式。
问题5：监控平台支持对window、linux全平台的监控吗?
回答：支持全平台监控，支持各种系统平台、网络、交换机等。
问题6：咱们监控系统是有专门的团队维护吗?
回答：我们的监控平台有运维团队维护并做二次开发。
问题7：支持波动监控吗?
回答：波动监控是肯定存在的，本身udp方式发送数据，数据更新速度很快，最重要一点，ganglia非常适合做分布式多机房监控，各个机房通过vpn传输数据，网络间的波动影响，可以通过监控参数调整。
问题8：一万多台机器，有多少个监控项?每天多少告警?
回答：我们的数据监控项超过1w，每次获取的xdl数据都在20-30M左右，核心数据是hadoop，这种方式建议通过单播来收集，因为组播对网络消耗较大。
问题9：文中提到1w台服务器监控延时三，秒如果有些监控点取数执行时间太长，做不到这么快速，怎么规避?如果机器本来资源不足，频繁跑监控，机器会不会挂?
回答：我们最大延时报警是10s，每个节点都是gmond在获取数据，gmond是主动发送数据到上级的gmond，因此消耗很小，几乎可以忽略不计，需要关注的是上级gmond数据汇聚点，这些服务器需要配置高性能cpu和磁盘，因此磁盘io消耗极大，对于执行时间过长的监控点，可以设置超时机制，这种情况一般是跨机房监控会出现，机房内部基本不会出现这种情况。
选ganglia就是看中了gmond对客户端资源消耗很小的缘故。
问题10：监控运维和开发团队有多少人?
回答：6个人，开发运维2人，系统(业务)运维3人，网络运维1人。
