大数据平台监控体系建设

背景

云筑大数据平台在建设过程中，前期为了快速上线基础组件服务业务，在整个集群的监控力度上采用散点式的监控；不同的组件监控采用不同的监控手段。监控数据的采集方式、完整度、监控指标体系等方面不健全，没有统一监控看板入口。随着接入的业务越来越多，为了更好的在平台上稳定的支撑业务，事前掌握集群现状，事中快速解决问题，事后快速弥补缺陷，保障平台的稳定性做好SRE；需要从上而下的建设大数据平台监控体系，夯实大数据平台监控能力，掌控大数据平台的能力面貌。

1 整体设计

整体技术架构采用数仓建模的方式来构建监控数据数仓，分为实时看板和离线监控项预警推理分析、实时指标告警，实施步骤如下

分层指标的梳理
数据采集
可视化展示
报警、预警

2 分层指标梳理

整个指标体系从下到上可以分为以下几层

底层物理主机层

大数据组件监控

业务服务监控

业务数据监控

2.1 底层物理主机层

大数据基础Hdfs集群机器、ES集群机器、Clickhouse集群机器、Api服务主机

监控项目	监控指标	等级
内存	内存容量	p0
内存	内存剩余容量	p0
内存	高峰内存使用时间段	p1
CPU	CPU利用率	p0
CPU	CPU高峰使用时间段	p0
IO	IO速率	p0
IO	打开文件句柄数量	p0
磁盘	磁盘总容量	p1
磁盘	磁盘剩余容量	p0

2.2 大数据基础组件层

整个大数据平台基于开源的HDP，结合云筑网自身的数据特点外加选择大数据其他开源组件搭建。整体组件种类多。包含数据采集、存储、计算、应用、调度、安全管理等多层面。

HDFS

监控组件	监控项目	监控指标	等级
hdfs总览	容量	集群总容量	p1
hdfs总览	容量	集群剩余容量	p0
hdfs总览	容量	集群每日数据增量	p0
hdfs总览	文件数	集群总文件数	p1
hdfs总览	文件数	集群小文件数	p0
hdfs总览	文件数	集群每日新增文件数	p1
namenode	内存	总内存	p1
namenode	内存	剩余内存	p0
namenode	内存	每日新增使用内存	p0
namenode	内存	Full Gc次数	p0
nameenode	NN	active切换次数	p0
namenode	线程	总的线程数量	p0
namenode	文件操作	连接数	p0
namenode	文件操作	每秒新建请求数量	p0
namenode	文件操作	每秒删除文件请求	p0
namenode	文件操作	美妙读取文件请求	p0
datanode	容量	当前节点容量	p0
datanode	容量	当前节点每日新增容量	p1
datanode	数据读写	写入速率	p0
datanode	数据读写	读取速率	p0
journalnode	editlog同步	同步延迟	p0
journalnode	节点数量	当前node数量	p0

Yarn

监控组件	监控项目	监控指标	等级
yarn总览	任务	正在运行任务数量	p1
yarn总览	任务	失败任务数量	p0
yarn总览	任务	正在运行的流任务数量	p0
yarn总览	任务	长离线任务数量（运行时长超过30分钟）	p0
yarn总览	任务	当前等待任务数量	p0
yarn总览	容量	集群当前内存	p0
yarn总览	容量	集群当前算力	p0
yarn总览	节点	nodemanager节点个数	p0
yarn总览	用户	用户总数	p1
resoucemanger	内存	内存总数	p1
resoucemanger	内存	剩余内存数量	p0
resoucemanger	内存	Full Gc次数	p1
resoucemanger	网络请求	当前连接数量	p0
nodemanager	内存	总内存	p1
nodemanager	内存	可用内存	p0
nodemanager	任务	当前的容器数量	p0

Zookeeper

监控项目	监控指标	等级
总览	节点状态	p0
总览	节点个数	p0
总览	当前的年代	p0
总览	zk集群数据大小	p0
总览	网络连接数量	p1
总览	znode数量	p1
总览	临时znode数量	p0
总览	打开的文件句柄	p1
总览	follower数量	p0
总览	当前的平均延迟	p0
总览	请求最大延迟	p0
内存	内存总量	p1
内存	内存剩余	p0

Kafka

监控项目	监控指标	等级
集群总览	broker数量	p0
集群总览	broker内存总量	p1
集群总览	broker可用内存	p0
集群总览	总数据量	p1
集群总览	每日新增数据量	p0
集群总览	总的topic数量	p1
集群总览	每日新增topic数量	p0
集群总览	没有leader节点的partition数量	p0
集群总览	总的副本数量	p1
集群总览	总的消费者个数	p0
内存	单个broker可以内存	p1
内存	页缓存读取率	p0
流量	topic流量	p0
流量	消费组消费堆积数量	p0
CPU	单个broker的cpu利用率	p0
IO	单个broker的io次数	p0

Clickhouse

监控项目	监控指标	等级
容量	集群总数据量	p1
容量	集群总的内存使用	p0
容量	集群总的block数量	p1
连接数	tcp连接数	p2
连接数	http连接数量	p2
任务	当前正在运行sql数量	p0
任务	等待执行的sql任务数量	p0
任务	后台merge任务数量	p0
任务	慢查询任务数量	p0
任务	大任务数量(内存使用过高)	p0
管理	alter操作	p0
内存	单实例内存利用率	p0
cpu	单实例cpu利用率	p0

Hive

监控组件	监控项目	监控指标	等级
hiveserver2	内存	jvm总内存	p1
hiveserver2	内存	剩余可用内存	p0
hiveserver2	内存	full Gc次数	p0
hiveserver2	网络请求	QPS	p1
hiveserver2	实例状态	当前实例是否存活	p0
hiveserver2	线程	总线程数量	p1
metastore	实例状态	当前实例是否存活	p0
metastore	内存	jvm总内存	p1
metastore	内存	jvm剩余可用内存	p0
metastore	内存	full Gc次数	p0
metastore	线程	总线程数量	p1

Trino

监控组件	监控项目	监控指标	等级
集群总览	节点状态	可用的worker节点数量	p0
集群总览	任务	当前正在运行的任务数量	p1
集群总览	任务	慢查询数量	p0
集群总览	任务	大查询(内存使用大)	p0
集群总览	任务	失败的任务数量	p0
集群总览	任务	当前排队的任务数量	p0
coordinator	内存	jvm总内存	p1
coordinator	内存	jvm剩余内存数量	p0
coordinator	内存	full Gc次数	p0
coordinator	线程	当前运行的线程总数	p1
coordinator	cpu	cpu利用率	p1
coordinator	网络连接	当前连接数量	p0
worker	内存	总可用内存	p1
worker	线程	当先运行线程总数	p1

2.3 业务服务层

监控服务	监控指标	等级
edata自主数据套索服务	进程是否存在	p0
edata自主数据套索服务	QPS	p1
edata自主数据套索服务	内存使用量	p1
edata自主数据套索服务	用户数量	p0
主数据服务	进程是否存在	p0
主数据服务	QPS	p1
主数据服务	jvm内存情况	p0
通用计算服务	进程存在	p0
通用计算服务	QPS	p1
通用计算服务	任务数量	p1
通用计算服务	慢查询任务	p0
AI推理服务	QPS	p0
AI推理服务	triton节点数量	p0

2.4 业务数据层

监控组件	监控指标	等级
hive	hive库表数量	p1
hive	hive每日新增表数量	p0
hive	hive表数据量环比	p0
hive	ads层数据表数据量	p0
hive	库表alter操作	p0
hive	各业务线数据量	p1
clickhouse	clickhouse库表数量	p1
clickhouse	clickhosue和hive表数据量是一致性	p0
clickhouse	alter操作次数	p0
Es	Es index数量	p0
Es	Es字段和hive字段的一致性比较	p0

3 数据采集

3.1 物理主机采集

物理主机的数据采集采用telegraf统一的采集，telefraf是go语言编写的一款开源数据工具，主要用于收集基于时间序列的数据，例如服务器CPU指标、内存指标、各种iot设备的数据。因此在收集监控物理主机层面的数据使用telegraf是一个比较不错的选择。telefraf官方网站(https://archive.docs.influxdata.com/telegraf/v1.7/introduction/getting-started/)

插件类型	插件作用
Inputs插件	数据输入插件、用户采集目标数据
Process插件	对采集到的数据进行简单的处理。比如给数据增加Tag标签等
Aggregate插件	聚合某个时间段的数据.比如比如取最大值、最小值、平均值等操作
Outputs插件	将采集和处理的数据输出到目标系统

3.2 大数据套件的数据采集

整个大数据套件的数据采集主要是prometheus采集jmx的数据项。prometheus是SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。主要用于各种服务系统的监控。在各大公司都有广泛的使用。

prometheus核心组件的介绍

组件名称	作用
Prometheus Server	主要负责数据采集和存储，提供PromQL查询语言的支持
客户端SDK	支持各种语言和Prometheus Server交互
Push Gateway	支持临时性Job主动推送指标的中间网关
Exporter	Exporter是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为Prometheus支持的格式。与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取

以监控Hadoop为例子，使用prometheus收集hdfs集群的数据

3.3 业务服务层数据采集

数据服务数据采集采用spring boot整合prometheus。需要在相应的工程服务中添加如下依赖

在配置项目配置文件中增加prometheus相应配置

3.4 业务数据层的采集

云筑大数据平台业务层面数据主要包括hive离线数仓和clickhosue、ES中的数据、调度系统中的调度元数据

对于hive中的业务数据，采用编写python脚本的方式从metastore底层的mysql元数据库中将数据同步到hive中，进行数据聚合加工。防止在mysql中进行聚合影响,metastore服务的稳定行.hive metastore中mysql 库元数据如下

类型	相关表
hive 数据库相关	DBS，DATABASES_PARAMS
hive 表和视图相关	TBLS,TABLE_PARAMS,TBL_PRVS
hive文件存储相关	SDS,SD_PARAMS,SERDES,SEREDS_PARAMS
hive表字段相关	COLUMNS_V2,TBLS,TAB_COL_STATS
hive分区相关	PARTITIONS,PARTITIONS_KEYS,PARTITIONS_KEY_ALS,PARITIONS_PARMS
hive UDF相关	FUNCS,FUNC_RU

对于clickhouse的元数据采集, clickhouse将数据存储信息元数据存放在system库里面。直接clickhouse的需要的数据同步到hive的数据仓库里面。clickhouse系统表详情参见官网介绍（https://clickhouse.com/docs/en/operations/system-tables）。

以system.parts为统计ck的表总行数、大小、压缩率等

ES业务数据采集

ES自带了元数据采集的接口、需要自定义python的脚本将ES的元数据按天同步到Hive的相应的数据库中。按需统计相关指标。Es常见统计接口如下

url地址	说明
/_cat/allocation	查看单节点的shard分配整体情况
/_cat/shards	查看各shard的详细情况
/_cat/shards/{index}	查看指定分片的详细情况
/_cat/nodes	查看所有节点信息
/_cat/indices	查看集群中所有index的详细信息
/_cat/count	查看当前集群的doc数量
/_cat/count/{index}	查看指定索引的doc数量
/_cat/fielddata	查看当前集群各个节点的fielddata内存使用情况

4 监控数据可视化

所有组件层面Metrics数据收集之后, 需要有一个地方集中监控维度的看板，在研究行业的通用的技术方案中，grafana是一个比较理想的选择。grafana本身自带了丰富的图表功能，能够连接不同的数据源。比如prometheus、es等。QA环境效果图如下

对于业务层面数据，我们收集在hive中之后，采用公司自研的edata自主报表平台，展示业务数据层面的数据，形成固定通用的业务数据周报，发给上层的领导。局部效果如下

5 监控告警

主动告警功能是平台稳定性里面至关主要的一环。监控看板的数据是静态的，用户常规的日常巡检很有帮助、平台服务的7*24小时的运行态的告警，可以帮助我们实时的掌控平台的运行情况。关于告警可以分为一下几部分

5.1 告警等级划分

监控告警分级也是至关重要的，当监控的东西越来越多的时候，就得给这些家伙进行分级管理了。有些监控告警是 P0 级，它很重要，一旦出现就需要引起我们的高度重视，快速响应，一般我们要求是触发电话通知，并通知到对应的值班人、负责人等。而有些监控项它更多的是偏提示或者预警，那么就要做好分类管理。在我们内部梳理部分的监控等级(表各为部分样例)

等级	报警项	通知方式
p0	可用内存不足	电话+钉钉
p0	节点down机器	电话+钉钉
p1	yarn任务失败	钉钉

5.2 告警收敛

前期在做告警时候，大数据团队开发人员自己编写脚本，做了一些监控告警。在钉钉群里发告警信息。刚开始的时候，群里消息还是时刻关注。后面发现群里的消息有一些info级别的、有一些不是很重要的。导致重要的监控信息容易被忽略。监控收敛这一块，目前我们还在经一步的探索。尽量是在发现问题的时候，一些故障可以通过程序自动修复，无需通知监控人员。

5.3 告警实现

目前平台的告警主要分成了三大块

第一块是主机层面的告警,采用的是zabbix自带的告警功能，通过配置相应的trigger进行告警处理
第二块为prometheus监控大数据组件和大数据对服务，利用prometheus的alter manager的功能实现报警
第三块为业务数据层监控告警，由开发人员执行编写python脚本进行数据对比达到报警的目的

上述的处理方式就是能够快速实现V1版本的告警管理，但是不难发现，告警方式多样、告警规则没有统一管理。比较理想的方式是，把所有的数据收集，通过一些transform操作统一消息格式。推送到kafka。然后由flink加载报警规则。进行统一的告警。这个方案我们内部正在逐步的推进。