基于流計(jì)算Oceanus和Elasticsearch Service構(gòu)建百億級(jí)實(shí)時(shí)監(jiān)控系統(tǒng)

導(dǎo)語?|?本文將從監(jiān)控系統(tǒng)整體架構(gòu)設(shè)計(jì)、監(jiān)控系統(tǒng)技術(shù)方案落地這兩部分闡述百億級(jí)大數(shù)據(jù)實(shí)時(shí)監(jiān)控系統(tǒng)的建設(shè)過程，旨在幫助大家了解監(jiān)控系統(tǒng)設(shè)計(jì)思路，對(duì)于監(jiān)控系統(tǒng)建設(shè)提供專業(yè)指導(dǎo)，快速構(gòu)建監(jiān)控系統(tǒng)。

在后移動(dòng)互聯(lián)網(wǎng)時(shí)代，良好的用戶體驗(yàn)是增長(zhǎng)的基礎(chǔ)，穩(wěn)定的使用體驗(yàn)就是用戶體驗(yàn)的基礎(chǔ)。大型的互聯(lián)網(wǎng)公司，特別是面向C端客戶的公司，對(duì)業(yè)務(wù)系統(tǒng)穩(wěn)定性的要求越來越高，因此對(duì)線上問題發(fā)現(xiàn)和處理的速度要求通常是分鐘級(jí)的。比如滴滴等出行公司，打車服務(wù)停擺10分鐘都會(huì)導(dǎo)致導(dǎo)致乘客、司機(jī)大規(guī)模投訴，不僅造成經(jīng)濟(jì)損失，而且嚴(yán)重影響平臺(tái)商譽(yù)和用戶口碑。

大型互聯(lián)網(wǎng)公司的業(yè)務(wù)系統(tǒng)都是大規(guī)模的分布式系統(tǒng)，各種業(yè)務(wù)應(yīng)用和基礎(chǔ)組件（數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列等）共同交織成復(fù)雜的依賴網(wǎng)絡(luò)，任何節(jié)點(diǎn)都可能出現(xiàn)故障，導(dǎo)致系統(tǒng)不可用。因此，業(yè)務(wù)系統(tǒng)的監(jiān)控非常重要，通過監(jiān)控及時(shí)發(fā)現(xiàn)和干預(yù)問題，避免事故或降低事故影響范圍。

（一）監(jiān)控系統(tǒng)需求

世界上并不存在完全可靠的系統(tǒng)，程序、機(jī)器、網(wǎng)絡(luò)等都可能在運(yùn)行中出現(xiàn)故障，進(jìn)而導(dǎo)致服務(wù)異常。因此監(jiān)控的目標(biāo)就是，高效及時(shí)地發(fā)現(xiàn)、定位系統(tǒng)異常問題，期望縮短異常的平均修復(fù)時(shí)間，從而降低異常造成的損失。

為了實(shí)現(xiàn)縮短異常的平均修復(fù)時(shí)間這一目標(biāo)，監(jiān)控系統(tǒng)應(yīng)該具有這些能力：

• 數(shù)據(jù)采集能力：全面、準(zhǔn)確、快速、低損耗地獲取監(jiān)控日志及數(shù)據(jù)；

• 數(shù)據(jù)匯聚能力：將相關(guān)數(shù)據(jù)匯聚起來，方便加工，得到我們需要關(guān)注的數(shù)據(jù)；

• 數(shù)據(jù)分析與處理能力：對(duì)需要關(guān)注的數(shù)據(jù)提供異常指標(biāo)檢測(cè)、故障診斷等分析方法，以及數(shù)據(jù)過濾、采樣、轉(zhuǎn)換等處理手段；

• 數(shù)據(jù)存儲(chǔ)能力：為海量日志與監(jiān)控指標(biāo)提供高性能存儲(chǔ)；

• 監(jiān)控告警能力：指定監(jiān)控規(guī)則，觸發(fā)規(guī)則后提供電話、郵件、微信、短信等各類告警機(jī)制；

• 數(shù)據(jù)展示能力：提供監(jiān)控?cái)?shù)據(jù)與告警的 Dashboard 展示功能，加速問題定位；

• 高可用：整個(gè)監(jiān)控系統(tǒng)需要做到高可用，監(jiān)控就是為了發(fā)現(xiàn)異常，如果由于異常導(dǎo)致自身不可用，肯定是減分的。

（二）監(jiān)控系統(tǒng)架構(gòu)

根據(jù)對(duì)監(jiān)控系統(tǒng)需求的調(diào)研，可以將監(jiān)控系統(tǒng)整體的數(shù)據(jù)流轉(zhuǎn)過程抽象為以下幾個(gè)階段：采集->匯聚->處理->存儲(chǔ)->分析->展示->告警。

從中我們可以總結(jié)出監(jiān)控系統(tǒng)的一般架構(gòu)：

從下往上來分析，首先是數(shù)據(jù)采集層，提供眾多采集手段，包括Agent采集、RPC埋點(diǎn)、HTTP上報(bào)等，可以通過Agent采集宿主機(jī)監(jiān)控?cái)?shù)據(jù)和日志，或者RPC埋點(diǎn)上報(bào)，也可以由用戶直接通過HTTP推送進(jìn)行數(shù)據(jù)采集。

成功采集到的數(shù)據(jù)，需要經(jīng)過統(tǒng)一的數(shù)據(jù)匯聚層，將相關(guān)聯(lián)的數(shù)據(jù)進(jìn)行匯聚。例如同一業(yè)務(wù)系統(tǒng)的所有服務(wù)器數(shù)據(jù)將會(huì)匯聚到一個(gè)相同的消息隊(duì)列中，便于異常檢測(cè)。

數(shù)據(jù)完成匯聚后，將分為三條數(shù)據(jù)流處理：數(shù)據(jù)處理、數(shù)據(jù)分析、數(shù)據(jù)存儲(chǔ)。

• 數(shù)據(jù)處理層：對(duì)原始監(jiān)控?cái)?shù)據(jù)進(jìn)行加工，通過數(shù)據(jù)清洗與轉(zhuǎn)換將數(shù)據(jù)格式化，并進(jìn)行基礎(chǔ)的聚合計(jì)算，例如累加計(jì)算10臺(tái)服務(wù)器的ERROR日志次數(shù)；

• 數(shù)據(jù)分析層：對(duì)標(biāo)準(zhǔn)化后的數(shù)據(jù)進(jìn)行關(guān)聯(lián)分析、異常檢測(cè)、故障診斷等，為后續(xù)的告警提供判斷依據(jù)；

• 數(shù)據(jù)存儲(chǔ)層：對(duì)日志、指標(biāo)、時(shí)序數(shù)據(jù)進(jìn)行存儲(chǔ)，便于Dashbord展示，可用于進(jìn)一步的數(shù)據(jù)挖掘。

數(shù)據(jù)流處理完成后，進(jìn)入監(jiān)控告警層，對(duì)符合監(jiān)控、告警規(guī)則的事件進(jìn)行告警推送。

數(shù)據(jù)流最終到達(dá)數(shù)據(jù)展示層，提供常見的用戶交互頁(yè)面：如監(jiān)控面板、告警面板等。

（一）技術(shù)選型

方案1: 流計(jì)算Oceanus+Elastic Stack

提到監(jiān)控系統(tǒng)方案，大家首先想到的肯定是Elastic Stack（Elasticsearch、Logstash、Kibana、Beats），其活躍的社區(qū)、簡(jiǎn)單的安裝流程、便捷的使用方式等優(yōu)勢(shì)吸引了大量用戶，當(dāng)前許多互聯(lián)網(wǎng)公司的監(jiān)控系統(tǒng)架構(gòu)都是基于開源Elastic stack搭建的。

Elastic Stack由Elasticsearch、Logstash、Kibana和Beats組成。下面分別對(duì)各個(gè)組件進(jìn)行簡(jiǎn)單的介紹。

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

Logstash是一款日志聚合器，它可以從各種輸入源動(dòng)態(tài)采集監(jiān)控日志和數(shù)據(jù)，對(duì)其進(jìn)行轉(zhuǎn)換后，將數(shù)據(jù)傳送到各種支持的輸出目的地。許多用戶將轉(zhuǎn)換后的數(shù)據(jù)發(fā)送到Elasticsearch，在其中對(duì)日志、監(jiān)控?cái)?shù)據(jù)進(jìn)行索引與搜索。

Kibana是工作在Elasticsearch之上的可視化層，為用戶提供數(shù)據(jù)分析和可視化的能力，可將存儲(chǔ)在Elasticsearch中的數(shù)據(jù)轉(zhuǎn)換為易于使用的圖表、圖形、直方圖和其他可視化表示，進(jìn)而深入挖掘數(shù)據(jù)特征。

Beats是一款輕量級(jí)日志采集器，目前Beats包含多種工具：Metricbeat、Filebeat、Heartbeat等。每個(gè)Beat都有一個(gè)簡(jiǎn)單的任務(wù)：采集日志或數(shù)據(jù)并發(fā)送到輸出目的地。

早期的ELK Stack使用Logstash收集并解析日志，但是Logstash本身是基于jdk的，而且它集成了許多插件，對(duì)內(nèi)存、CPU、IO等資源消耗比較高。相比于Logstash，Beats所占系統(tǒng)的CPU和內(nèi)存幾乎可以忽略不計(jì)，因此考慮使用輕量級(jí)的Beats組件來完成日志和監(jiān)控?cái)?shù)據(jù)的采集操作。架構(gòu)如下：

Elastic Stack運(yùn)行于分布式系統(tǒng)之上，為用戶提供了一個(gè)性能強(qiáng)大的平臺(tái)，該平臺(tái)通過采集、過濾、傳輸、儲(chǔ)存，對(duì)海量日志和監(jiān)控?cái)?shù)據(jù)進(jìn)行集中管理和準(zhǔn)實(shí)時(shí)搜索、分析，提供準(zhǔn)實(shí)時(shí)搜索、監(jiān)控、事件消息和分析報(bào)表等簡(jiǎn)單易用的功能，幫助運(yùn)維人員進(jìn)行線上業(yè)務(wù)的實(shí)時(shí)監(jiān)控，業(yè)務(wù)異常時(shí)及時(shí)定位原因、排除故障，深度挖掘日志的大數(shù)據(jù)價(jià)值。

但是Elastic Stack也存在一些不足。首先Beats只有采集日志與監(jiān)控?cái)?shù)據(jù)的功能，無法對(duì)數(shù)據(jù)進(jìn)行處理；另外Logstash的數(shù)據(jù)處理功能很弱，無法滿足復(fù)雜的數(shù)據(jù)處理需求，且不支持監(jiān)控?cái)?shù)據(jù)緩存，存在數(shù)據(jù)丟失的隱患。

綜上所述，在將監(jiān)控?cái)?shù)據(jù)與日志信息保存到Elasticsearch之前，需要引入消息隊(duì)列緩存數(shù)據(jù)，并使用大數(shù)據(jù)實(shí)時(shí)計(jì)算引擎對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)的過濾、轉(zhuǎn)換、聚合。

而騰訊云流計(jì)算Oceanus恰好可以實(shí)現(xiàn)這些功能。流計(jì)算Oceanus是大數(shù)據(jù)產(chǎn)品生態(tài)體系的實(shí)時(shí)化分析利器，是基于Apache Flink構(gòu)建的具備一站開發(fā)、無縫連接、亞秒延時(shí)、低廉成本、安全穩(wěn)定等特點(diǎn)的企業(yè)級(jí)實(shí)時(shí)大數(shù)據(jù)分析平臺(tái)。流計(jì)算Oceanus能很好地滿足監(jiān)控場(chǎng)景下海量實(shí)時(shí)數(shù)據(jù)處理的需求，監(jiān)控系統(tǒng)可以利用Oceanus的實(shí)時(shí)計(jì)算能力，對(duì)監(jiān)控日志與數(shù)據(jù)進(jìn)行清洗、轉(zhuǎn)換并完成聚合分析，實(shí)時(shí)計(jì)算的結(jié)果可以直接用于監(jiān)控告警展示，極大地提升了運(yùn)維人員在故障發(fā)生時(shí)的決策能力。

使用Elastic Stack還需要關(guān)注的點(diǎn)是監(jiān)控面板。Kibana的長(zhǎng)處在于日志分析，且僅適用于Elasticsearch，不支持任何其他類型的數(shù)據(jù)源；它的面板展示能力還有提高的空間，而且具有陡峭的學(xué)習(xí)曲線，對(duì)于非技術(shù)業(yè)務(wù)用戶來說很難上手。因此可以考慮使用其他的數(shù)據(jù)可視化工具代替Kibana作為監(jiān)控面板，讓Kibana專注于日志分析。綜合對(duì)比現(xiàn)有的可視化工具后，我們選擇使用Grafana。

在實(shí)際應(yīng)用場(chǎng)景中，可以使用Beats采集日志與監(jiān)控?cái)?shù)據(jù)，將Kafka作為Beats的輸出端。Kafka實(shí)時(shí)接收到Beats采集的數(shù)據(jù)后，使用流計(jì)算 Oceanus（Flink）進(jìn)行實(shí)時(shí)處理與聚合，將滿足需求的數(shù)據(jù)輸出到Elasticsearch中進(jìn)行分布式檢索，通過Kibana進(jìn)行日志分析，最后采用Grafana作為監(jiān)控面板。流程如下圖所示：

方案2: Zabbix+Prometheus+Grafana

Zabbix是一款開源的分布式系統(tǒng)監(jiān)控軟件。它支持可視化配置，提供多種指標(biāo)采集，支持自定義告警閾值與多樣的通知機(jī)制。Zabbix靈活的設(shè)計(jì)為用戶提供了易用的二次開發(fā)接口，讓用戶既可以使用Zabbix本身提供的功能，又可以自定義更多的監(jiān)控項(xiàng)功能，如硬件監(jiān)控、操作系統(tǒng)指標(biāo)監(jiān)控、服務(wù)進(jìn)程監(jiān)控等。

Prometheus是一款基于Go語言開發(fā)的監(jiān)控、告警、存儲(chǔ)套件，它通過HTTP協(xié)議從遠(yuǎn)程的機(jī)器收集數(shù)據(jù)并存儲(chǔ)在本地的時(shí)序數(shù)據(jù)庫(kù)上。Prometheus架構(gòu)簡(jiǎn)單，單個(gè)服務(wù)器節(jié)點(diǎn)可直接工作，屬于輕量級(jí)的 Server。同時(shí)不依賴外部存儲(chǔ)，便于遷移和維護(hù)，其監(jiān)控?cái)?shù)據(jù)直接存儲(chǔ)在 Prometheus Server本地的時(shí)序數(shù)據(jù)庫(kù)中，單個(gè)實(shí)例可以處理數(shù)百萬的 Metrics。Prometheus 具有靈活的數(shù)據(jù)模型和強(qiáng)大的數(shù)據(jù)查詢語句，可以幫助快速定位和診斷問題，非常適用于面向服務(wù)架構(gòu)的監(jiān)控。

Grafana是一個(gè)開箱即用的可視化工具，具有功能齊全的度量?jī)x表盤和圖形編輯器，有靈活豐富的圖形化選項(xiàng)，支持配置多種數(shù)據(jù)源，例如Elasticsearch、InfluxDB、Prometheus等。Grafana可以通過Datasource鏈接Prometheus url，并對(duì)接入的數(shù)據(jù)進(jìn)行分組、過濾、聚合等邏輯運(yùn)算，從而在監(jiān)控面板中直觀展示監(jiān)控指標(biāo)。

Zabbix、Prometheus和Grafana構(gòu)建的監(jiān)控系統(tǒng)部署簡(jiǎn)單，功能完善，非常適合容器化環(huán)境，但是也存在一定的局限，主要缺點(diǎn)是在超大規(guī)模數(shù)據(jù)量下存在性能瓶頸。

• Zabbix入門容易，能實(shí)現(xiàn)基礎(chǔ)的監(jiān)控，但是深層次需求需要非常熟悉 Zabbix并進(jìn)行大量的二次定制開發(fā)；

• Zabbix使用pull方式采集數(shù)據(jù)，存在性能瓶頸；

• Prometheus是基于監(jiān)控指標(biāo)（Metric）的監(jiān)控，不適用于日志（Logs）、事件（Event）、調(diào)用鏈（Tracing）等監(jiān)控；

• Prometheus目前只能提供非持久化的數(shù)據(jù)存儲(chǔ)，無法長(zhǎng)期保存數(shù)據(jù)；

• Prometheus只適合單機(jī)部署，對(duì)于集群化和水平擴(kuò)展，官方和社區(qū)都沒有銀彈，無法支持海量數(shù)據(jù)存儲(chǔ)與監(jiān)控。

選型總結(jié)

Elastic Stack與流計(jì)算Oceanus組合，構(gòu)建了分布式、可拓展、實(shí)時(shí)化的監(jiān)控系統(tǒng)，對(duì)海量日志和監(jiān)控?cái)?shù)據(jù)進(jìn)行集中管理和實(shí)時(shí)搜索、分析，提供指標(biāo)監(jiān)控、事件消息和分析報(bào)表等簡(jiǎn)單易用的功能。性能完善，擴(kuò)展性強(qiáng)，缺點(diǎn)是部署比較麻煩，資源消耗較高。

Zabbix、Prometheus和Grafana構(gòu)建的監(jiān)控系統(tǒng)部署簡(jiǎn)單，功能完善，非常適合容器化環(huán)境，但是存在致命缺陷，超大規(guī)模監(jiān)控?cái)?shù)據(jù)量下無法突破性能瓶頸。

綜上所述，我們最終考慮采用流計(jì)算Oceanus和Elastic Stack構(gòu)建監(jiān)控系統(tǒng)。

（二）系統(tǒng)優(yōu)化

隨著業(yè)務(wù)量的上漲，監(jiān)控指標(biāo)逐漸增多，需要監(jiān)控的設(shè)備不斷增長(zhǎng)，對(duì)監(jiān)控系統(tǒng)的性能要求也日益提升。當(dāng)數(shù)據(jù)量增長(zhǎng)到百億甚至千億級(jí)別，監(jiān)控系統(tǒng)可能會(huì)出現(xiàn)以下問題：

• 處理性能下降，系統(tǒng)整體處理性能變?nèi)?，處理抖?dòng)、毛刺情況增多。上游消息隊(duì)列出現(xiàn)大量數(shù)據(jù)堆積情況，監(jiān)控延時(shí)上升；

• 數(shù)據(jù)傾斜，由于業(yè)務(wù)系統(tǒng)各組件監(jiān)控?cái)?shù)據(jù)與日志分布不均勻，導(dǎo)致數(shù)據(jù)傾斜，F(xiàn)link任務(wù)反壓嚴(yán)重，各算子的Checkpoint時(shí)間變長(zhǎng)甚至頻繁失敗。部分節(jié)點(diǎn)出現(xiàn)CPU過載、OOM的情況；

• 存儲(chǔ)寫入性能下降，Elasticsearch寫入時(shí)延上漲，存在大面積寫入被拒絕的現(xiàn)象，最終導(dǎo)致上游Flink任務(wù)反壓，甚至任務(wù)崩潰。

當(dāng)系統(tǒng)不穩(wěn)定或者處理性能下降時(shí)，數(shù)據(jù)延時(shí)會(huì)上漲至小時(shí)甚至天級(jí)別，這對(duì)于需要盡量做到實(shí)時(shí)化的監(jiān)控系統(tǒng)來說是無法接受的。

而面對(duì)超大規(guī)模監(jiān)控?cái)?shù)據(jù)量的場(chǎng)景，騰訊云流計(jì)算Oceanus和Elasticsearch service進(jìn)行了大量?jī)?yōu)化。下面進(jìn)行詳細(xì)介紹。

• 流計(jì)算Oceanus

流計(jì)算Oceanus是大數(shù)據(jù)產(chǎn)品生態(tài)體系的實(shí)時(shí)化分析利器，是基于Apache Flink構(gòu)建的具備一站開發(fā)、無縫連接、亞秒延時(shí)、低廉成本、安全穩(wěn)定等特點(diǎn)的企業(yè)級(jí)實(shí)時(shí)大數(shù)據(jù)分析平臺(tái)。

流計(jì)算Oceanus能很好地滿足監(jiān)控場(chǎng)景下海量實(shí)時(shí)數(shù)據(jù)處理的需求。監(jiān)控系統(tǒng)可以利用Oceanus的實(shí)時(shí)計(jì)算能力，使用簡(jiǎn)單的SQL對(duì)監(jiān)控日志與數(shù)據(jù)進(jìn)行實(shí)時(shí)清洗、轉(zhuǎn)換與聚合分析。

• SQL性能優(yōu)化

流計(jì)算Oceanus對(duì)原生Flink SQL進(jìn)行了大量?jī)?yōu)化，提升超大規(guī)模數(shù)據(jù)量下作業(yè)的處理性能。

數(shù)據(jù)傾斜是導(dǎo)致Flink作業(yè)性能問題的常見原因。數(shù)據(jù)傾斜指的是數(shù)據(jù)分布嚴(yán)重不均衡，過多數(shù)據(jù)集中在某些task上，導(dǎo)致內(nèi)存緊張，頻繁GC；而頻繁的 GC導(dǎo)致系統(tǒng)吞吐下降，數(shù)據(jù)延遲，嚴(yán)重情況下還可能導(dǎo)致TaskManager失聯(lián)，任務(wù)崩潰。

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

Flink SQL下還存在UDF函數(shù)復(fù)用的問題。如果相同的UDF在SQL中出現(xiàn)多次，例如簡(jiǎn)單的JSON解析、URL解析等，原生的Flink SQL會(huì)多次執(zhí)行，影響性能。

針對(duì)UDF函數(shù)復(fù)用問題，流計(jì)算Oceanus將邏輯執(zhí)行計(jì)劃中重復(fù)調(diào)用的UDF提取出來，并對(duì)UDF的執(zhí)行結(jié)果進(jìn)行緩存，避免多次調(diào)用。

流表維表Join中存在數(shù)據(jù)冷啟動(dòng)問題，如果將維表數(shù)據(jù)加載到所有的subtask里面會(huì)造成較大的內(nèi)存消耗，而且很容易造成反壓。

流計(jì)算Oceanus的解決方案是，在維表的DDL中指定Bucket信息，流與維表進(jìn)行Join的時(shí)候會(huì)基于Bucket信息去加載維表中對(duì)應(yīng)分片的數(shù)據(jù)，同時(shí)在翻譯執(zhí)行計(jì)劃的時(shí)候流表拿到Bucket信息，以保證流與維表的數(shù)據(jù)都會(huì)基于同一個(gè)Bucket信息進(jìn)行Join。這種處理方案能大大減少全量維表數(shù)據(jù)預(yù)加載帶來的內(nèi)存消耗與反壓?jiǎn)栴}。

• 作業(yè)智能診斷與監(jiān)控

流計(jì)算Oceanus為作業(yè)異常重啟、Snapshot失敗、以及JobManager/TaskManager的CPU、內(nèi)存異常等各類運(yùn)行狀態(tài)的事件提供可視化的提示。

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

此外，流計(jì)算Oceanus還以Task粒度定義動(dòng)態(tài)指標(biāo)，并以維度聚合（sum、max、min、avg）的方式定義從上下游系統(tǒng)到集群作業(yè)的健康運(yùn)行相關(guān)的65+項(xiàng)監(jiān)控指標(biāo)，對(duì)作業(yè)進(jìn)行全方位監(jiān)控告警。

流計(jì)算Oceanus提供作業(yè)運(yùn)行事件可視化、作業(yè)智能診斷與全方位監(jiān)控告警等功能，為用戶的實(shí)時(shí)計(jì)算作業(yè)保駕護(hù)航。

• 作業(yè)自動(dòng)擴(kuò)縮容

流計(jì)算Oceanus提供作業(yè)自動(dòng)擴(kuò)縮容功能，根據(jù)CPU、內(nèi)存、反壓狀況等業(yè)務(wù)負(fù)載情況，自動(dòng)進(jìn)行作業(yè)并行度的調(diào)整，完成作業(yè)擴(kuò)縮容。

當(dāng)遇到數(shù)據(jù)傾斜、作業(yè)負(fù)載過高等事件時(shí)，流計(jì)算Oceanus會(huì)自動(dòng)調(diào)整作業(yè)并行度，增加作業(yè)運(yùn)行資源，從而避免數(shù)據(jù)傾斜，降低作業(yè)負(fù)載，保障作業(yè)穩(wěn)定運(yùn)行。而在業(yè)務(wù)低谷期流計(jì)算Oceanus會(huì)自動(dòng)縮減作業(yè)計(jì)算資源，減少資源浪費(fèi)。

作業(yè)自動(dòng)擴(kuò)縮容功能在保障業(yè)務(wù)時(shí)效性的同時(shí)，避免了資源浪費(fèi)，可以為用戶降低可觀的成本。

• 騰訊云 Elasticsearch Service

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

• 寫入耗時(shí)過大，大量寫入被拒絕；

• 部分索引查詢性能慢；

• 存儲(chǔ)成本急劇增加；

• 堆內(nèi)存使用過大。

Elasticsearch的使用姿勢(shì)、參數(shù)調(diào)優(yōu)等在社區(qū)有很多的案例和經(jīng)驗(yàn)可以借鑒，但是百億級(jí)實(shí)時(shí)監(jiān)控場(chǎng)景下，很多的痛點(diǎn)和挑戰(zhàn)是無法通過簡(jiǎn)單的調(diào)優(yōu)來解決的。

騰訊云Elasticsearch Service（ES）是基于開源搜索引擎Elasticsearch打造的高可用、可伸縮的云端全托管的Elasticsearch服務(wù)，包含Beats、Kibana及常用插件，并集成了安全、SQL、機(jī)器學(xué)習(xí)、告警、監(jiān)控等高級(jí)特性（X-Pack）。為了應(yīng)對(duì)上述的困難，騰訊云ES從內(nèi)核層面做了深度的優(yōu)化。

• 存儲(chǔ)模型優(yōu)化

Elasticsearch底層的Lucene是基于LSM Tree的數(shù)據(jù)文件，原生默認(rèn)的合并策略是按文件大小相似性合并，默認(rèn)一次固定合并10個(gè)文件，近似與分層合并。這種合并方式的最大優(yōu)點(diǎn)是合并高效，可以快速降低文件數(shù)；主要問題是數(shù)據(jù)不連續(xù)，會(huì)導(dǎo)致查詢時(shí)文件剪枝的能力變?nèi)?，比如查詢最近一小時(shí)的數(shù)據(jù)，很有可能一小時(shí)的文件被分別合并到了幾天前的文件中去了，導(dǎo)致需要遍歷的文件增加了。

為了提升數(shù)據(jù)連續(xù)性、收斂文件數(shù)量，提升文件的裁剪能力來提高查詢性能，騰訊云ES實(shí)現(xiàn)的文件合并策略主要是按時(shí)間序分層合并，每層文件之間按創(chuàng)建時(shí)間排序，除了第一層外，都按照時(shí)間序和目標(biāo)大小進(jìn)行合并，不固定每次合并文件數(shù)量，這種策略可以保證合并的高效性。對(duì)于少量的未合并的文件以及冷分片文件，采用持續(xù)合并的策略，將超過默認(rèn)五分鐘不再寫入的分片進(jìn)行持續(xù)合并，并控制合并并發(fā)和范圍，以降低合并開銷。

通過對(duì)合并策略的優(yōu)化，騰訊云ES將搜索場(chǎng)景的查詢性能提升了40%，同時(shí)帶主鍵的數(shù)據(jù)寫入性能提升了一倍。

• 成本優(yōu)化

騰訊云ES對(duì)業(yè)務(wù)數(shù)據(jù)訪問頻率進(jìn)行調(diào)研，發(fā)現(xiàn)最近的數(shù)據(jù)訪問頻率較高，例如最近5分鐘的，一小時(shí)的，一天的，近幾天的訪問頻率就比較少了，超過一個(gè)月的就更少了。

基于這種數(shù)據(jù)特征，騰訊云ES通過冷熱分離，把冷數(shù)據(jù)放到HDD來降低成本，同時(shí)利用索引生命周期管理來搬遷冷數(shù)據(jù)，冷數(shù)據(jù)盤一般比較大，因此還要利用多盤策略來提高吞吐和數(shù)據(jù)容災(zāi)能力。最后將超冷的數(shù)據(jù)冷備到騰訊云的對(duì)象存儲(chǔ)COS上，冷備成本非常低。

通過冷熱數(shù)據(jù)分離，監(jiān)控?cái)?shù)據(jù)總體存儲(chǔ)成本下降了將近10倍。

• 內(nèi)存優(yōu)化

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

為了對(duì)FST這種堆內(nèi)占用比較大的內(nèi)存做優(yōu)化，騰訊云ES將其移至堆外（off-heap），按需加載，實(shí)現(xiàn)更精準(zhǔn)的淘汰策略，提高內(nèi)存使用率，再加上多級(jí)cache的管理模式來提升性能。通過內(nèi)存優(yōu)化，可以提升堆內(nèi)內(nèi)存利用率，降低GC開銷，提升單個(gè)節(jié)點(diǎn)管理磁盤的能力。

本文從監(jiān)控系統(tǒng)整體架構(gòu)設(shè)計(jì)、監(jiān)控系統(tǒng)技術(shù)方案落地這兩部分闡述了百億級(jí)大數(shù)據(jù)實(shí)時(shí)監(jiān)控系統(tǒng)的建設(shè)過程。

首先闡述了監(jiān)控系統(tǒng)的需求，并根據(jù)需求總結(jié)出監(jiān)控系統(tǒng)架構(gòu)。隨后進(jìn)行技術(shù)選型，分別分析了基于流計(jì)算Oceanus、Elastic Stack和基于Zabbix、Prometheus、Grafana的監(jiān)控系統(tǒng)技術(shù)方案，并選擇基于流計(jì)算Oceanus和Elastic stack構(gòu)建監(jiān)控系統(tǒng)。最后針對(duì)超大規(guī)模監(jiān)控?cái)?shù)據(jù)量的場(chǎng)景，介紹騰訊云流計(jì)算Oceanus與Elasticsearch Service對(duì)性能與成本的各種優(yōu)化策略與手段?？傮w而言，選擇流計(jì)算Oceanus與Elasticsearch Service能很好地支撐實(shí)時(shí)監(jiān)控的需求，并極大地降低用戶成本。

希望本文可以幫助讀者了解監(jiān)控系統(tǒng)設(shè)計(jì)思路，對(duì)于監(jiān)控系統(tǒng)建設(shè)提供專業(yè)指導(dǎo)，快速構(gòu)建高性能的監(jiān)控系統(tǒng)。

（作者：龍逸塵，騰訊CSIG高級(jí)工程師）

??戳「閱讀原文」一鍵了解騰訊云大數(shù)據(jù)更多信息~