嘉宾简介：
高俊峰(南非蚂蚁)，Linux资深技术专家，畅销书籍《循序渐进Linux》、《高性能Linux服务器构建实战》作者，曾就职于新浪、万网，具有多年的自动化运维和管理经验，擅长Linux、集群应用、MySQL、Oracle等方面的系统管理、性能调优，规划设计，实战经验丰富。
目前关注于Hadoop数据平台以及和Hadoop相关的生态系统的运维、监控、部署、优化等技术。
前言
大家好，我是爱维Linux的南非蚂蚁，今天跟大家一起分享如何构建统一的运维监控平台。
谈到运维，监控应该是运维的重中之重。也有很多人说监控是运维的第三只眼睛，一个好的监控平台对运维工作来说，有很大的帮助。那么，如何构建一个完善的监控平台，就是我们今天要讨论的话题。
从我个人的理解来说，运维的核心工作其实是监控和故障处理这两个方面的内容。所以，首先要对业务系统有一个精确、完善的监控，这样能够保证在第一时间发现问题并通知相关人员解决。
其实出现问题了并不可怕，可怕的是我们很久都没有发现问题，而是被客户发现我们的业务系统出了故障，这就是个很严重的问题了。这些故障其实靠业务系统监控平台就可以完成。
统一监控报警平台设计思路
构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平台中。
并通过消除管理软件的差别，数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。
智能运维监控平台六大层
智能的运维监控平台，设计架构从低到高可以分为6层，三大模块，请看下图：
智能运维监控平台三大模块
在这6层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取模块和监控报警模块，每个模块完成的功能如下：
平台总览
下面根据上面的设计架构图的思路形成一个运维监控平台实现拓扑图，请看下图：
从图中可以看出，主要有三大部分组成，分别是数据收集模块、数据抽取模和监控报警模块。
其中，数据抽取模块用于其它两个模块之间的数据通信，而数据收集模块可以有一台或多台数据收集服务器组成，每个数据收集服务器可以直接从服务器群组收集各种数据指标，经过规范数据格式，最终将数据存储到数据收集服务器中。
监控报警模块通过数据抽取模块从数据收集服务器获取需要的数据，然后对数据设置报警阀值、报警联系人等，最终实现实时报警，报警方式支持手机短信报警、邮件报警等，另外，也可以通过插件或者自定义脚本来扩展报警方式。这样一整套监控报警平台就基本实现了。
Ganglia作为数据收集模块
Ganglia是一款为HPC(高性能计算)集群而设计的可扩展的分布式监控系统，它可以监视和显示集群中的节点的各种状态信息。
它由运行在各个节点上的gmond守护进程来采集cpu、mem、硬盘利用率、I/O负载、网络流量情况等方面的数据，然后汇总到gmetad守护进程下，使用rrdtools存储数据，最后将历史数据以曲线方式通过php页面呈现。
Ganglia特点如下：
Ganglia通过gmond完成自定义监控，现成可利用的模块有很多，地址如下：
https://github.com/ganglia/gmond_python_modules
基于以上Ganglia这些优点，使它非常适合作为监控报警平台的数据收集模块。虽然Cacti/Zabbix也可以实现数据的收集和图形报表的展示，但是当监控节点越来越多时，Cacti和Zabbix的缺点就慢慢暴露出来了，数据收集的准确性、实时性就很难得到保障了。
因此，要构建一个高性能的监控报警平台，Ganglia是首选的数据收集模块。我们之前在线上监控三地机房10000多台服务器，性能表现稳定，数据报警延时基本在10s左右。
Centreon作为监控报警模块
有了Ganglia收集数据还是不够的，运维人员不可能天天盯着数据报表。
因此，还需要对收集到的数据进行监控和报警：
对每个需要监控的主机或服务，设置一个报警阀值，当收集到的数据超过这个阀值时，在第一时间能自动报警并通知到运维人员，而如果收集到的数据没有超过指定的报警阀值，运维人员就可以去做别的事情，而不用时刻盯着数据报表，这是构建智能监控报警平台必须要实现的一个功能。
对主机或服务的状态值进行监控，当达到指定阀值时进行报警，要实现这个功能并不是什么难的事情，可以写个简单的脚本就能实现，但是这样太原始了，没有层次，维护性差，并且当需要监控报警的主机或服务越来越多时，脚本的性能就变得很差，管理也非常不方便，更别说有什么可视化效果了，因此，就需要有一个专业的监控报警工具来实现这个功能。
Centreon是一款功能强大的分布式IT监控系统，它通过第三方组件可以实现对网络、操作系统和应用程序的监控，它的特点如下：
Centreon通过第三方组件可以实现对网络、操作系统和应用程序的监控与报警。
在数据层，Centreon通过ndoutil模块将监控到的数据定时写入数据库中。
在展示层，Centreon提供了Web界面来配置、管理需要监控的主机或服务，并提供多种报警通知方式，同时还可以展现监控数据和报警状态，并可查询历史报警记录。
Ganglia与Centreon的无缝整合
Nagios和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是如何实现数据的传输和收集的，请看下图：
基本流程如下：
至此，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人。
转载请注明：安全专题
