怎么理解Flink指標、監控與告警

怎么理解Flink指標、監控與告警，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

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

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

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

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

• 監控報警的鏈路——基于美團點評實時計算平臺的實踐
• 常用的監控報警項——哪些指標可以高效地衡量我的作業
• 指標的聚合方式——橫看成嶺側成峰
• 指標監控的應用——有哪些常見的表達方式供參考

1.1 監控報警鏈路

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

1.2 指標展示：Grafana

2.1 常用的指標

• 對于系統指標最常關注的是作業的可用性，如 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 作業中可能需要訪問外部存儲（如 Redis ）, 可以通過打點來查看請求的耗時、請求的成功率等。

• 還有是緩存命中率，有時候由于數據集過大，我們只訪問熱數據，此時會在內存中緩存一部分信息，我們可以監控緩存命中率，如果緩存命中率非常高說明緩存有效，如果緩存命中率非常低，一直在訪問外部存儲，就需要考慮緩存設計的是否合理。
  

2.2 如何確定哪些指標需要關注？

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

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

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

4.1 作業異常報警

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

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

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

4.2 指標大盤

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

4.3 自動化運維

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

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

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

• 搭建模型。

• 設計，先把指標的特征提取出來，然后對這些特征去進行設計，最后做一個能兼容的系統，這樣對于已知類型的指標，就只需修改配置就可以擴展了。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。