網易雲信服務監控平台實踐
文 | 戴強 網易雲信數據平台資深開發工程師
導語：數據在很多業務中都至關重要，對於網易雲信，我們通過數據來提升服務並促進業務持續增長。藉助於服務監控平台的能力，我們可以很直觀的感受到線上服務的運行狀況，本文將詳細分析網易雲信的服務監控平台具體是如何實現的。
引言
通常人類的恐懼都來源於對現實世界的未知。
現實生活中存在很多的不確定性，恐懼是因為我們當前的認知無法對其作出合理解釋。例如這次的疫情的突然爆發，人們對死亡的恐懼不斷蔓延。世界存在很多的不確定性，什麼是不確定性？假設需要對明天的股票指數是漲是跌作出判斷，在沒有任何數據作支撐的情況下，我們只能像拋硬幣一樣都是百分之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搭建了網易雲信的實時和離線數倉體系，同時負責服務監控平台、數據應用平台、質量服務平台的設計開發工作。
