詳解 Flink 指標、監控與告警

整理： 李培殿 & 楊偉海（Flink 社區志願者）

校對：楊偉海（Flink 社區志願者）

 

摘要：本文由美團點評研發工程師孫夢瑤分享，主要介紹 Flink 的指標監控和報警的內容，分爲如下四部分：

1. 監控告警鏈路：基於美團點評實時計算平臺的實踐
   

2. 經常使用的監控項：哪些指標能夠高效地衡量做業
   

3. 指標的聚合方式：橫當作嶺側成峯
   

4. 指標監控的應用：有哪些常見的表達方式供參考
   

Tips：點擊「閱讀原文」連接可查看做者原版 PPT 及分享視頻～

 

爲何咱們關注指標監控

咱們將以天氣舉例。

指標：衡量和描述對象的方式

• 可量化： 好比最近天氣很熱。今天比昨天熱嗎？北京的溫度比上海更熱嗎？你們就沒有辦法評判，因此溫度就是這樣一個指標，來量化咱們天熱的程度。
• 標準化： 咱們習慣說的溫度是攝氏溫度，若是有人跟你講華氏溫度，說今天77度，你就會以爲很奇怪，氣溫怎麼會有這麼高的數值，所以，咱們的指標還須要是標準化的，須要有一個統一的標準。
• 多維度： 南方的同窗以爲35度悶得喘不過氣來；北方的同窗以爲35度好像也就那樣。由於咱們除了氣溫這個指標會影響人體的溫馨度以外，還有一個指標叫空氣溼度。因此衡量天氣須要結合多個維度的指標。

監控：對指標進行監測和控制

• 實時：好比天氣預報，實時的預報纔是咱們須要的監控內容。
• 易用： 相比於電視機裏固定時間播報的天氣信息，手機 App 就是易用的天氣監控軟件。
• 可查詢歷史： 好比前幾天某地一直在下雨，河流湍急，可能影響我出行的選擇。

今天的分享從如下四個方面展開：

• 監控報警的鏈路——基於美團點評實時計算平臺的實踐
• 經常使用的監控報警項——哪些指標能夠高效地衡量個人做業
• 指標的聚合方式——橫當作嶺側成峯
• 指標監控的應用——有哪些常見的表達方式供參考

1. 監控報警的鏈路

1.1 監控報警鏈路

美團點評的指標監控報警的鏈路以下圖所示。 首先是咱們對日誌和指標都會進行統一的集中化的收集。Reporter （2.8和3.1中有介紹）把 Flink 做業的指標做爲一條條日誌打出來。 而後再經過日誌收集收上去，收到 Kafka 裏面。接下來會經過實時做業作解析和聚合，再將獲得的指標落到 Kafka 裏，做爲實時數據源。

下游會根據不一樣的需求，對不一樣的數據作不一樣的處理和展現。日誌數據會落到 ES 裏供查詢使用，同時也會根據關鍵字接實時做業進行處理，作日誌相關報警；數值指標會落到 OpenTSDB 裏供你們查詢，同時也支持各種的指標報警。 最終這些內容仍是會集中到咱們的實時計算平臺裏，給用戶作一個統一的展現。

整個鏈路下來，主要分爲三個關鍵環節。

1. 日誌收集 部分，咱們首先是要把這些日誌和指標進行統一化、集中化的收集。對於這一環，以前兩個講師也講過， Flink 如今提供的方式有三種：一個是在 Flink UI 上能夠直接看到這個做業的一些指標；第二種 REST API 從做業上獲取指標；第三種就是配各類第三方的 Reporter 。美團這邊是在 slf4j 的基礎上增長本身的維度信息格式化後往下發。
2. 解析展現 部分，使用一些 Flink 做業去解析聚合平臺全部做業的指標數據，展現給用戶，也提供給下游使用。
3. 監控和報警 部分，對於聚合完成了的指標，作一些個性化的可配置的規則報警。

1.2 指標展現：Grafana

Grafana 支持比較多的數據源格式，好比 ES、OpenTSDB 等；它有個變量的功能，能夠看某個做業的指標，也能夠一塊兒對比看。

相比於自研的指標展現工具，Grafana 配置界面會比較方便，省時省力，性價比高。若是是隻是想簡單的展現一下全部的做業的指標的話，Grafana 是個很好的選擇，它也能夠被外嵌在其餘的頁面上。可是 Grafana 圖的類型比較單一，在實際的直接使用過程當中可能還會有一些侷限性。

2. 經常使用的監控項

下面咱們來關注下通常會使用哪些指標來衡量做業運行的情況。

2.1 經常使用的指標

■ 系統指標

系統指標在 Flink 官網有相應的說明。

• 對於系統指標最常關注的是做業的可用性，如 uptime (做業持續運行的時間)、fullRestarts (做業重啓的次數)。

• 第二個關注的是做業的流量，能夠經過 numRecordsIn、numBytesInLocal 等相關指標來關注做業天天處理的消息數目及高峯時間段的流量，經過關注這些指標能夠觀察做業的流量表現是否正常。

• 而後是 CPU（如：CPU.Load）、內存（如：Heap.Used ）、GC ( 如：GarbageCollector.Count、GarbageCollector.Time )及網絡 ( inputQueueLength、outputQueueLength) 相關指標，這些指標通常是用來排查做業的故障信息。

• 另外是 checkpoint 相關信息，例如最近完成的 checkpoint 的時長（ lastCheckpointDuration ）、最近完成的 checkpoint 的大小（ lastCheckpointSize ）、做業失敗後恢復的能力（ lastCheckpointRestoreTimestamp ）、成功和失敗的 checkpoint 數目（ numberOfCompletedCheckpoints、numberOfFailedCheckpoints ）以及在 Exactly once 模式下 barrier 對齊時間（ checkpointAlignmentTime ）。

• 還有就是 connector 的指標，例如經常使用的 Kafka connector ，Kafka 自身提供了一些指標，能夠幫助咱們瞭解到做業最新消費的消息的情況、做業是否有延遲等。
  

■  自定義指標

自定義指標是指用戶能夠在本身的做業邏輯中進行埋點，這樣能夠對本身的業務邏輯進行監控。

正如其餘講師所提到的，如今的 Flink 做業更像是一種微服務，不只關心做業是否把全部數據都處理完了，還但願做業能夠7×24小時不間斷的運行來處理數據。所以在業務邏輯中重要的指標在 Flink 中也會很重要。

• 好比處理邏輯耗時打點，例如包含複雜邏輯的業務系統，能夠經過在邏輯先後進行打點，這樣能夠查看每條消息處理完這個邏輯的耗時。

• 另外一塊是外部服務調用的性能， 在 Flink 做業中可能須要訪問外部存儲（如 Redis ）, 能夠經過打點來查看請求的耗時、請求的成功率等。

• 還有是緩存命中率，有時候因爲數據集過大，咱們只訪問熱數據，此時會在內存中緩存一部分信息，咱們能夠監控緩存命中率，若是緩存命中率很是高說明緩存有效，若是緩存命中率很是低，一直在訪問外部存儲，就須要考慮緩存設計的是否合理。
  

另外還有幾類是關於做業的處理邏輯，若是處理邏輯拋出異常將會致使做業 fullRestarts，此時通常會將這些異常進行 catch 住，若是涉及複雜計算的能夠經過重試機制多試幾回，若是重試後未成功則丟棄數據 。此時能夠將處理數據的佔比或者數據的某些特徵做爲指標上報，這樣能夠觀察此類數據的佔比來觀測數據處理是否存在異常。又如 filter 過濾的數據佔比能夠觀測 filter 的邏輯是否正常，還有窗口等涉及時間的算子須要監測超時丟棄的數據的佔比等。

2.2 如何肯定哪些指標須要關注？

1. 第一點是做業狀態相關的， 如做業是否出故障、做業是否存活、做業是否穩定運行、影響做業可用性的風險因素（如上次 checkpoint 是否成功、最近成功的 checkpoint 的時間）。

2. 第二點是做業性能相關的，如做業的處理延遲、數據傾斜、性能瓶頸（如外部訪問）等。

3. 第三點是業務邏輯相關，如上游數據質量、新上的邏輯是否存在問題、數據是否存在丟失（ Exactly once 語義中數據是否容許丟失）。

3. 指標的聚合方式

在上面介紹了經常使用的監控指標，接下來介紹下這些指標應該怎麼看。同一個指標可能在機器的角度去看，也可能在做業的角度去看，不一樣的角度會得出不一樣的結果。

首先是做業的聚合維度，細粒度的如 Task、Operator 維度，稍微大點的粒度如 Job、機器、集羣或者是業務維度（如每一個區域）。當查問題時從大的粒度着手，向細粒度進行排查。若是想看全局的現狀則須要比較粗的粒度。能夠將原始指標進行上報而後根據不一樣場景進行聚合。若是要作性能測試則須要細粒度的查詢，如 task 粒度。

另外一方面是聚合的方式，如總和、均值、最大值、最小值、變化率等，須要注意是要消除統計偏差，對數據取移動平均或者固定時間的平均來使曲線變得更加平滑。還有是差值，如上游數據量與下游數據量的差值、最新 offset 與消費的 offset 的差值。另外對於衡量 xx 率、xx 耗時可使用 99 線。 最後還有一點須要關注的，也是咱們在實際工做中遇到的坑，即 指標的缺失 ，若是沒有拿到指標，做業狀態則變成了黑盒，須要去關注做業的指標收集是否正常，須要監測是否存在指標丟失，是單個指標丟失仍是整個做業的指標丟失。

最後是在觀察指標的時候可能須要多個指標複雜聚合查詢，如常見的時間線對比，例如以前正常的做業在今天出現反壓，能夠經過查詢今天數據量的同比昨天數據量的增加。另外不一樣的業務有不一樣的趨勢，例如外賣存在高峯時間段，能夠對比數據量在高峯時間段的環比增加來進行衡量。還有關注的指標的持續時間，如做業的數據延遲，若是延遲時間較長則做業可能存在異常；還有指標的週期性，若是指標的變化存在週期性，則考慮是否由於時間窗口的影響。

還有須要考慮的是結合外部系統進行計算，例如上游爲消費 Kafka ，除了想知道當前消費的情況，還想查看上游的數據量。例如該圖中，藍線爲上游 Kafka 的數據量，紅線爲做業的 source 算子的 output 數據量，能夠看到在午高峯和晚高峯基本上是持平的狀態， 上游數據在午高峯及晚高峯有較高的增加，雖然在高峯時刻有反壓，但主要緣由是因爲上游數據量的增加而不是因爲做業的處理能力不足。若是上游有多個算子能夠將多個算子的數據量進行相加，這也是咱們除了使用 Grafana 外還自研的前端進行展現的緣由，自研前端能夠將指標更加靈活的進行展現。

4. 指標監控的應用

4.1 做業異常報警

• 做業狀態異常： 包括做業任務的異常狀態如 failing，也包括 uptime 等指標的異常。
• 做業無指標上報： 做業無指標上報會給做業的負責人發報警；當上報的做業多到必定程度了，達到預值的時候會直接給平臺的管理員發報警。
• 指標達到閾值： 是你們最經常使用的報警項。好比：
• 處理量跌0
• 消費延遲（落後必定數量、持續必定時間）
• 失敗率、丟失率等
• 個性化： 實時計算平臺中有不少類任務，不一樣的任務它會有不一樣的特性。好比：

• 報警時段：不一樣的時間段報警，可能須要有不一樣的域值，或者不一樣的報警方式（公司通信軟件報警、電話報警等）

• 聚合方式：不一樣的業務可能會有不一樣的報警的聚合的方式，這個也是須要儘可能的兼容的。
• 錯誤日誌、關鍵詞日誌： 當錯誤日誌到達必定量或者日誌出現某關鍵詞時，觸發報警。

注意：報警系統自己的穩定性， 放到第1位，避免出現誤報、漏報、延遲。不然會影響業務方的準確判斷。

4.2 指標大盤

• 反映平臺總體的現狀：
• 異常值高亮
• 多維度聚合
• 時間線對比等
• 及時發現並快速定位到故障
• 給出平臺可優化的方向
• 便於統籌資源分配

4.3 自動化運維

運維的幾種階段：

• 沒法運維： 沒有指標，做業狀態是個黑盒，出了問題一羣人查代碼。
• 手動運維： 重啓，擴容，回滾、遷移，降級，糾正錯誤代碼，優化處理邏輯。手動運維表示不管在幹什麼，當報警電話一來，你須要掏出電腦、手機去排查問題。
• 輔助運維： 當手動運維作多了，把你們的業務做業的各項指標都進行標準化，咱們就能夠獲得一些參考值。把這些經驗彙總，做爲其餘同窗的運維的時候參考的建議，這樣即便是新人也能夠快速藉助這些輔助工具進行處理，下降學習成本。
• 智能運維： 智能運維是不須要人處理，當發生故障的時候，自動操做的運維方式。執行做業的機器掛了，自動拉起，自動把做業啓動起來。資源不足了，自動去擴容。線上的做業有問題，自動切換到備用的做業……固然目前能作到的這些只能解決一部分問題，一些代碼問題帶來的故障仍是須要人爲介入修復 bug。

Q&A

Q1：構建一整套指標系統，指標庫如何維護？須要去對程序進行代碼級別的修改，仍是修改配置便可？

A： 既然想作一整套的監控系統天然但願這個指標儘量是一個可適配的方式，那麼咱們須要作什麼？

• 在設計整套系統的架構時，須要有必定的兼容性，不能只關注一類指標。

• 設計初期須要考慮有哪些類型的指標，每一個類型的指標有什麼樣的特徵，可能有哪些聚合的維度，用什麼樣的方式去聚合。

• 搭建模型。

• 設計，先把指標的特徵提取出來，而後對這些特徵去進行設計，最後作一個能兼容的系統，這樣對於已知類型的指標，就只需修改配置就能夠擴展了。

Q2：Grafana 平臺的展現效果很好，可是報警不友好；報警這塊有比較成熟的工具嗎？

A： 能夠看看 Prometheus，報警仍是挺成熟的。報警比指標聚合更須要個性化的東西，若是須要功能很是完善的話，可能都須要考慮自研。

Q3：算子內部能夠獲取到 taskManager 的指標嗎？

A： 經過 restful API 去拿，不推薦在算子內部作，指標這個東西自己不該該影響你做業自己的處理邏輯，監控應該是一個比較外圍的東西。

Q4:   如何根據指標發現做業問題的根源？

A:   按照指標從粗到細，能夠參考 2.8 節和 3.1 節老師的教程。

Q5:  指標數據量比較大，如何選擇存儲？

A:   能夠選擇 openTSDB，其餘 TSDB 也是能夠的，像其餘 Hive 或者 OLAP引擎 也是能夠考慮的，指標數據做爲一種時序數據，目前已有不少成熟的方案能夠選擇。

點擊「 閱讀原文 」可回顧做者分享視頻～

---

關注 Flink 中文社區，獲取更多技術乾貨

你在看」嗎？

本文分享自微信公衆號 - Flink 中文社區（gh_5efd76d10a8d）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。