基于Prometheus&Grafana构建大数据一站式运维监控方案

一、背景

对于大数据方向而言，开发与运维这两种方向往往是紧密结合的，没有明确的岗位界限，大多数中小型企业的大数据开发和运维工作往往就是一个小团队完成。
由于数据类业务的特性不同于传统应用开发，数据运维阶段的工作量往往比开发阶段工作量更大，如果运维工作没有妥善处理，层出不穷的问题会让整个团队疲于奔命。

二、痛点

根据实际情况，我们将大数据运维工作分为两大类：一个是业务运维，比如一个Flink流程序，一个批处理脚本调度等；还有一类就是组件运维，比如hdfs、yarn、hbase等。

业务类痛点：

采集程序、流程序等进程类程序可能遭遇异常挂掉；

批处理脚本调度可能发生调度失败情况；

数据可能发生延迟、丢失、不合常理的体量波动等问题。

组件类痛点：

hadoop主体通过ambari+hdp的方式搭建，es、kibana、调度平台、etl工具等组件都是独立搭建，组件数量多且分布很散，运维检查工作量庞大；

大部分大数据组件都具备高可靠容灾设计，偶尔挂一两个节点对于全局来说不受影响，因此很难及时发现问题，等发现问题时，已经是大问题了；

基于以上痛点，我们很有必要构建一个一站式能够全方面运维监控的平台，以便及时发现和最小代价解决问题。

三、选型

选型出发点：

是否开源：监控类程序所需要的权限往往比较大，开源产品相对透明

成熟度：目的是运维求稳，运维工具本身的成熟度很重要

拓展性：大数据组件非常广泛、业务的自定义监控也需要友好的拓展性

性能：越高越好

容器支持：大数据往往不是独立个体存在，在应用容器化时代，很有必要和应用共享一套监控方案

社区活跃度：活跃度越高，证明软件价值越大

企业使用量：使用的用户越多，相关资料和问题越容易找到解决方案

部署难度：越简单越好，尽可能降低上手成本

主流监控对比：

查阅了大量资料和测评分享，最终总结Zabbix、Open-Falcon、Prometheus三款监控软件的对比：

选型结论：

在各个指标维度和实际业务情况的综合考虑下，Prometheus更符合我们实际使用需求。最终选定了Prometheus+Grafana的监控方案。

补充说明：Grafana是一个可视化展示工具，通常与Prometheus等监控软件搭配使用。

四、方案设计

总体设计：

①Prometheus各类指标采集器将相应指标进行采集，由PrometheusServer进行汇集，最后由Grafana进行展示；

②对于MySQL中报表等业务数据或者数仓统计结果，直接由Grafana读取MySQL进行监控展示。

细节处理：

①系统监控、组件监控等Prometheus社区已有的开源监控采集器都有配套的Grafana展示模板，但是指标过于丰富，全部看懂需要非常深厚的技术功底，在常规运维巡检时也不需要检查全部指标。因此需要额外自定义构建一套常规运维巡检关键指标看板，在日常运维时只需要查看关键指标即可，等有必要时再去分析全量指标；

②自定义业务监控开发时，需要考虑采集频率、性能、对业务本身影响程度，不能本末倒置；

③数据量、数据质量等低频监控事件可借助ETL调度平台汇聚到MySQL中，直接使用Grafana进行展示，没必要为了使用Prometheus而强行再进行开发采集器。