整理：李培殿 & 楊偉海（Flink 社區志願者）
校對：楊偉海（Flink 社區志願者）
摘要：本文由美團點評研發工程師孫夢瑤分享，主要介紹 Flink 的指標監控和報警的內容，分為以下四部分：
- 監控告警鏈路：基於美團點評實時計算平臺的實踐
- 常用的監控項：哪些指標可以高效地衡量作業
- 指標的聚合方式：橫看成嶺側成峰
- 指標監控的應用：有哪些常見的表達方式供參考
Tips：點擊「閱讀原文」鏈接可查看作者原版 PPT 及分享視頻～
為什麼我們關注指標監控
我們將以天氣舉例。
指標：衡量和描述對象的方式
- 可量化：比如最近天氣很熱。今天比昨天熱嗎？北京的溫度比上海更熱嗎？大家就沒有辦法評判，所以溫度就是這樣一個指標，來量化我們天熱的程度。
- 標準化：我們習慣說的溫度是攝氏溫度，如果有人跟你講華氏溫度，說今天77度，你就會覺得很奇怪，氣溫怎麼會有這麼高的數值，因此，我們的指標還需要是標準化的，需要有一個統一的標準。
- 多維度：南方的同學覺得35度悶得喘不過氣來；北方的同學覺得35度好像也就那樣。因為我們除了氣溫這個指標會影響人體的舒適度之外，還有一個指標叫空氣溼度。所以衡量天氣需要結合多個維度的指標。
監控：對指標進行監測和控制
- 實時：比如天氣預報，實時的預報才是我們需要的監控內容。
- 易用：相比於電視機裡固定時間播報的天氣信息，手機 App 就是易用的天氣監控軟件。
- 可查詢歷史：比如前幾天某地一直在下雨，河流湍急，可能影響我出行的選擇。
今天的分享從以下四個方面展開：
- 監控報警的鏈路——基於美團點評實時計算平臺的實踐
- 常用的監控報警項——哪些指標可以高效地衡量我的作業
- 指標的聚合方式——橫看成嶺側成峰
- 指標監控的應用——有哪些常見的表達方式供參考
1. 監控報警的鏈路
1.1 監控報警鏈路
美團點評的指標監控報警的鏈路如下圖所示。首先是我們對日誌和指標都會進行統一的集中化的收集。Reporter （2.8和3.1中有介紹）把 Flink 作業的指標作為一條條日誌打出來。然後再通過日誌收集收上去，收到 Kafka 裡面。接下來會通過實時作業做解析和聚合，再將得到的指標落到 Kafka 裡，作為實時數據源。
下游會根據不同的需求，對不同的數據做不同的處理和展示。日誌數據會落到 ES 裡供查詢使用，同時也會根據關鍵字接實時作業進行處理，做日誌相關報警；數值指標會落到 OpenTSDB 裡供大家查詢，同時也支持各類的指標報警。最終這些內容還是會集中到我們的實時計算平臺裡，給用戶做一個統一的展示。
整個鏈路下來，主要分為三個關鍵環節。
- 日誌收集部分，我們首先是要把這些日誌和指標進行統一化、集中化的收集。對於這一環，之前兩個講師也講過， Flink 現在提供的方式有三種：一個是在 Flink UI 上可以直接看到這個作業的一些指標；第二種 REST API 從作業上獲取指標；第三種就是配各種第三方的 Reporter 。美團這邊是在 slf4j 的基礎上增加自己的維度信息格式化後往下發。
- 解析展示部分，使用一些 Flink 作業去解析聚合平臺所有作業的指標數據，展示給用戶，也提供給下游使用。
- 監控和報警部分，對於聚合完成了的指標，做一些個性化的可配置的規則報警。
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 如何確定哪些指標需要關注？
- 第一點是作業狀態相關的， 如作業是否出故障、作業是否存活、作業是否穩定運行、影響作業可用性的風險因素（如上次 checkpoint 是否成功、最近成功的 checkpoint 的時間）。
- 第二點是作業性能相關的，如作業的處理延遲、數據傾斜、性能瓶頸（如外部訪問）等。
- 第三點是業務邏輯相關，如上游數據質量、新上的邏輯是否存在問題、數據是否存在丟失（ 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引擎 也是可以考慮的，指標數據作為一種時序數據，目前已有很多成熟的方案可以選擇。
點擊「閱讀原文」可回顧作者分享視頻～