前言
大数据平台涉及到的组件非常多，对于集群节点的运行状态，使用性能的监控是非常有必要的。而常规的监控和运维成本非常高，因此需要一套对集群的可靠性，稳定性，健康度做出一系列的评价指标。大数据监控是指通过大数据技术手段获取、收集、分析数据，并能够准确分析信息，有效预测信息发展动态趋势。大数据监控主要围绕着海量全网数据，大多数需要借助监测系统来协助分析数据。
大数据监控体系
其实上面每个维度，都包含了很多的监控项与监控指标，而针对不同的告警维度，它的监控方式也不尽相同，但总体来说，对于大数据监控，分为资源监控和性能监控2方面。
- 一些监控是不断读取它的状态，比如常见的 CPU 、内存，然后设定阈值触发告警动作。
- 一些监控是需要有时序性的聚合统计，比如 HDFS 存储增量，当增量斜率比平时高的时候触发告警动作。
- 一些监控是需要和其他监控做与操作，或者联动，同时满足才会触发告警动作。
针对这些不同的监控指标，单纯的一个监控组件 或者 数据采集方式是不能满足的。光靠开源的监控手段也无法全部覆盖，所以我们做了各式组件 + 自研的监控脚本与程序去实现整体的监控框架。
整个7 个维度，我们按照不同的框架与组件实现，主要分为两个实现
大数据任务相关常见指标
大数据运维监控
通用大数据台性能监控组件：Grafana + Prometheus + Alertmanager等。
底层基础监控
这部分比较简单，就是基于 Zabbix + 云监控 对所有的 网络、服务器 进行实时监控数据收集。
因为我们同时负责了不同的事业部 与 部门的运维工作，所以进行了 分组、分模版、分告警渠道 的形式，实现对不同部门的告警。但同时为了避免重复维护，我们尽量复用告警模版。
比如培优大数据、数据中台业务侧的 很多业务类型的告警都是类似的，所有的项目模块都需要对 Java 进程，Nginx 进程进行监控，那我们就划分两个 分组，同时和 一个 Java 进程告警模版相关联。而不是创建两个：
如上，业务模块 对应的 主机群组，不同的主机群组可以 复用 相同的告警模版。 比如不管是培优还是网校、不管是业务还是集群、底层服务器的 CPU、内存等基础监控都得有。 所以就可以复用同一个告警模版。
PS：有时候会遇到 相同告警模版，相同监控项，但是监控阈值不同。 比如 虽然业务服务器 和 大数据集群服务器 都需要监控 CPU ，但是业务服务器只要超过 65% ，我们就认为是异常，但是大数据服务器在高峰期可能长时间处于 90% 左右的 CPU 利用率，那么它的阈值要更高，并且持续时长也要更高些。
对于 Zabbix 我们只是力求把它用好，尽可能通过 划分组、复用模版 的方式让它更清晰、整洁、高效。
Zabbix是近年来兴起的监控系统，易于入门，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发，难度较大；此外，系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多；并且自定义的项目报警需要自己设置，过程比较繁琐。
集群性能监控
对 大数据 组件的性能监控，我们借助 Prometheus + AlertManager + Grafana 的架构方式。主要分为四个简要步骤：
- 自建 Flask exporter ，从 Cloudera Manager 的 API 中取出各式组件需要监控的 Metrics 。
- 通过 Alertmanager 对需要的 metrics 进行告警。
- 自建告警系统 + 电话告警 API 供 Alertmanager 调用。
- 将 Prometheus data source 接入 Grafana 做报表展示。
Prometheus
Prometheus注重于数据存储及分析，存储采集到的监控数据并以metric的形式保存在其中，且能够将数据落到本地磁盘中，供使用人员二次查询数据。
Prometheus同时附加了强大的计算与分析功能，能够利用各种labels与promql语句来完成多维度的监控数据查询，从而为故障排查与问题定位提供可靠的证据。
监控规则方面，Prometheus可以根据promql来获取数据，并且与固定阈值进行计算比较，若超出正常范围，则标记为告警信息，并且可以分组分标签定义告警描述，供后续Alertmanager使用。
在拓展性方面，Prometheus可以轻松的完成服务发现功能，并拥有每秒上万数据点的监控数据收集与分析的处理能力，完全摆脱了传统监控系统对监控主机数量的要求。目前联通大数据平台机器几千余台，监控实例过十万，监控实例指标过千万，Prometheus优良的性能可以做到完美支撑。
Prometheus特点
① 监控数据存储功能及多维度查询
② 优秀的自定义及第三方监控拓展功能
③ 良好的监控生态圈之常见client库
Alertmanager
Alertmanager的主要作用是对告警进行分类并发送到客户端。Alertmanager在监控系统中的定位是接收Prometheus发送来的告警，并逐一按照配置中route进行分类，并且通过silencing、inhibition的规则计算，最终得到有效告警信息，通过邮件、钉钉、微信等方式发送给各类业务人群。
Alertmanager特点
① 分组
使用分组特性，Alertmanager会将具有共同属性的告警归为一条发送到接收端，清晰明了。
② 抑制
某主机上运行了一个mysql实例，若该主机宕机，则会收到多条关于mysql各项监控的告警信息，但如果配置了抑制用法，只要触发该主机的宕机告警，上面mysql所触发的告警便会被抑制掉，即高级警报将会抑制低级警报。
③ 沉默
比如，某主机硬件主板损坏，但厂商反馈要2天后才能更换主板，一般情况下在更换主板前，该警报会一直大量重复发送。如果此时利用沉默功能，在页面上配置沉默选项即可暂停此告警，待修复完成后取消沉默规则即可
Grafana
Grafana是大数据平台性能监控图形化展示功能的核心组件，也是近年来比较受欢迎的一款监控配置展示工具，其优点在于能对接各种主流数据库，并且能在官网及社区上下载精致的模板，通过导入json模板做到快速的展示数据。
主机监控项
主机监控项：主机监控项概览:内核、内存、负载、磁盘io、网络、磁盘存储、inode占用、进程数、线程数。
主机资源占用：主要从cpu占用、内存占用、负载、线程数多个维度统计同一主机群体。
主机用途分类：
主机资源占用top10：主要从cpu占用、内存占用、负载、线程数多个维度统计同一主机群体（如：A机房接口机是一个主机群体，B机房计算节点是一个主机群体）占用资源最多的前十台机器。
进程资源占用top10：通过主机监控大屏和主机资源占用top10定位故障主机的故障时间段和异常指标，只能初步的帮助运维人员排查机器故障的原因。例如，当机器负载过高时，在主机监控大屏中往往能看出主机的cpu使用，读写io、网络io会发生急速增长，却不能定位是哪个进程导致。当重启故障主机之后，又无法排查历史故障原因。因此对于主机层面监控，增加了进程资源占用top10，能获取占用cpu，内存最高的进程信息(进程开始运行时间、已运行时长、进程pid、cpu使用率、内存使用率等有用信息)。这样，当主机因为跑了未经测试的程序，或者因运行程序过多，或程序线程并发数过多时，就能有效的通过历史数据定位机器故障原因。
平台项监控
平台监控项种类繁多，有hdfs、yarn、zookeeper、kafka、storm、spark、hbase等平台服务。每个服务下有多种角色类别，如hdfs服务中包括Namenode、Datenode、Failover Controller、JournalNode 。每个角色类别下又有多个实例。如此产生的监控指标实例达几十万个。目前联通大数据使用的CDH版本大数据平台，基础监控指标全面多样。根据现状，平台层面我们主要配置比较关键的一些监控项。
集群yarn队列资源占用多维画像
zeeplin操作日志
hdfs各目录文件数及存储多维画像
集群namenode RPC 实时多维画像
生产报表相关监控
告警收敛与告警分级
一条告警的流程：
其实告警收敛的核心目的是提升告警有效性，确保问题能在第一时间得到妥善处理。
目前我们的告警收敛做的比较糙，主要分为三部分：
- Zabbix 部分就单纯的根据进一步细分 主机群组 和 监控模版，比如 Datanode 独立一个基础监控，将阈值调高，不至于频繁告警。
- Prometheus 本身是支持 告警分组 与 告警收敛的，就 基于 Prometheus 的告警分组特性进行了一些常态化的告警收敛。
- 自建升级监控 目前 是根据一些简单计算公式进行收敛策略，我一直觉得这块其实大有可为，后面我们逐步要做 DataOps 和 AiOPS 的时候可以基于Flink 等通过大量的实时算法策略做告警收敛。
这里也附上我对告警收敛的一点思考。 首先，它是一个细活，当到一定规模和体量的时候，必然要深入算法，去建模，对监控流量进行分析。从而达到 类似 AIOPS 的效果，进行故障自愈和智能巡检等效果。而想要做到这一步还是要有比较专业的团队去聚焦，做监控平台。 而监控平台一个很大的挑战将会是，平台如何有通用的产品能力，去适配不同业务场景的监控告警 功能。
告警分级也是至关重要的，当监控的东西越来越多的时候，就得给这些家伙进行分级管理了。 有些监控告警是 P0 级，它很重要，一旦出现就需要引起我们的高度重视，快速响应，一般我们要求是触发电话通知，并通知到对应的值班人、负责人等。 而有些监控项它更多的是偏提示或者预警，那么就要做好分类管理。
针对线上的一些告警，进行了如下分类分级（内容太多，这里只截取了一小部分）：
如上，根据不同的监控项、监控类型，分别针对线上的监控做了告警分级处理。
我们规定，所有的 P0 级告警，全部走 电话 + 知音楼 通知，所有的 P1 级告警都走 对应的知音楼核心群通知。P2 及以上告警收敛覆盖率要达到 80%。
好的告警分级 能减轻运维人员自己的负担，也能使告警更有效清晰。但如何打造一套完整的告警分级体系，还需要贴合业务场景 并且有监控数据分析，综合去评定。 一旦有了这样的体系，那么后面要做的就是不断补充完善这个体系。出故障的时候也能按图索骥，根据监控告警分级策略不断打磨完善。
