基于Prometheus+Grafana打造企业级Flink监控系统

基于Prometheus+Grafana打造企业级Flink监控系统

大数据技术与架构 大数据技术与架构

在进入本文以前，我先问你们一个问题，大家公司或者业务系统上是如何对生产集群上的数据同步任务、实时计算任务或者是调度任务自己的执行状况和日志进行监控的呢？可能你会回答是自研或者ELK系统或者Zabbix系统。
今天咱们要介绍的主角可能会吊打上面的监控系统哦。
随着容器技术的发展，Kubernetes 已然成为你们追捧的容器集群管理系统。Prometheus 做为生态圈 Cloud Native Computing Foundation（简称：CNCF）中的重要一员，其活跃度仅次于 Kubernetes，现已普遍用于 Kubernetes 集群的监控系统中。
在 Flink 任务的监控上，本文将简要介绍 Prometheus 体系中的组件如何使用，实例演示 Prometheus 的安装，配置及使用。并最终造成一套 Flink 任务监控的解决方案。

Prometheus前因后果

Prometheus 是由前 Google 工程师从 2012 年开始在 Soundcloud 以开源软件的形式进行研发的系统监控和告警工具包，自此之后，许多公司和组织都采用了 Prometheus 做为监控告警工具。Prometheus 的开发者和用户社区很是活跃，它如今是一个独立的开源项目，能够独立于任何公司进行维护。为了证实这一点，Prometheus 于 2016 年 5 月加入 CNCF 基金会，成为继 Kubernetes 以后的第二个 CNCF 托管项目。
最初，Prometheus 被用在微服务系统的监控上，微服务的落地一直都是业界重点关注的问题，其中除了部署难外，最大的问题就是集群监控、系统配置和系统治理等方面的带来的挑战。
2019 年 Flink 横空出世后，随之而来的运维、监控成为你们关注的重点。做为新一代的监控框架，就像网易在实践过程提出的同样，Prometheus 具备如下特色：

• 灵活的数据模型：在Prometheus里，监控数据是由值、时间戳和标签表组成的，其中监控数据的源信息是彻底记录在标签表里的；同时Prometheus支持在监控数据采集阶段对监控数据的标签表进行修改，这使其具有强大的扩展能力；
• 强大的查询能力：Prometheus提供有数据查询语言PromQL。从表现上来看，PromQL提供了大量的数据计算函数，大部分状况下用户均可以直接经过PromQL从Prometheus里查询到须要的聚合数据；
• 健全的生态: Prometheus可以直接对常见操做系统、中间件、数据库、硬件及编程语言进行监控；同时社区提供有Java/Golang/Ruby语言客户端SDK，用户可以快速实现自定义监控项及监控逻辑；
• 良好的性能：在性能方面来看，Prometheus提供了PromBench基准测试，从最新测试结果来看，在硬件资源知足的状况下，Prometheus单实例在每秒采集10w条监控数据的状况下，在数据处理和查询方面依然有着不错的性能表现；
• 更契合的架构：采用推模型的监控系统，客户端须要负责在服务端上进行注册及监控数据推送；而在Prometheus采用的拉模型架构里，具体的数据拉取行为是彻底由服务端来决定的。服务端是能够基于某种服务发现机制来自动发现监控对象，多个服务端之间可以经过集群机制来实现数据分片。推模型想要实现相同的功能，一般须要客户端进行配合，这在微服务架构里是比较困难的；
• 成熟的社区：Prometheus是CNCF组织第二个毕业的开源项目，拥有活跃的社区；成立至今，社区已经发布了一百多个版本，项目在 GitHub 上得到的star数超过了3.8万。
  
  能够这么说，Prometheus 天生为监控而生。

  Prometheus架构和组件

Prometheus 的总体架构以及生态系统组件以下图所示：

Prometheus Server 直接从监控目标中或者间接经过推送网关来拉取监控指标，它在本地存储全部抓取到的样本数据，并对此数据执行一系列规则，以汇总和记录现有数据的新时间序列或生成告警。能够经过 Grafana 或者其余工具来实现监控数据的可视化。
Prometheus 生态圈中包含了多个组件，Prometheus 的主要模块包括：Prometheus server, exporters, Pushgateway, PromQL, Alertmanager 以及图形界面。其中许多组件是可选的：

• Prometheus Server: 用于收集和存储时间序列数据。
• Client Library: 客户端库，为须要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
• Push Gateway: 主要用于短时间的 jobs。因为这类 jobs 存在时间较短，可能在 Prometheus 来 pull 以前就消失了。为此，此次 jobs 能够直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，须要使用 node exporter。
• Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
• Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。
• 一些其余的工具。
  Prometheus 的工做流程以下：
  Prometheus经过配置文件中指定的服务发现方式来肯定要拉取监控指标的目标(Target)。
  接着从要拉取的目标(应用容器和Pushgateway)，发起HTTP请求到特定的端点(Metric Path)，将指标持久化至自己的TSDB中，TSDB最终会把内存中的时间序列压缩落到硬盘。
  Prometheus会按期经过PromQL计算设置好的告警规则，决定是否生成告警到Alertmanager，后者接收到告警后会负责把通知发送到邮件或企业内部群聊中。

  Prometheus的数据模型和核心概念

Prometheus 全部采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB）：属于同一指标名称，同一标签集合的、有时间戳标记的数据流。除了存储的时间序列，Prometheus 还能够根据查询请求产生临时的、衍生的时间序列做为返回结果。
上面这段话是否是听起来十分拗口？咱们用人话来解释一下：
Prometheus 所采集到的数据被定义为【指标】。存储的数据为【时间序列】，所谓时间序列（或称动态数列）是指将同一统计指标的数值按其发生的时间前后顺序排列而成的数列。而存储的数据库为自带的时序数据库TSDB。

指标名称和标签

Prometheus 中每一条时间序列由指标名称（Metrics Name）以及一组标签（键值对）惟一标识。其中指标的名称（metric name）能够反映被监控样本的含义（例如，http_requeststotal — 表示当前系统接收到的 HTTP 请求总量），指标名称只能由 ASCII 字符、数字、下划线以及冒号组成，同时必须匹配正则表达式 [a-zA-Z:][a-zA-Z0-9:]*。
标签的名称只能由 ASCII 字符、数字以及下划线组成并知足正则表达式 [a-zA-Z][a-zA-Z0-9_]*。其中以 _做为前缀的标签，是系统保留的关键字，只能在系统内部使用。标签的值则能够包含任何 Unicode 编码的字符。

样本

在时间序列中的每个点称为一个样本（sample），样本由如下三部分组成：

• 指标（metric）：指标名称和描述当前样本特征的 labelsets；
• 时间戳（timestamp）：一个精确到毫秒的时间戳；
• 样本值（value）：一个 folat64 的浮点型数据表示当前样本的值。

  指标类型

Prometheus 的客户端库中提供了四种核心的指标类型。

• Counter：表明一种样本数据单调递增的指标，即只增不减，一般用来统计如服务的请求数，错误数等。
• Gauge：表明一种样本数据能够任意变化的指标，便可增可减，一般用来统计如服务的CPU使用值，内存占用值等。
• Histogram 和 Summary：用于表示一段时间内的数据采样和点分位图统计结果，一般用来统计请求耗时或响应大小等。
  讲到这里，读者是否是有所顿悟？还记得 Flink 中的指标类型吗？Flink 也提供了四种类型的监控指标，分别是：Counter、Gauge、Histogram、Meter。

  Prometheus的安装

咱们能够在官网下载Prometheus的安装包：https://prometheus.io/download/ 。这里咱们同时安装Prometheus和Grafana，而后进行解压：

tar xvfz prometheus-*.tar.gz
cd prometheus-*

启动：

$ cd prometheus/
// 查看版本
$ ./prometheus --version
// 运行server
$ ./prometheus --config.file=prometheus.yml

访问本地的http://localhost:9090/ 便可以看到Prometheus的graph页面。

安装grafana

rpm -ivh grafana-6.5.2-1.x86_64.rpm

启动：

service grafana-server start

访问http://localhost:3000/ 能够看到grafana 界面。

固然，Prometheus还有不少其余组件服务于不一样的场景，例如pushgateway和nodeexporter。他们各自的做用能够在官网查看。咱们暂时不作介绍。
这里假设咱们要监控每个服务器的状态，这时候咱们就须要node_manager这个组件。
咱们也是直接安装启动：

$ tar xvfz node_exporter-xxx.tar.gz
// 进入解压出的目录
$ cd node_exporter-xxx
// 运行监控采集服务
$ ./node_exporter

将node_exporter添加到Prometheus服务器，咱们请求一下本地的http://localhost:9090/ 能够看到当前机器的一些指标：

总之，若是你要监控不一样的目标，那么就须要安装Prometheus体系中不一样的组件。关于详细的安装过程和配置过程咱们不作过多展开，你们能够网上搜索有很是多的教程。

Prometheus+Grafana+nodeManager+pushgateway打造企业级Flink平台监控系统

咱们先来看一下总体的监控架构：

这里面有几个核心的组件：

• Flink App ：这是咱们须要监控的数据来源
• Pushgateway+nodeManger : 都是Prometheus 生态中的组件，pushGateway服务收集Flink的指标，nodeMnager负责监控运行机器的状态
• Prometheus : 咱们监控系统的主角
• Grafana：可视化展现
  关于这四个组建的安装，咱们不在仔细描述，你们能够参考网上的资源，咱们重点讲述一下配置文件。
  首先，flink.yaml文件的配置：

metrics.reporter.promgateway.class: org.apache.flink.metrics.prometheus.PrometheusPushGatewayReporter
metrics.reporter.promgateway.host: node1
metrics.reporter.promgateway.port: 9091
metrics.reporter.promgateway.jobName: flinkjobs
metrics.reporter.promgateway.randomJobNameSuffix: false
metrics.reporter.promgateway.deleteOnShutdown: true

prometheus.yml中的配置：

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
        labels:
          instance: 'prometheus'
  - job_name: 'linux'
    static_configs:
      - targets: ['localhost:9100']
        labels:
          instance: 'localhost'
  - job_name: 'pushgateway'
    static_configs:
      - targets: ['localhost:9091']
        labels:
          instance: 'pushgateway'

而后咱们把 Flink集群、nodeManager、pushGateway、Prometheus、Grafana分别启动起来。
因为上面一句配置好Flink、 nodeManager、pushGateway，而且在Grafana中已经添加了prometheus 数据源，因此Grafana中会自动获取到 flink job的metrics 。咱们进入 Grafana 首页，点击New dashboard，建立一个新的dashboard。

选中以后，即会出现对应的监控指标

对于 Flink 任务，咱们须要监控的指标包括JobManager 服务器状态、Checkpoint状况、程序运行时长、Taskmanager内存，流量。甚至能够加上operator的进出流量用来定位反压问题。

业界典型应用

事实上Prometheus自从一出世，便受到了关注，咱们用同程艺龙数据库监控系统的实践来看一下生产上是如何使用Prometheus的。
目前同程的总体监控架构设计以下图所示：

其中几个关键的组件以下：

Agent

这是同程用 golang 开发的监控信息采集 agent，负责采集监控指标和实例日志。监控指标包括了该宿主机的相关信息(实例、容器)。

Pushgateway

官方提供的组件，由于 Prometheus 是经过 pull 的方式获取数据的，若是让 Prometheus Server 去每一个节点拉数据，那么监控服务的压力就会很大，咱们是在监控几千个实例的状况下作到 10s 的采集间隔(固然采用联邦集群的模式也能够，可是这样就要须要部署 Prometheus Server。再加上告警相关的东西之后，整个架构会变的比较复杂。)。因此 agent 采起数据推送至 pushgateway，而后由 Prometheus Server 去 pushgateway 上面 pull 数据。这样在 Prometheus Server 在写入性能知足的状况下，单台机器就能够承载整个系统的监控数据。考虑到跨机房采集监控数据的问题，能够在每一个机房都部署 pushgateway 节点，同时还能缓解单个 pushgateway 的压力。

Prometheus Server

Prometheus Server 去 pushgateway 上面拉数据的时间间隔设置为 10s。多个 pushgateway 的状况下，就配置多个组便可。为了确保 Prometheus Server 的高可用，能够再加一个 Prometheus Server 放到异地容灾机房，配置和前面的 Prometheus Server 同样。若是监控须要保留时间长的话，也能够配置一个采集间隔时间较大的 Prometheus Server，好比 5 分钟一次，数据保留 1 年。

Alertmanager

使用 Alertmanager 前，须要先在 Prometheus Server 上面定义好告警规则。支持邮件、微信、webhook 多种类型，告警是经过 webhook 的方式，将触发的告警推送至指定 API，而后经过这个接口的服务进行二次加工。

Grafana

Prometheus 完美支持 Grafana，能够经过 PromQL 语法结合 Grafana，快速实现监控图的展现。为了和运维平台关联，经过 url 传参的方式，实现了运维平台直接打开指定集群和指定实例的监控图。

目前同程基于 Prometheus 的监控系统，承载了整个平台全部实例、宿主机、容器的监控。采集周期 10S，Prometheus 一分钟内每秒平均摄取样本数 9-10W。仅仅使用一台物理机(不包括高可用容灾资源)就能够承载当前的流量，而且还有很大的容量空间(CPU\Memory\Disk)。若是将来单机没法支撑的状况下，能够扩容成联邦集群模式。