一、背景概述

框架Dashboard是一款攜程內(nèi)部歷史悠久的自研監(jiān)控產(chǎn)品，其定位是企業(yè)級(jí)Metrics監(jiān)控場(chǎng)景，主要提供用戶自定義Metrics接入，并基于此提供實(shí)時(shí)數(shù)據(jù)分析和視圖展現(xiàn)的面板服務(wù)，提供可定制的基于時(shí)間序列的各類系統(tǒng)級(jí)性能數(shù)據(jù)和業(yè)務(wù)指標(biāo)數(shù)據(jù)的看板。還可以提供靈活的數(shù)據(jù)收集接口、分布式的大容量存儲(chǔ)和靈活的展現(xiàn)方式。

由于時(shí)間較早，那時(shí)候業(yè)界還沒(méi)有像樣的TSDB產(chǎn)品，類似Prometheus，InfluxDB都是后起之秀，所以Dashboard選型主要使用了HBase來(lái)存儲(chǔ)Metrics數(shù)據(jù)。并且基于HBase來(lái)實(shí)現(xiàn)了TSDB，解決了一些HBase熱點(diǎn)問(wèn)題，同時(shí)將部分查詢聚合下放到HBase，目的是優(yōu)化其查詢性能，目前看來(lái)總體方案依賴HBase/HDFS還是有點(diǎn)重。

近些年，隨著攜程監(jiān)控All-in-One產(chǎn)品的提出。對(duì)于內(nèi)部的Metrics存儲(chǔ)統(tǒng)一也提出了新的要求。由于Dashboard查詢目前存在的諸多問(wèn)題以及Metrics統(tǒng)一的目標(biāo)，我們決定替換升級(jí)Dashboard現(xiàn)有的HBase存儲(chǔ)方案，并且在Metrics場(chǎng)景提供統(tǒng)一的查詢層API。

二、整體架構(gòu)

Dashboard產(chǎn)品主要分了6個(gè)組件，包括dashboard-engine，dashboard-gateway，dashboard-writer，dashboard-HBase存儲(chǔ)，dashboard-collector，dashboard-agent。目前實(shí)時(shí)寫(xiě)入數(shù)據(jù)行數(shù)6億條/分鐘，架構(gòu)圖如下：

• dashboard-engine是查詢引擎。
• dashboard-gateway是提供給用戶的查詢界面。
• dashboard-writer是數(shù)據(jù)寫(xiě)入HBase的組件。
• dashboard-collector是基于Netty實(shí)現(xiàn)的Metrics數(shù)據(jù)收集的服務(wù)端。
• dashboard-agent是用戶打點(diǎn)的客戶端，支持sum，avg，max，min這幾種聚合方式。
• dashboard-HBase是基于HBase實(shí)現(xiàn)的Metrics存儲(chǔ)組件。

產(chǎn)品主要特性如下：?

• 支持存儲(chǔ)精確到分鐘級(jí)的基于時(shí)間序列的數(shù)據(jù)。
• 單個(gè)指標(biāo)數(shù)據(jù)可支持多個(gè)tag。
• 展現(xiàn)提供任意形式的視圖同時(shí)可靈活基于tag進(jìn)行分組。

三、目前的存在問(wèn)題

基于HBase的Metrics存儲(chǔ)方案雖然具有良好的擴(kuò)展性，比較高的吞吐，但是隨著時(shí)間發(fā)展，已經(jīng)不是最優(yōu)的TSDB方案了，可以歸納總結(jié)為如下幾個(gè)痛點(diǎn)。

• 在TSDB場(chǎng)景查詢慢，整體表現(xiàn)不如專業(yè)的TSDB。
• HBase熱點(diǎn)問(wèn)題，容易影響數(shù)據(jù)寫(xiě)入。
• HBase技術(shù)棧運(yùn)維操作很重。
• 采用自研協(xié)議，不支持業(yè)界標(biāo)準(zhǔn)的Prometheus協(xié)議，無(wú)法和內(nèi)部All-in-one監(jiān)控產(chǎn)品較好的融合。

四、替換難點(diǎn)

• 系統(tǒng)寫(xiě)入數(shù)據(jù)量大，6億條/分鐘。
•  Dashboard數(shù)據(jù)缺乏治理，很多不合理高維的metrics數(shù)據(jù)，日志型數(shù)據(jù)，經(jīng)過(guò)統(tǒng)計(jì)，整體基數(shù)達(dá)上千億，這對(duì)TSDB不友好，這部分需要寫(xiě)入程序做治理。如圖2所示是top20基數(shù)統(tǒng)計(jì)，有很多Metric基數(shù)已經(jīng)上億。
• Dashboard系統(tǒng)存在時(shí)間久，內(nèi)部有很多程序調(diào)用，替換需要做到對(duì)用戶透明。

五、替換升級(jí)方案

從上面的架構(gòu)來(lái)看，目前我們替換的主要是dashboard-writer和dashboard-HBase這兩個(gè)最核心的組件。為了對(duì)用戶的平滑遷移，其他組件稍作改動(dòng)，在dashboard-engine組件上對(duì)接新的查詢API即可替換升級(jí)成功。對(duì)于用戶側(cè)，查詢的界面dashboard-gateway和打點(diǎn)的客戶端dashboard-agent還是原有的模式不變，因此整個(gè)的替換方案對(duì)用戶透明。具體如下：

1、dashboard-HBase升級(jí)為dashboard-vm

存儲(chǔ)從HBase方案替換成VictoriaMetrics+ClickHouse混合存儲(chǔ)方案：?

• VictoriaMetrics是兼容主流Prometheus協(xié)議的TSDB，在TSDB場(chǎng)景下查詢效果好，所以會(huì)接入絕大多數(shù)TSDB數(shù)據(jù)。
• 基于ClickHouse提供元數(shù)據(jù)服務(wù)，主要為界面的adhoc查詢服務(wù)，原來(lái)這部分元數(shù)據(jù)是存儲(chǔ)在HBase里面，新的方案采用ClickHouse來(lái)存儲(chǔ)。元數(shù)據(jù)主要存儲(chǔ)了measurement列表，measurement-tagKey列表，measurement-tagKey-tagValue列表這三種結(jié)構(gòu)，目前在ClickHouse創(chuàng)建了一張表來(lái)存這些元數(shù)據(jù)。

本地表結(jié)構(gòu)為：

CREATE TABLE hickwall.downsample_mtv
(`timestamp` DateTime,
`metricName` String,
`tagKey` String,
`tagValue` String,
`datasourceId` UInt8 DEFAULT 40)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/hickwall_cluster-{shard}/downsample_mtv', '{replica}')
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp, metricName, tagKey)
TTL timestamp + toIntervalDay(7)
SETTINGS index_granularity = 8192

?分布式表結(jié)構(gòu)為：

CREATE TABLE hickwall.downsample_mtv__dt 
(`timestamp` DateTime,
 `metricName` String,
 `tagKey` String,
 `tagValue` String,
 `datasourceId` UInt8 DEFAULT 40) 
ENGINE = Distributed(hickwall_cluster, hickwall, downsample_mtv, rand())

• ClickHouse存儲(chǔ)少量日志型的數(shù)據(jù)

由于長(zhǎng)期缺乏一些治理，Dashboard還存儲(chǔ)了一些日志型數(shù)據(jù)，這類數(shù)據(jù)是一些基數(shù)很大但數(shù)據(jù)量少的數(shù)據(jù)，不適合存儲(chǔ)在VictoriaMetrics。為了實(shí)現(xiàn)所有數(shù)據(jù)透明遷移，這部分?jǐn)?shù)據(jù)經(jīng)過(guò)評(píng)估，通過(guò)白名單配置的方式接入ClickHouse來(lái)存儲(chǔ)，需要針對(duì)每一個(gè)接入的日志型指標(biāo)來(lái)創(chuàng)建表和字段。目前的做法是按照BU維度來(lái)建表，并且針對(duì)指標(biāo)tag來(lái)創(chuàng)建字段，考慮到接入的日志型指標(biāo)數(shù)量少，所以表的字段數(shù)量會(huì)相對(duì)可控。用機(jī)票FLT的表結(jié)構(gòu)舉例如下圖。

2、Dashboard-writer升級(jí)為Dashboard-vmwriter

Dashboard-collector會(huì)分流全量的數(shù)據(jù)到Kafka，Dashboard-vmwriter的工作流程大致是消費(fèi)Kafka->數(shù)據(jù)處理->數(shù)據(jù)寫(xiě)入存儲(chǔ)。Dashboard-vmwriter主要實(shí)現(xiàn)了以下幾個(gè)核心的功能：

• Metrics元數(shù)據(jù)抽取功能，負(fù)責(zé)抽取出measurement，tagKey，tagValue寫(xiě)入ClickHouse的mtv本地表。這塊元數(shù)據(jù)存儲(chǔ)主要依賴了Redis（用于實(shí)時(shí)寫(xiě)入）和ClickHouse（用于查詢）。
• 指標(biāo)預(yù)聚合功能，用于加速查詢。對(duì)接公司內(nèi)部的配置中心來(lái)下發(fā)預(yù)聚合的配置，配置格式如下。

下面的配置會(huì)生成ClusterName和appid這兩個(gè)維度組合的credis預(yù)聚合指標(biāo)。

 {
        "metricName": "credis.java.latency",
        "tagNames": [
            "ClusterName",
            "appid"
        ]
}

?配置下發(fā)后，Dashboard-vmwriter會(huì)自動(dòng)聚合一份預(yù)聚合指標(biāo)存入VictoriaMetrics，指標(biāo)命名規(guī)則為hi_agg.{measurement}_{tag1}_{tag2}_{聚合field}。同樣的，查詢層API會(huì)讀取同樣的預(yù)聚合配置來(lái)決定查詢預(yù)聚合的指標(biāo)還是原始的指標(biāo)，默認(rèn)為所有的measurement維度都開(kāi)啟了一份預(yù)聚合的配置，因?yàn)樵赥SDB實(shí)現(xiàn)中，查一個(gè)measurement的數(shù)據(jù)會(huì)掃描所有的timeseries，查詢開(kāi)銷很大，所以這部分直接去查預(yù)聚合好的measurement比較合理。

• 數(shù)據(jù)治理：異常數(shù)據(jù)自動(dòng)檢測(cè)及封禁，目前主要涉及以下方面：

1）基于HyperLogLog的算法來(lái)統(tǒng)計(jì)measurement級(jí)別的基數(shù)，如果measurement的基數(shù)超級(jí)大，比如超過(guò)500萬(wàn)，那么就會(huì)丟棄一些tag維度。

2）基于Redis和內(nèi)存cache來(lái)統(tǒng)計(jì)measurement-tagKey-tagValue的基數(shù)，如果某個(gè)tagValue增長(zhǎng)過(guò)快，那么就丟棄這個(gè)tag的維度，并且記錄下丟棄這種埋點(diǎn)。Redis主要使用了set集合，key的命名是{measurement}_{tagKey}，成員是[tagValue1，tagValue2，… , tagValueN]，主要是通過(guò)sismember來(lái)判斷成員是否存在，sadd來(lái)添加成員，scard判斷key的成員數(shù)量。

寫(xiě)入程序會(huì)先在本地內(nèi)存Cache查找Key的成員是否存在，沒(méi)有的話會(huì)去Redis查找，對(duì)Redis的qps是可控的，本地Cache是基于LRU的淘汰策略，本地內(nèi)存可控。整個(gè)過(guò)程是在寫(xiě)入的時(shí)候?qū)崟r(shí)進(jìn)行的，也能保證數(shù)據(jù)的及時(shí)性和高性能，寫(xiě)入Redis的元數(shù)據(jù)也會(huì)實(shí)時(shí)增量同步到ClickHouse的mtv表，這樣用戶界面也能實(shí)時(shí)查詢到元數(shù)據(jù)。

3）數(shù)據(jù)高性能寫(xiě)入，整個(gè)消費(fèi)的線程模型大概是一個(gè)進(jìn)程一個(gè)kafka消費(fèi)線程n個(gè)數(shù)據(jù)處理線程m個(gè)數(shù)據(jù)寫(xiě)入線程。線程之間通過(guò)隊(duì)列來(lái)通信，為了在同一個(gè)進(jìn)程內(nèi)方便數(shù)據(jù)做預(yù)聚合操作。假設(shè)配置了4個(gè)數(shù)據(jù)處理線程，那么就會(huì)按照measurement做hash，分到4個(gè)bucket里面處理，這樣同一個(gè)measurement的數(shù)據(jù)會(huì)在一個(gè)bucket里面處理，也方便后續(xù)的指標(biāo)預(yù)聚合處理。

private int computeMetricNameHash(byte[] metricName) {
int hash = Arrays.hashCode(metricName);
hash = (hash == Integer.MIN_VALUE ? 0 : hash);
return hash;
}
byte[] metricName = metricEvent.getName();
hash = computeMetricNameHash(metricName);
buckets[Math.abs(hash) % bucketCount].add(metricEvent);

?經(jīng)過(guò)程序埋點(diǎn)測(cè)算，正常情況下整體鏈路的數(shù)據(jù)寫(xiě)入延遲控制在1s內(nèi)，大約在百毫秒級(jí)。

3、Metrics統(tǒng)一查詢層

契約上，兼容了Dashboard原來(lái)的查詢協(xié)議，也支持標(biāo)準(zhǔn)的prometheus協(xié)議。

實(shí)現(xiàn)上，封裝了VictoriaMetics+ClickHouse的統(tǒng)一查詢，支持元數(shù)據(jù)管理，預(yù)聚合管理，限流，rollup策略等。

查詢層主要提供了以下四個(gè)核心接口。?

• Data接口：根據(jù)measurement，tagKey，tagValue返回時(shí)序數(shù)據(jù)，數(shù)據(jù)源是VictoriaMetrics。
• Measurement接口：返回limit數(shù)量的measurement列表，數(shù)據(jù)源是ClickHouse。
• Measurement-tagKey接口：返回指定measurement的tagKey列表，數(shù)據(jù)源是ClickHouse。
• Measurement-tagKey-tagValue接口：返回指定measurement和tagkey的tagValue的列表，數(shù)據(jù)源是ClickHouse。

如下圖第一張所示是新的存儲(chǔ)架構(gòu)，第二張是VictoriaMetrics自身的架構(gòu)。

需要注意到，整個(gè)數(shù)據(jù)寫(xiě)入層是單機(jī)房寫(xiě)單機(jī)房的存儲(chǔ)集群，是完全的單元化結(jié)構(gòu)。最上層通過(guò)統(tǒng)一的數(shù)據(jù)查詢層匯總多個(gè)機(jī)房的數(shù)據(jù)進(jìn)行聚合輸出。在可用性方面，任何單一機(jī)房的故障僅會(huì)影響單機(jī)房的數(shù)據(jù)。

六、替換前后效果對(duì)比

1）替換后的查詢耗時(shí)從MAX，AVG，STD提升近4倍。查詢耗時(shí)大多落在10-50ms之間。相比之前HBase經(jīng)常查詢超時(shí)，整體查詢的穩(wěn)定性也好了很多，見(jiàn)圖6，7。

2）寫(xiě)入穩(wěn)定性提升，徹底解決了因?yàn)镠Base熱點(diǎn)引發(fā)的數(shù)據(jù)積壓。

3）替換后支持了更多的優(yōu)秀的特性，可以基于promQL實(shí)現(xiàn)指標(biāo)的邏輯計(jì)算，同比環(huán)比，模糊匹配等。

七、未來(lái)規(guī)劃

1）統(tǒng)一查詢層接入所有Metrics數(shù)據(jù)，除了Dashboard，目前內(nèi)部還有HickWall，Cat有大量Metrics數(shù)據(jù)沒(méi)有接入統(tǒng)一查詢層，目前采用的是直連openrestry+VictoriaMetrics的方式，openrestry上面做了一些簡(jiǎn)單的查詢邏輯，這塊計(jì)劃后續(xù)接入統(tǒng)一查詢層，這樣內(nèi)部可以提供統(tǒng)一的元信息管理，預(yù)聚合策略等，達(dá)到Metrics架構(gòu)統(tǒng)一。

2）提供統(tǒng)一寫(xiě)入層，總體Metrics目前是近億級(jí)/秒，這塊寫(xiě)入目前主要是基于Kafka消費(fèi)進(jìn)存儲(chǔ)的方式，內(nèi)部這塊寫(xiě)入是有多個(gè)應(yīng)用在處理，如果有統(tǒng)一的寫(xiě)入層那么就能做到寫(xiě)入邏輯統(tǒng)一，和查詢層的查詢策略也能做到聯(lián)動(dòng)，減少重復(fù)建設(shè)。

3）Metrics的存儲(chǔ)統(tǒng)一層提供了較好的典范，內(nèi)部的日志存儲(chǔ)層統(tǒng)一也在如火如荼的進(jìn)行中，也會(huì)往這樣的一個(gè)方向發(fā)展。