1、为什么要做

从谷歌2003年发布的三篇经典论文《The Google File System 》、《MapReduce: Simplified Data Processing onLarge Clusters》、《Bigtable: A Distributed Storage System for Structured Data》开启了大数据的时代，经过20年的蓬勃发展，大数据已经非常普及常用了。
考虑到大数据4V的特性，你很难说只用一个技术方案或者组件就能应对所有的场景和需求。所以大数据技术架构相对来说还是较为复杂的，其中还涉及到了很多分布式、高可用的机制。比如HDFS的namenode，那如果namenode没有做HA的情况下，出现服务异常终止的情况，基本上整个大数据集群就会宕掉，所有的服务基本都不可用了。这种情况是致命的，你的服务将彻底瘫痪并且无法快速恢复。
那为了保证大数据服务的稳定高可用，我们除了要对相关的服务或组件做HA设计，还需要有完善的监控告警方案，来及时发现当前大数据服务中的隐患和故障并进行消除，已确保当前大数据服务的SLA。
接下来我们就来展开讨论，本文是关于大数据监控告警建设的道而非术，我们会介绍从哪些方面去建设监控告警，而如何建设采用哪些技术方案你完全可以结合当前生产实际情况或者现有标准规范去实施。

2、从哪些方面做

在开始之前，我们有必要介绍下大数据的技术架构，这样有助于我们了解大数据的组成架构、这样我们可以更好的切入去做监控的建设。我们从下向上看，我们可以分层如下
1. 数据来源层：此层基本上是数仓的ODS层数据来源，如app/web的埋点日志，MySQL/mongodb中的业务数据，外部文件等等。基本分两类：一类是用户在app/web触发的相关行为日志，一般通过flume/logstash+Kafka的技术方案来收集，另一类就是业务数据了。我们在此层需要关注的就是收集到的行为日志的波动情况，由于业务DB无法直连，所以我们更多的是在数据集成链路和业务数据接入数仓ODS层后做相关的数据质量监控来监测业务数据波动情况。
2. 数据采集层：此层是将业务数据、埋点数据接入数仓的实现，我们当前使用的是FlinkCDC做业务数据实时集成，在此层可能需要关注的就是你的数据集成任务是否正常。
3. 数据存储层：此层基本是将收集到的业务数据、埋点数据放入大数据存储中，考虑到不同的数据存储需求，此层的数据存储可能会比较丰富不仅仅只有HDFS，此层需要关注的就是存储相关服务健康度以及你的存储使用情况。
4. 数据计算层：此层主要就是数据计算了，会有Flink实时处理&离线批处理。此层需要关注的就是你的计算任务执行是否正常、执行是否超时、Flink任务是否异常终止、Flink任务ck是否正常等等。需要结合你的计算任务来梳理需要做哪些监控。
5. 调度引擎层：此层就是对你的计算任务做周期性调度了，同样会有Flink实时处理&离线批处理。此层需要关注的就是你的调度服务健康度，以及任务的调度执行情况了。我们将任务的调度执行情况和数据计算层的监控一起来看，调度本身也是在做数据的计算执行。
6. 数据服务层：数据服务层基本上就是对外提供数据服务能力了，不同公司会有不同的数据服务能力输出方案。可以是grafana等数据可视化平台，也可能是对外API输出，或者是自建的BI平台等等。此层基本上关注你的数据服务能力是否正常，需要结合你的生产实际情况来看。

所以我们将其抽象如下：

大数据基座

大数据基座基本就是集群相关服务了，包括但不限于HDFS、hive、yarn、spark等等，他们组合再一起共同构建起了大数据的地基，我们可以基于此在上层进行数据的存储、计算、分析等等一系列工作。那么按照我们的经验来说，不管你是托管在第三方云厂商还是基于CDH或者HDP建设，其监控需要关注的点基本相同。主要如下
● 主机实例健康度
○ CPU
○ 内存
○ 磁盘使用、磁盘读写
○ 网络
○ ......

● 集群服务健康度
○ hive、hdfs、yarn等服务健康度，服务不可用，进程故障等
○ 各服务堆内存使用情况
○ yarn 任务挂起、yarn资源使用、yarn队列资源不足
○ hive sql执行成功率低
○ 进程重启、主备切换等关键事件
○ ......

集群服务健康度相对来说要做的更多，我们具体到每个单独的组件可能都会有不同类型的监控，如hive的hms，hiveserver2，hive session等等，这里我们不再展开赘述，你可以参照各云厂商大数据集群的监控也可以参照各组件的官方文档。

数据集成

首先可以看下我们的其中一部分的数据集成链路。这样有利于我们理解需要做哪些方面的监控。

行为埋点数据

首先我们结合自己的实际业务情况指定了客户端埋点协议，埋点协议主要从用户信息、设备信息、事件信息、应用信息等几个大方面去定义一个完整的事件内容，这样全公司各APP产品都可以基于我们的埋点协议来去做全链路的上报、存储、统计分析等流程。
那么用户在APP触发点击浏览行为时，就会生成符合埋点协议的事件，然后收集nginx中的日志，通过logstash 向Kafka发送，因为我们的埋点相对来说还是比较大的，一天的增量约500GB，所以我们在这里用Kafka来做缓冲。
埋点日志进入到Kafka后，我们会用Flink来去做实时的ETL，将其写入Kudu数据加速层，做近实时的统计分析。
那么在此处你要考虑的监控就是整个日志收集链路的各个环节，包括但不限于
● logstash服务健康度
● Kafka服务健康度
● 埋点事件上报地址是否正常
● .....
即使你做了上述各环节的监控，也不能百分百保证埋点日志出问题能立刻发现。我们这边就遇到过两次其它类型的问题，其一是客户端埋点上报地址使用的域名被封禁了，其二是客户端埋点上报地址的http证书过期导致埋点无法正常上报。此时你的各个服务是正常的，但是埋点却报不上来了。所以我们还需要持续的对上报的埋点事件总量波动做监控，你可以结合你的实际业务情况，做分钟、小时、天粒度的各事件波动监控。这样就可以在埋点事件量出现大幅波动的情况下，迅速感知到。下图是我们的一个示例：

业务数据

由于大数据侧无法直连业务DB做一些精细化的监控。所以我们只能在数据集成的链路和进入ods层的数据层面做相关的监控告警了。
我们会用FlinkCDC来去做业务数据库的整库变更订阅。所以首先要关注的就是你的FlinkCDC任务的健康度，Flink 任务执行是否正常等。我们在下文中的计算实时部分再详细提及。
除此之外，在FlinkCDC将业务数据写入Kudu后，我们还会持续的关注业务数据最新的数据产生时间，这样在业务数据超过指定时间仍未有更新时及时发现。介入确认处理流程。
当然你也可以在你的FlinkCDC 任务中实现这个功能，具体的实现还是结合你的实际业务情况和规范来实施。
除了基于整库的全局监控外，在业务数据进入数仓的ODS层后，我们还会结合数据质量监控来做具体的业务表的数据监控，比如单表数据掉0或者单表数据波动异常的情况，这部分将在数据质量环节介绍，此处就不再赘述。

存储

HDFS

如果你使用的是HDFS，那么从存储层面，我们需要监控关注的点如下：
● DataNode磁盘故障：可能会导致已写入的文件丢失。
● 单副本的块数超过阈值：单副本的数据在节点故障时容易丢失，单副本的文件过多会对HDFS文件系统的安全性造成影响。
● 待补齐的块数超过阈值：HDFS可能会进入安全模式，无法提供写服务。丢失的块数据无法恢复。
● 数据目录配置不合理：数据磁盘挂载在根目录或其它关键目录下。对HDFS系统性能产生影响。
● HDFS文件数超过阈值：HDFS文件数过多，磁盘存储不足可能造成数据入库失败。对HDFS系统性能产生影响。
● 丢失的HDFS块数量超过阈值：HDFS存储数据丢失，HDFS可能会进入安全模式，无法提供写服务。丢失的块数据无法恢复。
● DataNode磁盘空间使用率超过阈值，会影响到HDFS的数据写入。
● HDFS磁盘空间使用率超过阈值，HDFS集群磁盘容量不足，会影响到HDFS的数据写入。
● ......

对象存储

那如果你使用的是对象存储，那么恭喜你上述HDFS的相关监控项基本都不需要你去关注了，一切交给对象存储。你可能需要关注如下几点：
● 存储桶的使用情况
● 数据生命周期管理策略
● 安全审计，如AK/SK的保存修改
● ......

计算

计算层面基本上关注的就是具体任务的执行情况了，我们针对实时、离线任务分开就行阐述。

实时

Flink已经成为实时计算领域的事实标准，所以我们这里的实时主要针对Flink，实时任务需要关注的点如下：
● 任务是否异常终止
● 任务重启次数
● Kafka消费是否延迟
● ck是否正常、耗时情况、失败数
● 是否有反压、倾斜
● job本身的资源使用情况
● sink端的执行时间是否超时
● 自定义指标打点收集
● ......
下图是我们的Flink任务监控的一个示例：

关于Flink任务的监控，可以结合Flink metrics来去更细粒度的进行制定。

离线

离线任务主要为批处理任务，批处理任务相对简单，无非成功或失败或者超时，所以我们主要关注如下几点：
● 任务异常终止
● 任务执行超时
● 任务平均执行时间(超时优化)
● 长尾任务
● 占用资源过多任务
● ......

调度

调度服务相对来说简单，在保证HA的前提上，关注你的调度服务是否异常即可。如dolphinscheduler，我们要关注
● master节点状态
● worker节点状态
● 节点相关负载

数据服务

数据服务是对外提供的数据能力，这也是大数据直接展现价值的载体。所以数据服务相关的监控需要格外重视。我们需要关注如下：
● 数据服务是否正常，如grafana能否正常访问，API服务是否能够正常调用
● 提供的数据是否准确，数据是否缺失等（我们将在数据质量环节详细阐述）
● 服务响应时间，如页面加载时间、API调用时间
● ......

数据质量

数据质量监控会相对复杂，但是它是必须要做的，错误的数据将会直接影响业务的相关决策判断。
根据DAMA制定的数据标准管理办法，我们需要从如下角度进行数据质量监控
1. 完整性：数据完整性问题包括：模型设计不完整，例如：唯一性约束不完整、参照不完整；数据条目不完整，例如：数据记录丢失或不可用；数据属性不完整，例如：数据属性空值。
2. 准确性：准确性也叫可靠性，是用于分析和识别哪些是不准确的或无效的数据，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策。
3. 时效性：时效性用来衡量能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。
4. 唯一性：用于识别和度量重复数据、冗余数据。重复数据是导致业务无法协同、流程无法追溯的重要因素，也是数据治理需要解决的最基本的数据问题。例如：业务主键id重复。
5. 数据一致性：多源数据的数据模型不一致，例如：命名不一致、数据结构不一致、约束规则不一致。数据实体不一致，例如：数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致……。相同的数据有多个副本的情况下的数据不一致、数据内容冲突的问题。

在此基础上，我们需要对各种类型进行细粒度的划分。

3、总结和经验

使用邮件组或者订阅的方式进行告警通知，以免人员变动情况下相关的告警通知对象变更。
重要告警集成睿象云，进行短信和电话告警，以免非工作日时间告警接受处理延迟。
监控不需要追求大而全，而是按照更要程度及SLA进行建设。
可能受影响的相关方必须订阅相关监控告警通知，以免A方以为此告警不重要，但是对B方很重要，甚至会影响业务。
监控、告警、处理要有完整的流程闭环及知识沉淀，形成监控告警处理知识库。

4、参考文档

https://www.infoq.cn/article/XudrcZEUFhPJR7kfYNur
https://juejin.cn/post/6967234979847733279
https://support.huaweicloud.com/intl/zh-cn/usermanual-mrs/alm_13000.html
https://zhuanlan.zhihu.com/p/208935690

作者介绍

冯成杨资深大数据开发工程师

菜单

大数据监控建设之道