大資料監控建設之道

01

—

為什麼要做

從谷歌2003年釋出的三篇經典論文《The Google File System 》、《MapReduce: Simplified Data Processing onLarge Clusters》、《Bigtable: A Distributed Storage System for Structured Data》開啟了大資料的時代，經過20年的蓬勃發展，大資料已經非常普及常用了。

考慮到大資料4V的特性，你很難說隻用一個技術方案或者元件就能應對所有的場景和需求。是以大資料技術架構相對來說還是較為複雜的，其中還涉及到了很多分布式、高可用的機制。比如HDFS的namenode，那如果namenode沒有做HA的情況下，出現服務異常終止的情況，基本上整個大資料叢集就會宕掉，所有的服務基本都不可用了。這種情況是緻命的，你的服務将徹底癱瘓并且無法快速恢複。

那為了保證大資料服務的穩定高可用，我們除了要對相關的服務或元件做HA設計，還需要有完善的監控告警方案，來及時發現目前大資料服務中的隐患和故障并進行消除，以確定目前大資料服務的SLA。

接下來我們就來展開讨論，本文是關于大資料監控告警建設的道而非術，我們會介紹從哪些方面去建設監控告警，而如何建設采用哪些技術方案你完全可以結合目前生産實際情況或者現有标準規範去實施。

02

—

從哪些方面做

在開始之前，我們有必要介紹下大資料的技術架構，這樣有助于我們了解大資料的組成架構、這樣我們可以更好的切入去做監控的建設。

我們從下向上看，我們可以分成如下

1. 資料來源層：此層基本上是數倉的ODS層資料來源，如app/web的埋點日志，MySQL/mongodb中的業務資料，外部檔案等等，此層基本上不需要做監控。
2. 資料采集層：此層是将業務資料、埋點資料接入數倉的實作，我們目前使用的是FlinkCDC做業務資料實時內建，在此層可能需要關注的就是你的資料內建任務是否正常。
3. 資料存儲層：此層基本是将收集到的業務資料、埋點資料放入大資料存儲中，考慮到不同的資料存儲需求，此層的資料存儲可能會比較豐富不僅僅隻有HDFS，此層需要關注的就是存儲相關服務健康度以及你的存儲使用情況。
4. 資料計算層：此層主要就是資料計算了，會有Flink實時處理&離線批處理。此層需要關注的就是你的計算任務執行是否正常、執行是否逾時、Flink任務是否異常終止、Flink任務ck是否正常等等。需要結合你的計算任務來梳理需要做哪些監控。
5. 排程引擎層：此層就是對你的計算任務做周期性排程了，同樣會有Flink實時處理&離線批處理。此層需要關注的就是你的排程服務健康度，以及任務的排程執行情況了。我們将任務的排程執行情況和資料計算層的監控一起來看，排程本身也是在做資料的計算執行。
6. 資料服務層：資料服務層基本上就是對外提供資料服務能力了，不同公司會有不同的資料服務能力輸出方案。可以是grafana等資料可視化平台，也可能是對外API輸出，或者是自建的BI平台等等。此層基本上關注你的資料服務能力是否正常，需要結合你的生産實際情況來看。

是以我們将其抽象如下：

大資料基座

大資料基座基本就是叢集相關服務了，包括但不限于HDFS、hive、yarn、spark等等，他們組合再一起共同建構起了大資料的地基，我們可以基于此在上層進行資料的存儲、計算、分析等等一系列工作。

那麼按照我們的經驗來說，不管你是托管在第三方雲廠商還是基于CDH或者HDP建設，其監控需要關注的點基本相同。主要如下

• 主機執行個體健康度
• CPU
• 記憶體
• 磁盤使用、磁盤讀寫
• 網絡
• ......

• 叢集服務健康度
• hive、hdfs、yarn等服務健康度，服務不可用，程序故障等
• 各服務堆記憶體使用情況
• yarn 任務挂起、yarn資源使用、yarn隊列資源不足
• hive sql執行成功率低
• 程序重新開機、主備切換等關鍵事件
• ......

叢集服務健康度相對來說要做的更多，我們具體到每個單獨的元件可能都會有不同類型的監控，如hive的hms，hiveserver2，hive session等等，這裡我們不再展開贅述，你可以參照各雲廠商大資料叢集的監控也可以參照各元件的官方文檔。

資料內建據內建

首先可以看下我們的其中一部分的資料內建鍊路。這樣有利于我們了解需要做哪些方面的監控。

行為埋點資料

首先我們結合自己的實際業務情況指定了用戶端埋點協定，埋點協定主要從使用者資訊、裝置資訊、事件資訊、應用資訊等幾個大方面去定義一個完整的事件内容，這樣全公司各APP産品都可以基于我們的埋點協定來去做全鍊路的上報、存儲、統計分析等流程。

那麼使用者在APP觸發點選浏覽行為時，就會生成符合埋點協定的事件，然後收集nginx中的日志，通過logstash 向Kafka發送，因為我們的埋點相對來說還是比較大的，一天的增量約500GB，是以我們在這裡用Kafka來做緩沖。

埋點日志進入到Kafka後，我們會用Flink來去做實時的ETL，将其寫入Kudu資料加速層，做近實時的統計分析。

那麼在此處你要考慮的監控就是整個日志收集鍊路的各個環節，包括但不限于

● logstash服務健康度

● Kafka服務健康度

● 埋點事件上報位址是否正常

● .....

即使你做了上述各環節的監控，也不能百分百保證埋點日志出問題能立刻發現。我們這邊就遇到過兩次其它類型的問題，其一是用戶端埋點上報位址使用的域名被封禁了，其二是用戶端埋點上報位址的http證書過期導緻埋點無法正常上報。此時你的各個服務是正常的，但是埋點卻報不上來了。是以我們還需要持續的對上報的埋點事件總量波動做監控，你可以結合你的實際業務情況，做分鐘、小時、天粒度的各事件波動監控。這樣就可以在埋點事件量出現大幅波動的情況下，迅速感覺到。

下圖是我們的一個示例：

業務資料

由于大資料側無法直連業務DB做一些精細化的監控。是以我們隻能在資料內建的鍊路和進入ods層的資料層面做相關的監控告警了。

我們會用FlinkCDC來去做業務資料庫的整庫變更訂閱。是以首先要關注的就是你的FlinkCDC任務的健康度，Flink 任務執行是否正常等。我們在下文中的計算實時部分再詳細提及。

除此之外，在FlinkCDC将業務資料寫入Kudu後，我們還會持續的關注業務資料最新的資料産生時間，這樣在業務資料超過指定時間仍未有更新時及時發現。介入确認處理流程。

當然你也可以在你的FlinkCDC 任務中實作這個功能，具體的實作還是結合你的實際業務情況和規範來實施。

除了基于整庫的全局監控外，在業務資料進入數倉的ODS層後，我們還會結合資料品質監控來做具體的業務表的資料監控，比如單表資料掉0或者單表資料波動異常的情況，這部分将在資料品質環節介紹，此處就不再贅述。

存儲

HDFS

如果你使用的是HDFS，那麼從存儲層面，我們需要監控關注的點如下：

● DataNode磁盤故障：可能會導緻已寫入的檔案丢失。

● 單副本的塊數超過門檻值：單副本的資料在節點故障時容易丢失，單副本的檔案過多會對HDFS檔案系統的安全性造成影響。

● 待補齊的塊數超過門檻值：HDFS可能會進入安全模式，無法提供寫服務。丢失的塊資料無法恢複。

● 資料目錄配置不合理：資料磁盤挂載在根目錄或其它關鍵目錄下。對HDFS系統性能産生影響。

● HDFS檔案數超過門檻值：HDFS檔案數過多，磁盤存儲不足可能造成資料入庫失敗。對HDFS系統性能産生影響。

● 丢失的HDFS塊數量超過門檻值：HDFS存儲資料丢失，HDFS可能會進入安全模式，無法提供寫服務。丢失的塊資料無法恢複。

● DataNode磁盤空間使用率超過門檻值，會影響到HDFS的資料寫入。

● HDFS磁盤空間使用率超過門檻值，HDFS叢集磁盤容量不足，會影響到HDFS的資料寫入。

● ......

對象存儲

那如果你使用的是對象存儲，那麼恭喜你上述HDFS的相關監控項基本都不需要你去關注了，一切交給對象存儲。

你可能需要關注如下幾點：

● 存儲桶的使用情況

● 資料生命周期管理政策

● 安全審計，如AK/SK的儲存修改

● ......

計算

計算層面基本上關注的就是具體任務的執行情況了，我們針對實時、離線任務分開就行闡述。

實時

Flink已經成為實時計算領域的事實标準，是以我們這裡的實時主要針對Flink，實時任務需要關注的點如下：

● 任務是否異常終止

● 任務重新開機次數

● Kafka消費是否延遲

● ck是否正常、耗時情況、失敗數

● 是否有反壓、傾斜

● job本身的資源使用情況

● sink端的執行時間是否逾時

● 自定義名額打點收集

● ......

下圖是我們的Flink任務監控的一個示例：

關于Flink任務的監控，可以結合Flink metrics來去更細粒度的進行制定。

離線

離線任務主要為批處理任務，批處理任務相對簡單，無非成功或失敗或者逾時，是以我們主要關注如下幾點：

● 任務異常終止

● 任務執行逾時

● 任務平均執行時間(逾時優化)

● 長尾任務

● 占用資源過多任務

● ......

排程

排程服務相對來說簡單，在保證HA的前提上，關注你的排程服務是否異常即可。如dolphinscheduler，我們要關注

● master節點狀态

● worker節點狀态

● 節點相關負載

資料服務

資料服務是對外提供的資料能力，這也是大資料直接展現價值的載體。是以資料服務相關的監控需要格外重視。

我們需要關注如下：

● 資料服務是否正常，如grafana能否正常通路，API服務是否能夠正常調用

● 提供的資料是否準确，資料是否缺失等（我們将在資料品質環節詳細闡述）

● 服務響應時間，如頁面加載時間、API調用時間

● ......

資料品質

資料品質監控會相對複雜，但是它是必須要做的，錯誤的資料将會直接影響業務的相關決策判斷。

根據DAMA制定的資料标準管理辦法，我們需要從如下角度進行資料品質監控

1. 完整性：資料完整性問題包括：模型設計不完整，例如：唯一性限制不完整、參照不完整；資料條目不完整，例如：資料記錄丢失或不可用；資料屬性不完整，例如：資料屬性空值。
2. 準确性：準确性也叫可靠性，是用于分析和識别哪些是不準确的或無效的資料，不可靠的資料可能會導緻嚴重的問題，會造成有缺陷的方法和糟糕的決策。
3. 時效性：時效性用來衡量能否在需要的時候獲到資料，資料的及時性與企業的資料處理速度及效率有直接的關系，是影響業務處理和管理效率的關鍵名額。
4. 唯一性：用于識别和度量重複資料、備援資料。重複資料是導緻業務無法協同、流程無法追溯的重要因素，也是資料治理需要解決的最基本的資料問題。例如：業務主鍵id重複。
5. 資料一緻性：多源資料的資料模型不一緻，例如：命名不一緻、資料結構不一緻、限制規則不一緻。資料實體不一緻，例如：資料編碼不一緻、命名及含義不一緻、分類層次不一緻、生命周期不一緻……。相同的資料有多個副本的情況下的資料不一緻、資料内容沖突的問題。

在此基礎上，我們需要對各種類型進行細粒度的劃分。

03

—

總結和經驗

1. 使用郵件組或者訂閱的方式進行告警通知，以免人員變動情況下相關的告警通知對象變更。
2. 重要告警內建睿象雲，進行短信和電話告警，以免非工作日時間告警接受處理延遲。
3. 監控不需要追求大而全，而是按照更要程度及SLA進行建設。
4. 可能受影響的相關方必須訂閱相關監控告警通知，以免A方以為此告警不重要，但是對B方很重要，甚至會影響業務。
5. 監控、告警、處理要有完整的流程閉環及知識沉澱，形成監控告警處理知識庫。

參考文檔：

[1].百分點大資料技術團隊：萬億級大資料監控平台建設實踐_大資料_百分點認知智能實驗室_InfoQ精選文章https://www.infoq.cn/article/XudrcZEUFhPJR7kfYNur

[2].大資料叢集監控體系架構 - 掘金 (juejin.cn)

https://juejin.cn/post/6967234979847733279

[3].ALM-13000 ZooKeeper服務不可用（2.x及以前版本）_MapReduce服務 MRS (huaweicloud.com)

https://support.huaweicloud.com/intl/zh-cn/usermanual-mrs/alm_13000.html

[4].DAMA知識體系解讀（12）資料品質管理 - 知乎 (zhihu.com)

https://zhuanlan.zhihu.com/p/208935690

作者 | 馮成楊 資深大資料開發工程師

來源-微信公衆号:微鯉技術團隊

出處:https://mp.weixin.qq.com/s/TJk704oudI3mnhJgpjaLXg