如果你是一个经验丰富的运维开发人员，那么你一定知道Ganglia、Nagios、Zabbix、Elasticsearch、Grafana等组件。这些开源组件都有着深厚的发展背景及功能价值，但如何做到合理搭配选择，如何配比资源从而达到性能的最优，这里就体现了运维人的深厚功力。

下文中，联通大数据平台维护团队将对几种常见监控组合进行介绍，并基于丰富的实战经验，对集群主机及其接口机监控进行系统性总结。

一、几种常见的监控工具选择

目前常见的监控组合如下：

Nagios、Ganglia、Zabbix属于较早期的开源监控工具，而grafana、prometheus则属于后起之秀。下面，将分别介绍三种监控告警方式的背景及其优缺点：

1、Nagios+Ganglia

Nagios最早是在1999年以“NetSaint”发布，主要应用在Linux和Unix平台环境下的监控告警，能够监控网络服务、主机资源，具备并行服务检查机制。

其可自定义shell脚本进行告警，但随着大数据平台承载的服务、数据越来越多之后，Nagios便逐渐不能满足使用场景。

例如：其没有自动发现的功能，需要修改配置文件；只能在终端进行配置，不方便扩展，可读性比较差；时间控制台功能弱，插件易用性差；没有历史数据，只能实时报警，出错后难以追查故障原因。

Ganglia是由UC Berkeley发起的一个开源监控项目，设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web前端。

主要用来监控系统性能，如：cpu 、mem、硬盘利用率，I/O负载、网络流量情况等，通过曲线很容易见到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能起到重要作用。

但随着服务、业务的多样化，ganglia覆盖的监控面有限，且自定义配置监控比较麻烦，展示页面查找主机繁琐、展示图像粗糙不精确是其主要缺点。

2、Zabbix

Zabbix是近年来兴起的监控系统，易于入门，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发，难度较大；此外，系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多；并且自定义的项目报警需要自己设置，过程比较繁琐。

3、jmxtrans or Telegraf or collect + influxdb or Prometheus or elasticsearch + Grafana +alertmanager

这套监控系统的优势在于数据采集、存储、监控、展示、告警各取所长。性能、功能可扩展性强，且都有活跃的社区支持。缺点在于其功能是松耦合的，较为考验使用者对于使用场景的判断与运维功力。

毕竟，对于运维体系来说，没有“最好”，只有“最适合”。

二、联通大数据平台的监控发展历程

早期，联通大数据平台通过Ganglia与Nagios有效结合，发挥Ganglia的监控优势和Nagios的告警优势，做到平台的各项指标监控。

但随着大数据业务的突增、平台复杂程度的增加，Nagios与Ganglia对平台的监控力度开始稍显不足，并且开发成本过高。主要体现在配置繁琐，不易上手；开发监控采集脚本过于零散，不好统一配置管理，并且Nagios没有历史数据，只能实时报警，出错后难以追查故障原因。

中期，我们在部分集群使用了Zabbix，发现其对于集群层、服务层、角色层及角色实例监控项的多维度监控开发管理相对繁琐，并且如果想要把平台所有机器及业务的监控和告警集成到Zabbix上，对于Zabbix的性能将是很大的挑战。

于是我们采用以Prometheus+ Grafana+ alertmanager为核心组件的监控告警方式，搭建开发以完成对现有大规模集群、强复杂业务的有效监控。

采用PGA（Prometheus+ Grafana+ alertmanager）监控告警平台的原因是其在数据采集选型、存储工具选型、监控页面配置、告警方式选择及配置方面更加灵活，使用场景更加广泛，且功能性能更加全面优秀。

三、平台搭建、组件选型、监控配置的技巧

1、采集丶存储工具的选型

1）采集器选择

常见的采集器有collect、telegraf、jmxtrans（对于暴露jmx端口的服务进行监控）。

笔者在经过对比之后选择了telegraf，主要原因是其比较稳定，并且背后有InfluxData公司支持，社区活跃度不错，插件版本更新周期也不会太长。

Telegraf是一个用Go语言编写的代理程序，可采集系统和服务的统计数据，并写入InfluxDB、prometheus、es等数据库。Telegraf具有内存占用小的特点，通过插件系统，开发人员可轻松添加支持其他服务的扩展。

2）数据库选型

对于数据库选择，笔者最先使用influxdb，过程中需要注意调整增加influxdb的并发能力，并且控制数据的存放周期。

对于上千台服务器的集群监控，如果存储到influxdb里，通过grafana界面查询时，会产生大量的线程去读取influxdb数据，很可能会遇到influxdb读写数据大量超时。

遇到这种情况，可以先查看副本存储策略：SHOW RETENTION POLICIES ON telegraf

再修改副本存储的周期：

ALTER RETENTION POLICY "autogen" ON "telegraf" DURATION 72h REPLICATION 1 SHARD DURATION 24h DEFAULT

需理解以下参数：

但是，由于InfluxDB开源版对于分布式支持不稳定，单机版的InfluxDB服务器对于上千台的服务器监控存在性能瓶颈（数据存储使用的普通sata盘，非ssd）。笔者后来选择使用es或 prometheus联邦来解决（关于es的相关权限控制、搭建、调优、监控维护，以及prometheus的相关讲解将在后续文章具体阐述）。

2、Grafana展示技巧

Grafana是近年来比较受欢迎的一款监控配置展示工具，其优点在于能对接各种主流数据库，并且能在官网及社区上下载精致的模板，通过导入json模板做到快速的展示数据。

1）主机监控项

内核、内存、负载、磁盘io、网络、磁盘存储、inode占用、进程数、线程数。

以一台主机监控展示为样例，大家先看下效果图：

联通大数据公司作为专业的大数据服务运营商，后台支持的主机数量规模庞大，各主机用途大不相同，那么就需要做好主机分类。

用盒子的概念来说，机房是父类盒子，里面放置集群计算节点子盒子和接口机子盒子。集群主机、接口机分离，这样当一台主机故障时，方便更快的查找定位。

主要从cpu占用、内存占用、负载、线程数多个维度统计同一主机群体（如：A机房接口机是一个主机群体，B机房计算节点是一个主机群体）占用资源最多的前十台机器。

通过主机监控大屏和主机资源占用top10定位故障主机的故障时间段和异常指标，只能初步的帮助运维人员排查机器故障的原因。

例如，当机器负载过高时，在主机监控大屏中往往能看出主机的cpu使用，读写io、网络io会发生急速增长，却不能定位是哪个进程导致。当重启故障主机之后，又无法排查历史故障原因。

因此对于主机层面监控，增加了进程资源占用top10，能获取占用cpu，内存最高的进程信息（进程开始运行时间、已运行时长、进程pid、cpu使用率、内存使用率等有用信息）。

这样，当主机因为跑了未经测试的程序，或者因运行程序过多，或程序线程并发数过多时，就能有效的通过历史数据定位机器故障原因。

总结：主机层面可监控项还有很多，关键点在于对症下药，把排查故障的运维经验转化为采集数据的合理流程，再通过数据关联来分析排查故障。

2）平台监控项

平台监控项种类繁多，有HDFS、Yarn、Zookeeper、Kafka、Storm、Spark、HBase等平台服务。

每个服务下有多种角色类别，如hdfs服务中包括Namenode、Datenode、Failover Controller、JournalNode 。每个角色类别下又有多个实例。如此产生的监控指标实例达几十万个。

目前联通大数据使用的CDH版本大数据平台，基础监控指标全面多样。根据现状，平台层面我们主要配置比较关键的一些监控项。

帮助平台管理人员合理评估个队列资源使用情况，快速做出适当调整。

Zeppelin并没有相关的可视化审计日志，通过实时的获取Zeppelin操作日志来展现Zeppelin操作，方便运维人员审计。

实时统计各业务用户的数据目录存储，便于分析HDFS存储增量过大的目录。

当Hadoop集群节点数达到千台左右时，集群业务对于Yarn队列资源使用达到百分之八十以上，且集群写多读少，很容易造成namenode-rpc等待队列深度过大，造成namenode-rpc延迟，这将会严重影响集群整体业务的运行。半小时能跑完的任务，可能会跑数个小时。

根本原因还是集群承载业务数量过多，并且业务逻辑设计不合理，造成Yarn任务执行过程频繁操作HDFS文件系统，产生了大量的rpc操作。更底层的，每个dn节点的磁盘负载也会过高，造成数据读写io超时。

通过提取namenode日志、HDFS审计日志，多维度分析，可通过HDFS目录和HDFS操作类型两个方面确认rpc操作过多的业务。并且根据具体是哪种类型的操作过多，来分析业务逻辑是否合理来进行业务优化。

例如有某大数据业务的逻辑是每秒往HDFS目录写入上千个文件，并且每秒遍历下HDFS目录。但触发加工是十分钟触发一次，因此该业务产生了大量的rpc操作，严重影响到集群性能，后调优至5分钟遍历次HDFS目录，集群性能得到极大优化。

3）日常生产监控项

由于联通大数据平台承载业务体量很大，通过后台查询繁琐，而通过可视化展示能方便生产运维人员快速了解日生产情况，定位生产延迟原因。

对于平台监控的内容就先介绍到这里，接下来，我们来聊聊如何建立统一采集模板、告警各集群的全量监控指标、进行分组告警并自动化恢复。

三、告警分析、处理及发送功能的经验

1、为什么要选择Prometheus+Alertmanager？

你的监控系统是否曾面临这些痛点：

对于业务量、平台主机量级较大的公司来说，使用以nagios+ganglia为首的传统的监控平台往往会遇到以上情况，显得力不从心。

经过大量、丰富的实战工作后，我们最后选择Prometheus+Alertmanager+钉钉的搭配作为联通大数据监控平台的告警分析、处理及发送工具组合。

这套组合不仅能够针对以上痛点一一解决，也可以说是运维人员保障集群平台稳定运行、故障排查、问题定位的一把利器。

接下来笔者会对系统中的Prometheus、Alertmanager等组件逐一进行介绍。

2、Prometheus-数据存储及分析

1）Prometheus简介

基于上图，大家可以清晰的看到，Prometheus实际上是一个tsdb型数据库，所有的采集数据以metric的形式保存在其中，且能够将数据落到本地磁盘中，供使用人员二次查询数据。

Prometheus同时附加了强大的计算与分析功能，能够利用各种labels与promql语句来完成多维度的监控数据查询，从而为故障排查与问题定位提供可靠的证据。

监控规则方面，Prometheus可以根据promql来获取数据，并且与固定阈值进行计算比较，若超出正常范围，则标记为告警信息，并且可以分组分标签定义告警描述，供后续Alertmanager使用。

在拓展性方面，Prometheus可以轻松的完成服务发现功能，并拥有每秒上万数据点的监控数据收集与分析的处理能力，完全摆脱了传统监控系统对监控主机数量的要求。目前联通大数据平台机器几千余台，监控实例过十万，监控实例指标过千万，Prometheus优良的性能可以做到完美支撑。

2）Prometheus特点

下图中以一个简单例子说明：该条查询可以看到某集群接口机15分钟内的系统负载，涉及到的标签维度为集群、主机IP、主机类型等。

在实际线上环境中，还可以添加多个标签来完成查询，并且可以利用promql特有的查询语句（sum、count_values、topk等）来完成更加丰富的多维度查询，提供可靠、便捷、直观的监控数据供运维人员使用。

Pushgateway是Prometheus环境中的一个data_collector。把它定义为采集者的原因很简单，标准的Prometheus会采用pull模式从target中获取监控数据,但当由于外力原因（如网络、硬件等）无法直接从target中拉取数据时，就要依靠Pushgateway了，请看下图：

大致流程为client上部署的脚本（支持多语言shell、python等）会收集target中的数据，并且以metric形式传送到Pushgateway中，只要保证client和Pushgateway能够正常通信即可。

Prometheus会按照配置时间，定时到Pushgateway上拉取监控数据，从而达到收集target的目的。

下图为Pushgetway发送数据的代码过程：

那么是否可以这么理解：对于常见组件（redis、mysql、nginx、haproxy等），我们可以依靠现有的丰富client库，直接进行监控纳管；对于一些特殊组件或自定义业务，可通过多语言脚本采集监控数据或业务埋点方式，把Pushgateway作为一个data_collector来收集各方数据，从而完成监控纳管。

由于近年Prometheus的兴起，开源社区中越来越多的人将自己的代码贡献出来，使得Prometheus拥有庞大的client库（redis、mysql、nginx、haproxy等），运维人员可以利用这些client实现即开即用即监控的功能。

3）配置

global:

scrape_interval: 15s

evaluation_interval: 15s

# scrape_timeout is set to the global default (10s).

# Alertmanager configuration

alerting:

alertmanagers:

- static_configs:

- targets: ['IP:9093']

rule_files:

# - "first_rules.yml"

# - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:

- job_name: 'prometheus'

scrape_interval: 15s

static_configs:

- targets: ['localdns:9090']

3、Alertmanager-告警的分类搬运工

1）Alertmanager简介

Alertmanager在监控系统中的定位是接收Prometheus发送来的告警，并逐一按照配置中route进行分类，并且通过silencing、inhibition的规则计算，最终得到有效告警信息，通过邮件、钉钉、微信等方式发送给各类业务人群。

2）Alertmanager特点

可以用一个业务场景来解释该特点：某大数据集群由于网络问题大面积瘫痪，上百个datanode触发断开告警，如果按照传统监控模式的话，收到的将是上百条的告警短信形成短信轰炸。

但如果使用分组特性，Alertmanager会将具有共同属性的告警归为一条发送到接收端，清晰明了。

还是用业务场景来解释该特点：某主机上运行了一个MySQL实例，若该主机宕机，则会收到多条关于MySQL各项监控的告警信息，但如果配置了抑制用法，只要触发该主机的宕机告警，上面MySQL所触发的告警便会被抑制掉。

举例来说，某主机硬件主板损坏，但厂商反馈要2天后才能更换主板，一般情况下在更换主板前，该警报会一直大量重复发送。如果此时利用沉默功能，在页面上配置沉默选项即可暂停此告警，待修复完成后取消沉默规则即可。

3）配置

global:

resolve_timeout: 5m

templates:

- 'template/*.tmpl'

route:

group_by: ['cluster']

group_wait: 10s

group_interval: 20s

repeat_interval: 30m

receiver: 'host'

routes:

###############example####################

- receiver: 'example'

match:

cluster: example

continue: true

- name: 'example'

webhook_configs:

- url: ':8180/dingtalk/ops_dingding/send'

inhibit_rules:

- source_match:

- source_match_re:

target_match_re:

equal: ['ipAddress']

4、钉钉-最终告警接收查阅

运维人员常用的发送告警工具有短信、邮件、企业微信和钉钉，之所以选择钉钉的原因如下：

使用钉钉作为告警接收工具，简单来说就是在钉钉群聊中配置机器人，每个机器人会有一条唯一的webhook，当接收到来自Alertmanager的告警后就可以发送到手机端。本文不再详述钉钉机器人的配置，感兴趣的同学可以自行到网上查阅资料。

5、补充知识点

作为运维人员，做得最多的工作就是日常巡检、故障恢复。公司集群规模越庞大，故障发生率和故障实例数也会成倍增加，相信每个运维人都体会过节假日被临时召唤修复故障的经历。

这里，笔者额外贡献一条“自动化恢复”小贴士，解放随时等待召唤的运维er，你值得拥有：

自动化简易流程：通过采集分析Prometheus里的告警数据，利用Fabric或Ansible等多线程安全并发远程连接工具，执行相关角色实例的恢复工作。

Fabric建立连接执行恢复命令。

目前自动化恢复涉及的集群日常运维操作有：

需要提示的是，自动化恢复的适用场景很多，但并不适用于罕见故障且该故障有一定概率会影响到平台部分功能性能的情况，建议大家使用前严谨权衡、对症下药。