鑽石舞台

作者：龍逸塵，騰訊 CSIG 高級工程師

在後移動互聯網時代，良好的用戶體驗是增長的基礎，穩定的使用體驗就是用戶體驗的基礎。大型的互聯網公司，特別是面向 C 端客戶的公司，對業務系統穩定性的要求越來越高，因此對線上問題發現和處理的速度要求通常是分鐘級的。比如滴滴等出行公司，打車服務停擺 10 分鐘都會導致導致乘客、司機大規模投訴，不僅造成經濟損失，而且嚴重平台商譽和用戶口碑。

大型互聯網公司的業務系統都是大規模的分布式系統，各種業務應用和基礎組件（數據庫、緩存、消息隊列等）共同交織成複雜的依賴網絡，任何節點都可能出現故障，導致系統不可用。因此，業務系統的監控非常重要，通過監控及時發現和干預問題，避免事故或降低事故影響範圍。

本文將從監控系統整體架構設計、監控系統技術方案落地這兩部分闡述了百億級大數據實時監控系統的建設過程，旨在幫助大家了解監控系統設計思路，對於監控系統建設提供專業指導，快速構建監控系統。

世界上並不存在完全可靠的系統，程序、機器、網絡等都可能在運行中出現故障，進而導致服務異常。因此監控的目標就是，高效及時地發現、定位系統異常問題，期望縮短異常的平均修復時間，從而降低異常造成的損失。

為了實現縮短異常的平均修復時間這一目標，監控系統應該具有這些能力：

根據對監控系統需求的調研，可以將監控系統整體的數據流轉過程抽象為以下幾個階段：採集 -> 匯聚 -> 處理 -> 存儲 -> 分析 -> 展示 -> 告警。

從中我們可以總結出監控系統的一般架構：

從下往上來分析，首先是數據採集層，提供眾多採集手段，包括 Agent 採集、RPC 埋點、HTTP 上報等，可以通過 Agent 採集宿主機監控數據和日誌，或者 RPC 埋點上報，也可以由用戶直接通過 HTTP 推送進行數據採集。

成功採集到的數據，需要經過統一的數據匯聚層，將相關聯的數據進行匯聚。例如同一業務系統的所有服務器數據將會匯聚到一個相同的消息隊列中，便於異常檢測。

數據完成匯聚後，將分為三條數據流處理：數據處理、數據分析、數據存儲。

數據流處理完成後，進入監控告警層，對符合監控、告警規則的事件進行告警推送。

數據流最終到達數據展示層，提供常見的用戶交互頁面：如監控面板、告警面板等。

提到監控系統方案，大家首先想到的肯定是 Elastic Stack（Elasticsearch、Logstash、Kibana、Beats），其活躍的社區、簡單的安裝流程、便捷的使用方式等優勢吸引了大量用戶，當前許多互聯網公司的監控系統架構都是基於開源 Elastic stack 搭建的。

Elastic Stack 由 Elasticsearch、Logstash、Kibana 和 Beats 組成。下面分別對各個組件進行簡單的介紹。

Elasticsearch 是一款實時全文搜索和分析引擎。作為 Elastic stack 的核心，Elasticsearch 可用於搜索各種類型的數據：從文本、數字和地理空間數據到其他類型的結構化和非結構化數據，主要支持搜索、分析、存儲數據三大功能。Elasticsearch 基於 Apache Lucene 搜索引擎庫構建，它易於使用且可擴展。

Logstash 是一款日誌聚合器，它可以從各種輸入源動態採集監控日誌和數據，對其進行轉換後，將數據傳送到各種支持的輸出目的地。許多用戶將轉換後的數據發送到 Elasticsearch，在其中對日誌、監控數據進行索引與搜索。

Kibana 是工作在 Elasticsearch 之上的可視化層，為用戶提供數據分析和可視化的能力，可將存儲在 Elasticsearch 中的數據轉換為易於使用的圖表、圖形、直方圖和其他可視化表示，進而深入挖掘數據特徵。

Beats 是一款輕量級日誌採集器，目前 Beats 包含多種工具：Metricbeat、Filebeat、Heartbeat 等。每個 Beat 都有一個簡單的任務：採集日誌或數據並發送到輸出目的地。

早期的 ELK Stack 使用 Logstash 收集並解析日誌，但是 Logstash 本身是基於 jdk 的，而且它集成了許多插件，對內存、CPU、IO 等資源消耗比較高。相比於 Logstash，Beats 所占系統的 CPU 和內存幾乎可以忽略不計，因此考慮使用輕量級的 Beats 組件來完成日誌和監控數據的採集操作。架構如下：

Elastic Stack 運行於分布式系統之上，為用戶提供了一個性能強大的平台，該平台通過採集、過濾、傳輸、儲存，對海量日誌和監控數據進行集中管理和准實時搜索、分析，提供准實時搜索、監控、事件消息和分析報表等簡單易用的功能，幫助運維人員進行線上業務的實時監控，業務異常時及時定位原因、排除故障，深度挖掘日誌的大數據價值。

但是 Elastic Stack 也存在一些不足。首先 Beats 只有採集日誌與監控數據的功能，無法對數據進行處理；另外 Logstash 的數據處理功能很弱，無法滿足複雜的數據處理需求，且不支持監控數據緩存，存在數據丟失的隱患。

綜上所述，在將監控數據與日誌信息保存到 Elasticsearch 之前，需要引入消息隊列緩存數據，並使用大數據實時計算引擎對數據進行實時的過濾、轉換、聚合。

而騰訊雲流計算 Oceanus 恰好可以實現這些功能。流計算 Oceanus 是大數據產品生態體系的實時化分析利器，是基於 Apache Flink 構建的具備一站開發、無縫連接、亞秒延時、低廉成本、安全穩定等特點的企業級實時大數據分析平台。流計算 Oceanus 能很好地滿足監控場景下海量實時數據處理的需求，監控系統可以利用 Oceanus 的實時計算能力，對監控日誌與數據進行清洗、轉換並完成聚合分析，實時計算的結果可以直接用於監控告警展示，極大地提升了運維人員在故障發生時的決策能力。

使用 Elastic Stack 還需要關注的點是監控面板。Kibana 的長處在於日誌分析，且僅適用於 Elasticsearch，不支持任何其他類型的數據源；它的面板展示能力還有提高的空間，而且具有陡峭的學習曲線，對於非技術業務用戶來說很難上手。因此可以考慮使用其他的數據可視化工具代替 Kibana 作為監控面板，讓 Kibana 專注於日誌分析。綜合對比現有的可視化工具後，我們選擇使用 Grafana。

在實際應用場景中，可以使用 Beats 採集日誌與監控數據，將 Kafka 作為 Beats 的輸出端。Kafka 實時接收到 Beats 採集的數據後，使用流計算 Oceanus（Flink）進行實時處理與聚合，將滿足需求的數據輸出到 Elasticsearch 中進行分布式檢索，通過 Kibana 進行日誌分析，最後採用 Grafana 作為監控面板。流程如下圖所示：

Zabbix 是一款開源的分布式系統監控軟件。它支持可視化配置，提供多種指標採集，支持自定義告警閾值與多樣的通知機制。Zabbix 靈活的設計為用戶提供了易用的二次開發接口，讓用戶既可以使用 Zabbix 本身提供的功能，又可以自定義更多的監控項功能，如硬件監控、操作系統指標監控、服務進程監控等。

Prometheus 是一款基於 Go 語言開發的監控、告警、存儲套件，它通過 HTTP 協議從遠程的機器收集數據並存儲在本地的時序數據庫上。Prometheus 架構簡單，單個服務器節點可直接工作，屬於輕量級的 Server。同時不依賴外部存儲，便於遷移和維護，其監控數據直接存儲在 Prometheus Server 本地的時序數據庫中，單個實例可以處理數百萬的 Metrics。Prometheus 具有靈活的數據模型和強大的數據查詢語句，可以幫助快速定位和診斷問題，非常適用於面向服務架構的監控。

Grafana 是一個開箱即用的可視化工具，具有功能齊全的度量儀錶盤和圖形編輯器，有靈活豐富的圖形化選項，支持配置多種數據源，例如 Elasticsearch、InfluxDB、Prometheus 等。Grafana 可以通過 Datasource 鏈接 Prometheus url，並對接入的數據進行分組、過濾、聚合等邏輯運算，從而在監控面板中直觀展示監控指標。

Zabbix、Prometheus 和 Grafana 構建的監控系統部署簡單，功能完善，非常適合容器化環境，但是也存在一定的局限，主要缺點是在超大規模數據量下存在性能瓶頸。

Elastic Stack 與流計算 Oceanus 組合，構建了分布式、可拓展、實時化的監控系統，對海量日誌和監控數據進行集中管理和實時搜索、分析，提供指標監控、事件消息和分析報表等簡單易用的功能。性能完善，擴展性強，缺點是部署比較麻煩，資源消耗較高。

Zabbix、Prometheus 和 Grafana 構建的監控系統部署簡單，功能完善，非常適合容器化環境，但是存在致命缺陷，超大規模監控數據量下無法突破性能瓶頸。

綜上所述，我們最終考慮採用流計算 Oceanus 和 Elastic Stack 構建監控系統。

隨着業務量的上漲，監控指標逐漸增多，需要監控的設備不斷增長，對監控系統的性能要求也日益提升。當數據量增長到百億甚至千億級別，監控系統可能會出現以下問題：

當系統不穩定或者處理性能下降時，數據延時會上漲至小時甚至天級別，這對於需要儘量做到實時化的監控系統來說是無法接受的。

而面對超大規模監控數據量的場景，騰訊雲流計算 Oceanus 和 Elasticsearch service 進行了大量優化。下面進行詳細介紹。

流計算 Oceanus 是大數據產品生態體系的實時化分析利器，是基於 Apache Flink 構建的具備一站開發、無縫連接、亞秒延時、低廉成本、安全穩定等特點的企業級實時大數據分析平台。

流計算 Oceanus 能很好地滿足監控場景下海量實時數據處理的需求。監控系統可以利用 Oceanus 的實時計算能力，使用簡單的 SQL 對監控日誌與數據進行實時清洗、轉換與聚合分析。

流計算 Oceanus 對原生 Flink SQL 進行了大量優化，提升超大規模數據量下作業的處理性能。

數據傾斜是導致 Flink 作業性能問題的常見原因。數據傾斜指的是數據分布嚴重不均衡，過多數據集中在某些 task 上，導致內存緊張，頻繁 GC；而頻繁的 GC 導致系統吞吐下降，數據延遲，嚴重情況下還可能導致 TaskManager 失聯，任務崩潰。

針對數據傾斜問題，流計算 Oceanus 自動為作業開啟 Local-Global Aggregate 與 Mini-Batch 功能。Local-Global Aggregate 能夠靠 Local Aggregate 的預聚合篩除部分傾斜數據，從而降低 Global Aggregate 的熱點，避免數據傾斜，提升處理性能。同時，在 Aggregate 的處理過程中可以開啟 Mini Batch 方式，Local 階段採取微批提交避免數據量緩存過多，Global 階段則可以減少狀態的訪問次數，降低 I/O 壓力。

Flink SQL 下還存在 UDF 函數復用的問題。如果相同的 UDF 在 SQL 中出現多次，例如簡單的 JSON 解析、URL 解析等，原生的 Flink SQL 會多次執行，影響性能。

針對 UDF 函數復用問題，流計算 Oceanus 將邏輯執行計劃中重複調用的 UDF 提取出來，並對 UDF 的執行結果進行緩存，避免多次調用。

流表維表 Join 中存在數據冷啟動問題，如果將維表數據加載到所有的 subtask 裡面會造成較大的內存消耗，而且很容易造成反壓。

流計算 Oceanus 的解決方案是，在維表的 DDL 中指定 Bucket 信息，流與維表進行 Join 的時候會基於 Bucket 信息去加載維表中對應分片的數據，同時在翻譯執行計劃的時候流表拿到 Bucket 信息，以保證流與維表的數據都會基於同一個 Bucket 信息進行 Join。這種處理方案能大大減少全量維表數據預加載帶來的內存消耗與反壓問題。

流計算 Oceanus 為作業異常重啟、Snapshot 失敗、以及 JobManager/TaskManager 的 CPU、內存異常等各類運行狀態的事件提供可視化的提示。

並且以異常日誌的採集和聚合分析為切入，智能地診斷分析異常信息，並給出建議的解決方案。

此外，流計算 Oceanus 還以 Task 粒度定義動態指標，並以維度聚合（sum、max、min、avg）的方式定義從上下游系統到集群作業的健康運行相關的 65+ 項監控指標，對作業進行全方位監控告警。

流計算 Oceanus 提供作業運行事件可視化、作業智能診斷與全方位監控告警等功能，為用戶的實時計算作業保駕護航。

流計算 Oceanus 提供作業自動擴縮容功能，根據 CPU、內存、反壓狀況等業務負載情況，自動進行作業並行度的調整，完成作業擴縮容。

當遇到數據傾斜、作業負載過高等事件時，流計算 Oceanus 會自動調整作業並行度，增加作業運行資源，從而避免數據傾斜，降低作業負載，保障作業穩定運行。而在業務低谷期流計算 Oceanus 會自動縮減作業計算資源，減少資源浪費。

作業自動擴縮容功能在保障業務時效性的同時，避免了資源浪費，可以為用戶降低可觀的成本。

伴隨數據量的極速上漲，開源 Elasticsearch 暴露出來的問題為：

Elasticsearch 的使用姿勢、參數調優等在社區有很多的案例和經驗可以借鑑，但是百億級實時監控場景下，很多的痛點和挑戰是無法通過簡單的調優來解決的。

騰訊雲 Elasticsearch Service（ES）是基於開源搜索引擎 Elasticsearch 打造的高可用、可伸縮的雲端全託管的 Elasticsearch 服務，包含 Beats、Kibana 及常用插件，並集成了安全、SQL、機器學習、告警、監控等高級特性（X-Pack）。為了應對上述的困難，騰訊雲 ES 從內核層面做了深度的優化。

Elasticsearch 底層的 Lucene 是基於 LSM Tree 的數據文件，原生默認的合併策略是按文件大小相似性合併，默認一次固定合併 10 個文件，近似與分層合併。這種合併方式的最大優點是合併高效，可以快速降低文件數；主要問題是數據不連續，會導致查詢時文件剪枝的能力變弱，比如查詢最近一小時的數據，很有可能一小時的文件被分別合併到了幾天前的文件中去了，導致需要遍歷的文件增加了。

為了提升數據連續性、收斂文件數量，提升文件的裁剪能力來提高查詢性能，騰訊雲 ES 實現的文件合併策略主要是按時間序分層合併，每層文件之間按創建時間排序，除了第一層外，都按照時間序和目標大小進行合併，不固定每次合併文件數量，這種策略可以保證合併的高效性。對於少量的未合併的文件以及冷分片文件，採用持續合併的策略，將超過默認五分鐘不再寫入的分片進行持續合併，並控制合併並發和範圍，以降低合併開銷。

通過對合併策略的優化，騰訊雲 ES 將搜索場景的查詢性能提升了 40%，同時帶主鍵的數據寫入性能提升了一倍。

騰訊雲 ES 對業務數據訪問頻率進行調研，發現最近的數據訪問頻率較高，例如最近 5 分鐘的，一小時的，一天的，近幾天的訪問頻率就比較少了，超過一個月的就更少了。

基於這種數據特徵，騰訊雲 ES 通過冷熱分離，把冷數據放到 HDD 來降低成本，同時利用索引生命周期管理來搬遷冷數據，冷數據盤一般比較大，因此還要利用多盤策略來提高吞吐和數據容災能力。最後將超冷的數據冷備到騰訊雲的對象存儲 COS 上，冷備成本非常低。

通過冷熱數據分離，監控數據總體存儲成本下降了將近 10 倍。

通過對線上 Elasticsearch 集群進行分析，發現很多場景下，堆內內存使用率很高，而磁盤的使用率比較低。其中 Elasticsearch 的 FST 即倒排索引占據了絕大部分堆內內存，而且這部分是常駐內存的。每 10 TB 的磁盤 FST 的內存消耗大概在 10 GB 到 15 GB 左右。

為了對 FST 這種堆內占用比較大的內存做優化，騰訊雲 ES 將其移至堆外（off-heap），按需加載，實現更精準的淘汰策略，提高內存使用率，再加上多級 cache 的管理模式來提升性能。通過內存優化，可以提升堆內內存利用率，降低 GC 開銷，提升單個節點管理磁盤的能力。

本文從監控系統整體架構設計、監控系統技術方案落地這兩部分闡述了百億級大數據實時監控系統的建設過程。

首先闡述了監控系統的需求，並根據需求總結出監控系統架構。隨後進行技術選型，分別分析了基於流計算 Oceanus、Elastic Stack 和基於 Zabbix、Prometheus、Grafana 的監控系統技術方案，並選擇基於流計算 Oceanus 和 Elastic stack 構建監控系統。最後針對超大規模監控數據量的場景，介紹騰訊雲流計算 Oceanus 與 Elasticsearch Service 對性能與成本的各種優化策略與手段。總體而言，選擇流計算 Oceanus 與 Elasticsearch Service 能很好地支撐實時監控的需求，並極大地降低用戶成本。

希望本文可以幫助讀者了解監控系統設計思路，對於監控系統建設提供專業指導，快速構建高性能的監控系統。