文 | 戴強 網易雲信資料平臺資深開發工程師 導語：資料在很多業務中都至關重要，對於網易雲信，我們通過資料來提升服務並促進業務持續增長。藉助於服務監控平臺的能力，我們可以很直觀的感受到線上服務的執行狀況，本文將詳細分析網易雲信的服務監控平臺具體是如何實現的。 ## 引言 通常人類的恐懼都來源於對現實世界的未知。 現實生活中存在很多的不確定性，恐懼是因為我們當前的認知無法對其作出合理解釋。例如這次的疫情的突然爆發，人們對死亡的恐懼不斷蔓延。世界存在很多的不確定性，什麼是不確定性？假設需要對明天的股票指數是漲是跌作出判斷，在沒有任何資料作支撐的情況下，我們只能像拋硬幣一樣都是百分之50的概率。在這種場景下，我們做出的所有判斷都是不可信的，並且會對自己的決定感到不安。 假如人們瞭解了所有涉及某種即將發生的事件的因素，那麼他們就可以精確地預測到這一事件；或者相反，如果發生了某個事件，那麼就可以認為，它的發生是不可避免的，這便是拉普拉斯的信條（又名決定論）。 正如以上的理論所表達的意思，資料可以幫助我們指引方向，並且驗證我們的方向是否正確。同樣，資料對於網易雲信的發展來說也至關重要，我們需要通過資料來提升我們的服務，並促進業務持續增長。 網易雲信是集網易20年 IM 以及音視訊技術打造的 PaaS 服務產品，我們一直致力於提供**穩定可靠的通訊服務**，而如何保證穩定可靠呢？ **服務監控平臺**就是其中重要的一環，其就相當於布加迪威龍上的儀表盤，汽車的時速是多少，油量是否足夠，當前的轉速是多少，這些在儀表盤上一目瞭然，可以幫助我們做出判斷：是不是還可以踩一點油門，必要的時候是不是該剎一下車。服務監控平臺的目標和價值就在這裡，它也就相當於網易雲信這輛布加迪威龍的儀表盤，可以告訴我們當前的服務質量怎麼樣，是不是需要多加點“油”，是不是需要踩一下“油門”或者“剎車”，給我們和客戶提供更多的資訊，幫助我們提供最優質的、最可靠、最穩定的服務。  本文就來詳細分析網易雲信的服務監控平臺具體是如何實現的，將從整體架構出發，簡單介紹網易雲信服務監控平臺的框架，再仔細分析包括資料採集、資料預處理、監控告警、資料應用四個模組的實現。 ## 系統架構 現在網易雲信的音視訊資料基本都來源於客戶端和服務端日誌，所以整個資料的採集鏈路是其中非常重要的一環，決定了資料的有效性和時效性。 首先，我們來看一下網易雲信採集監控平臺的整體架構，如下圖：  採集監控平臺整體架構主要分為資料採集、資料處理、資料應用、監控告警四部分，整個處理流程如下： - 資料採集： - 我們主要的資料來源為業務 SDK 和應用伺服器，這些資料可以通過 HTTP Api、Kafka 兩種方式接入採集服務。 - 採集服務對資料進行簡單校驗和拆分，然後通過 Kafka 傳輸到資料清洗服務。 - 資料處理：資料處理服務主要負責對接收到的資料進行處理然後發給下游服務使用。其中我們提供了 JOSN 等簡單的資料格式化能力，另外也提供了指令碼處理模組，以支援更靈活更強大的資料處理能力，該能力也使得我們監控平臺的資料處理能力更富多樣性。 - 監控告警：監控告警模組對於我們一開始提到的服務監控能力來說，是最重要的一環。我們對於採集到的資料進行分維度聚合統計和分析，使用豐富的聚合演算法、靈活多變的規則引擎來最終達到服務預警和問題定位的目的。 - 資料應用：清洗後的資料可以直接寫入時序資料庫供問題排查平臺使用，也可以通過 Kafka 接入 es、HDFS、流處理平臺，最終供應用層使用。例如：質量服務平臺、通用查詢服務、問題排查平臺等。 接下來我們會對上述四個模組進行詳細的分析。 ## 資料採集 資料採集是服務監控平臺的入口，也是整個流程的第一步，下圖是資料採集模組的架構圖。  上文也有提到，為了便於使用者接入，我們提供了 HTTP API 和 Kafka 兩個通道給業務方。 - HTTP API 多用於端側或伺服器中偏實時的資料上報場景，用以支援秒級的資料接入。 - Kafka 多用於高吞吐量、資料實時性要求不太高的場景。 - 資料過濾預處理模組，提前將一些非法資料進行過濾，並預先資料拆分等處理。 最後通過 Kafka 傳輸到資料處理服務，接下來就是資料處理階段的介紹了。 ## 資料處理 完成資料採集階段後，即進入資料處理階段，具體流程如下：  - 任務排程，主要負責資料處理執行緒的生命週期管理，從啟動到關閉。 - 消費者，在獲取資料後使用內部的佇列進行解耦，從而達到橫向擴充套件的能力以提高資料處理執行緒的並行度。 - 處理單元，可以根據需要設定並行度： - 資料處理能力分成兩種，通用規則和自定義指令碼。通用規則就是簡單的 JSON 轉換、欄位提取等，這些基本可以滿足80%的需求，但是為了支撐類似多欄位關聯計算、正則表示式、多流關聯處理等複雜業務，我們也提供了自定義指令碼進行資料處理的能力。 - 維度表的使用主要是針對多資料流關聯處理的場景，為了解決資料量和併發高的問題使用了本地+第三方快取的方案。 - 時序資料庫輸出：時序資料庫我們使用的是NTSDB，NTSDB 是網易雲基於influxdb做的叢集化方案，有高可用、高壓縮比、高併發等特點。 資料處理完之後，接下來一個比較重要的階段就是監控告警。 ## 監控告警 下面這張圖簡單展示了監控告警的流程：  監控告警階段分為指標聚合模組以及告警模組。 指標聚合模組支援指定欄位分組統計、靈活的聚合視窗時間、資料過濾、細粒度的運算元級別的資料過濾、資料延遲最大時間。最重要的是我們支援了非常豐富的聚合運算元：累加、最小/最大值、firstValue/lastValue、平均數、記錄數、去重計數、TP系列（TP90/TP95/TP99）、環比、標準差等，同時還支援在第一次指標聚合後進行復合計算的能力（複合指標）。這些豐富的運算元為我們實現更多靈活的監控規則提供了保證。 另外我們將原有的一階段聚合改成了兩階段聚合，為什麼呢？因為在資料處理的過程中我們經常會遇到的一個問題：資料熱點問題導致的傾斜。所以這裡我們增加了預處理階段，在這一階段利用隨機數進行打散，保證資料的均衡，然後預聚合的資料在第二階段進行總的聚合處理。 告警模組和指標聚合模組從原有的一個模組拆分為兩個，指標模組更多的關注如何做資料聚合，而不是和告警模組耦合在一起作為告警模組的一部分。而告警作為一個附加的功能，只需要根據接收到的資料，做一些告警的規則校驗、頻控校驗、告警資訊封裝、對接訊息平臺傳送告警訊息，同時支援了內部 IM 平臺、簡訊、電話等訊息通道，多樣的訊息通道是為了可以第一時間感知到問題的出現。 ## 資料應用 資料應用現有的平臺：資料視覺化、質量服務平臺、ELK日誌平臺、線上離線分析等。下面，我們針對每個平臺簡單介紹一下。 ### 資料視覺化 資料視覺化這部分，我們和大部分公司一樣使用 Grafana 來實現。需要做視覺化的資料可以先同步到NTSDB中，然後再使用 NTSDB 作為資料製作圖表和大盤。另外對於不支援的圖表，我們針對Grafana 做了二次開發以支援更多的視覺化需求。 下圖皆是針對音視訊問題排查場景做的一些儀表盤：   ### 質量服務平臺 該平臺旨在為客戶提供直觀、高效、全面、實時的問題定位排查工具，客戶在收到問題反饋之時，可以第一時間發現、定位問題，並最終反饋使用者和進行優化。  ### ELK 日誌平臺 ELK 技術棧包含 Logstash、ES、Kibana 三個元件，是一整套日誌採集、儲存、查詢及視覺化的解決方案。當前在我們的體系中，更多的用於詳細日誌的查詢。 ### 線上離線分析 這裡我們使用 Kafka 作為資料管道，藉助 Flink 平臺對日誌資料進行切分和歸檔。將這部分資料同步到離線數倉後，可以進行後續的資料探勘分析工作，同樣這裡也不擴充套件討論。 ## 結語 以上就是本文的全部介紹，分析了網易雲信服務監控平臺的設計和實踐，其中主要介紹了整個服務監控平臺的系統架構，並且針對資料採集、資料處理、監控告警、資料應用四個點做了一些闡述。 網易雲信的整個資料採集監控體系從2020年初上線至今，從原有的十幾個採集任務增長到了300多個，100+的關鍵使用者行為和系統事件、300+的核心音視訊指標，每日處理百萬行的資料、T級的資料量。整個平臺的併發量、吞吐量都在不斷地上升，這都得益於雲信業務的不斷增長，但也使得我們對平臺的穩定性和擴充套件性提出了更高的要求。 未來，我們將藉助於平臺的能力為客戶們提供更加優質的服務。 ### 作者介紹 戴強，網易雲信資料平臺資深開發工程師，一直從事資料平臺相關工作，從0到1搭建了網易雲信的實時和離線數倉體系，同時負責服務監控平臺、資料應用平臺、質量服務平臺的設計開發