基於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)。若是將來單機沒法支撐的狀況下，能夠擴容成聯邦集羣模式。