詳細介紹了監控系統整體架構設計與技術方案落地。基于流計算 Oceanus 與 Elasticsearch Service 可以輕松建構百億級實時監控系統。
作者：龍逸塵，騰訊 CSIG 進階工程師
在後移動網際網路時代，良好的使用者體驗是增長的基礎，穩定的使用體驗就是使用者體驗的基礎。大型的網際網路公司，特别是面向 C 端客戶的公司，對業務系統穩定性的要求越來越高，是以對線上問題發現和處理的速度要求通常是分鐘級的。比如滴滴等出行公司，打車服務停擺 10 分鐘都會導緻導緻乘客、司機大規模投訴，不僅造成經濟損失，而且嚴重平台商譽和使用者口碑。
大型網際網路公司的業務系統都是大規模的分布式系統，各種業務應用和基礎元件（資料庫、緩存、消息隊列等）共同交織成複雜的依賴網絡，任何節點都可能出現故障，導緻系統不可用。是以，業務系統的監控非常重要，通過監控及時發現和幹預問題，避免事故或降低事故影響範圍。
本文将從監控系統整體架構設計、監控系統技術方案落地這兩部分闡述了百億級大資料實時監控系統的建設過程，旨在幫助大家了解監控系統設計思路，對于監控系統建設提供專業指導，快速建構監控系統。
世界上并不存在完全可靠的系統，程式、機器、網絡等都可能在運作中出現故障，進而導緻服務異常。是以監控的目标就是，高效及時地發現、定位系統異常問題，期望縮短異常的平均修複時間，進而降低異常造成的損失。
為了實作縮短異常的平均修複時間這一目标，監控系統應該具有這些能力：
資料采集能力：全面、準确、快速、低損耗地擷取監控日志及資料
資料彙聚能力：将相關資料彙聚起來，友善加工，得到我們需要關注的資料
資料分析與處理能力：對需要關注的資料提供異常名額檢測、故障診斷等分析方法，以及資料過濾、采樣、轉換等處理手段
資料存儲能力：為海量日志與監控名額提供高性能存儲
監控告警能力：指定監控規則，觸發規則後提供電話、郵件、微信、短信等各類告警機制
資料展示能力：提供監控資料與告警的 Dashboard 展示功能，加速問題定位
高可用：整個監控系統需要做到高可用，監控就是為了發現異常，如果由于異常導緻自身不可用，肯定是減分的
根據對監控系統需求的調研，可以将監控系統整體的資料流轉過程抽象為以下幾個階段：采集 -> 彙聚 -> 處理 -> 存儲 -> 分析 -> 展示 -> 告警。
從中我們可以總結出監控系統的一般架構：
從下往上來分析，首先是資料采集層，提供衆多采集手段，包括 Agent 采集、RPC 埋點、HTTP 上報等，可以通過 Agent 采集主控端監控資料和日志，或者 RPC 埋點上報，也可以由使用者直接通過 HTTP 推送進行資料采集。
成功采集到的資料，需要經過統一的資料彙聚層，将相關聯的資料進行彙聚。例如同一業務系統的所有伺服器資料将會彙聚到一個相同的消息隊列中，便于異常檢測。
資料完成彙聚後，将分為三條資料流處理：資料處理、資料分析、資料存儲。
資料處理層：對原始監控資料進行加工，通過資料清洗與轉換将資料格式化，并進行基礎的聚合計算，例如累加計算 10 台伺服器的 ERROR 日志次數；
資料分析層：對标準化後的資料進行關聯分析、異常檢測、故障診斷等，為後續的告警提供判斷依據；
資料存儲層：對日志、名額、時序資料進行存儲，便于 Dashbord 展示，可用于進一步的資料挖掘。
資料流處理完成後，進入監控告警層，對符合監控、告警規則的事件進行告警推送。
資料流最終到達資料展示層，提供常見的使用者互動頁面：如監控面闆、告警面闆等。
提到監控系統方案，大家首先想到的肯定是 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 作為監控面闆。流程如下圖所示：
flink+es
Zabbix 是一款開源的分布式系統監控軟體。它支援可視化配置，提供多種名額采集，支援自定義告警門檻值與多樣的通知機制。Zabbix 靈活的設計為使用者提供了易用的二次開發接口，讓使用者既可以使用 Zabbix 本身提供的功能，又可以自定義更多的監控項功能，如硬體監控、作業系統名額監控、服務程序監控等。
Prometheus 是一款基于 Go 語言開發的監控、告警、存儲套件，它通過 HTTP 協定從遠端的機器收集資料并存儲在本地的時序資料庫上。Prometheus 架構簡單，單個伺服器節點可直接工作，屬于輕量級的 Server。同時不依賴外部存儲，便于遷移和維護，其監控資料直接存儲在 Prometheus Server 本地的時序資料庫中，單個執行個體可以處理數百萬的 Metrics。Prometheus 具有靈活的資料模型和強大的資料查詢語句，可以幫助快速定位和診斷問題，非常适用于面向服務架構的監控。
Grafana 是一個開箱即用的可視化工具，具有功能齊全的度量儀表盤和圖形編輯器，有靈活豐富的圖形化選項，支援配置多種資料源，例如 Elasticsearch、InfluxDB、Prometheus 等。Grafana 可以通過 Datasource 連結 Prometheus url，并對接入的資料進行分組、過濾、聚合等邏輯運算，進而在監控面闆中直覺展示監控名額。
Zabbix、Prometheus 和 Grafana 建構的監控系統部署簡單，功能完善，非常适合容器化環境，但是也存在一定的局限，主要缺點是在超大規模資料量下存在性能瓶頸。
Zabbix 入門容易，能實作基礎的監控，但是深層次需求需要非常熟悉 Zabbix 并進行大量的二次定制開發；
Zabbix 使用 pull 方式采集資料，存在性能瓶頸；
Prometheus 是基于 監控名額（Metric） 的監控，不适用于日志（Logs）、事件（Event）、調用鍊（Tracing）等監控；
Prometheus 目前隻能提供非持久化的資料存儲，無法長期儲存資料；
Prometheus 隻适合單機部署，對于叢集化和水準擴充，官方和社群都沒有銀彈，無法支援海量資料存儲與監控。
Elastic Stack 與流計算 Oceanus 組合，建構了分布式、可拓展、實時化的監控系統，對海量日志和監控資料進行集中管理和實時搜尋、分析，提供名額監控、事件消息和分析報表等簡單易用的功能。性能完善，擴充性強，缺點是部署比較麻煩，資源消耗較高。
Zabbix、Prometheus 和 Grafana 建構的監控系統部署簡單，功能完善，非常适合容器化環境，但是存在緻命缺陷，超大規模監控資料量下無法突破性能瓶頸。
綜上所述，我們最終考慮采用流計算 Oceanus 和 Elastic Stack 建構監控系統。
随着業務量的上漲，監控名額逐漸增多，需要監控的裝置不斷增長，對監控系統的性能要求也日益提升。當資料量增長到百億甚至千億級别，監控系統可能會出現以下問題：
處理性能下降 系統整體處理性能變弱，處理抖動、毛刺情況增多。上遊消息隊列出現大量資料堆積情況，監控延時上升。
資料傾斜 由于業務系統各元件監控資料與日志分布不均勻，導緻資料傾斜，Flink 任務反壓嚴重，各算子的 Checkpoint 時間變長甚至頻繁失敗。部分節點出現 CPU 過載、OOM 的情況。
存儲寫入性能下降 Elasticsearch 寫入時延上漲，存在大面積寫入被拒絕的現象，最終導緻上遊 Flink 任務反壓，甚至任務崩潰。
當系統不穩定或者處理性能下降時，資料延時會上漲至小時甚至天級别，這對于需要盡量做到實時化的監控系統來說是無法接受的。
而面對超大規模監控資料量的場景，騰訊雲流計算 Oceanus 和 Elasticsearch service 進行了大量優化。下面進行詳細介紹。
流計算 Oceanus 是大資料産品生态體系的實時化分析利器，是基于 Apache Flink 建構的具備一站開發、無縫連接配接、亞秒延時、低廉成本、安全穩定等特點的企業級實時大資料分析平台。
流計算 Oceanus 能很好地滿足監控場景下海量實時資料處理的需求。監控系統可以利用 Oceanus 的實時計算能力，使用簡單的 SQL 對監控日志與資料進行實時清洗、轉換與聚合分析。
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 能很好地支撐實時監控的需求，并極大地降低使用者成本。
希望本文可以幫助讀者了解監控系統設計思路，對于監控系統建設提供專業指導，快速建構高性能的監控系統。
流計算 Oceanus & Elasticsearch 服務組合套餐限時放價售賣中↓↓
關注“騰訊雲大資料”公衆号，技術交流、最新活動、服務專享一站Get~