鑽石舞台

一、背景

監控領域有三大塊，分別是Metrics，Tracing，Logging。這三者作為IT可觀測性數據的三劍客，基本可以滿足各類監控、告警、分析、問題排查等需求。

Logs：我們對於Logs是更加寬泛的定義，即記錄事物變化的載體，包括常見的訪問日誌、交易日誌、內核日誌等文本型以及GPS、音視頻等泛型數據。日誌在調用鏈場景結構化後其實可以轉變為Trace，在進行聚合、降採樣操作後會變成Metrics。

Metrics：是聚合後的數值，相對比較離散，一般有name、labels、time、values組成，Metrics數據量一般很小，相對成本更低，查詢的速度比較快。

Traces：是最標準的調用日誌，除了定義調用的父子關係外（一般通過TraceID、SpanID、ParentSpanID），一般還會定義操作的服務、方法、屬性、狀態、耗時等詳細信息，通過Trace能夠代替一部分Logs的功能，通過Trace的聚合也能得到每個服務、方法的Metrics指標。

近年來，可觀測性這個概念如火如荼，可以看作是對監控的一次大升級。CNCF也發布了OpenTelemetry標準，旨在提供可觀測性領域的標準化方案。那麼相比傳統的監控告警，監控和可觀測性有啥區別和聯繫呢？個人理解，可觀測性能夠以更加白盒的方式看透整個複雜的系統，幫助我們更好的觀察系統的運行狀況，快速定位和解決問題。

簡單理解，監控和可觀測性的關係。監控告訴我們系統的哪些部分是正常工作的，可觀測性告訴我們那裡為什麼不工作了。監控側重宏觀，可觀測性包括微觀能力。監控是可觀測性的子集。

圖1

近些年，隨着攜程集團對線上故障1-5-10目標的提出（即第1分鐘發現故障，第5分鐘定位故障，第10分鐘解決故障），對監控系統提出了更高的要求。監控系統最重要的三個特點可以定義為，系統穩定性，數據及時性，數據精準性，三者缺一不可。

攜程監控系統 Hickwall 是一個企業級的指標監控告警系統，兼容了業界的 Prometheus監控標準，覆蓋攜程所有的指標監控數據，包括系統層和應用層。主要目標是實現指標數據的採集、接入、存儲、展現，並在此基礎上配置告警和通知，告警治理等，同時為第三方平台提供第一手的監控數據和告警事件。

二、遇到的問題

隨着業務不斷膨脹，系統規模的持續擴大，Hickwall遇到了一些問題：

高基數查詢，指標維度過多，導致整體查詢慢，用戶體驗不佳。

雲原生的監控方案缺乏，需要支持開源PromQL業界標準，Prometheus SDK指標接入。

監控粒度粗，一些毛刺無法洞察，需要提高數據採樣粒度。

告警系統多，技術方案雜，難維護，產品使用上用戶到處找入口，規則和閾值定義不一樣，很困惑。

監控數據延遲，導致誤告警。

告警多，重複告警，缺乏治理。

容器大規模HPA帶來的指標基數膨脹問題。

三、主要的演進

針對上述問題和痛點，Hickwall過去兩年進行了一些針對性的優化和演進。

3.1 雲原生監控

1）TSDB升級，經過三次演進，現在是基於VictoriaMetrics實現的第四代的TSDB解決方案。完全兼容Prometheus查詢語法。

2）提供了自研Beacon容器監控組件，和k8s體系高度集成，不僅支持容器系統指標，JVM指標，也支持自定義的PrometheusSDK埋點接入。

3.2 解決高基數問題

1）產品升級，新增日誌/指標預聚合能力，產品開放配置能力，根據一定配置策略，通過將多維原始數據降維，收斂指標維度，聚合輸出預聚合數據，通過這種方式可以縮減指標量級，對後續鏈路的處理都有性能提升。目前系統配置了166條聚合規則，生成了209個指標。

2）指標治理：監控統計指標維度，應用維度的高基數檢測，對非法寫入進行封禁。非法寫入包括了tag的value使用了隨機數，字符內容超過256個字符，指標名稱使用了中文命名等。

3）容量規劃：做好集群的自監控，進行妥善的容量規劃，主要是監控ts增長數量和datapoint數據量，以應對日益增長的指標數據。

4）忽略有問題的tag：治理平台能夠按需配置ignore tag，例如針對HPA場景下的應用埋點，忽略value容易發生變化的hostname和ip這兩種tag（一般不會關心這種維度），可以大大減少基數。

3.3 數據粒度提升

為了響應集團1-5-10目標，核心指標採集上秒級，目前主要涉及的是核心的系統指標，業務訂單指標和部分應用指標，其他非關鍵可以按需自行配置。

3.4 告警中台接入

自研新一代統一的pull告警系統，統一各類老的告警技術方案，目前接入告警規則10萬+，同時對接了告警中心，對用戶提供一站式的告警治理能力。

3.5 解決數據延遲問題

數據延遲問題主要是數據鏈路還依賴了消費Kafka來寫入TSDB。因此我們將核心鏈路改造成最短路徑，從數據網關分發數據直接寫到TSDB，從根本上解決了延遲問題。

3.6 時序存儲的演進

Hickwall存儲這塊主要經歷了下面四個階段。

第一階段：ES存儲，Graphite查詢語法

第一個版本的架構主要以數據寫Kafka，消費Kafka進ES的套路來設計。這個方案的好處：

可以容忍比較大的系統downtime

數據可以多次多種方式加以利用

ES存儲的寫入性能最大化

ES的聚合能力比較強，所以不少聚合都可以實時來做

ES非常穩定可靠，運維工作較少

第一個版本已經初步實現了監控系統的功能，但是在使用過程中同樣暴露了一些問題：

1）ES存儲導致數據容易堆積

ES是一個非常穩定的全文索引工具，比較適合日誌，搜索的場景。但是卻不是最好的監控數據的存儲方式，主要是寫入性能不是很好，必須大批量，高等待的方式寫才能達到比較大的量，但是這個比較大的量相對監控數據的場景也略顯不夠。

而且為了提高寫的性能，還需要犧牲數據的實時性（提高refresh time來減少磁盤操作，提高寫入量）。實時性又是一個高質量的監控系統所需要努力提高的。這就是一個矛盾點，雖然當時能夠做到勉強接受，但肯定不是最理想的，當時的數據latency需要30s以上。

2）數據鏈路過長

監控數據主要是從Proxy進來到Trigger告警需要依次經過6個組件，任何一個組件出現問題，都可能導致告警漏告或誤告。

第二階段：基於InfluxDB存儲，打造自研的Incluster集群方案，Graphite查詢語法

ES用於時間序列存儲存在不少問題，例如磁盤空間使用大，磁盤IO使用多，索引維護複雜，寫入和查詢速度慢等。當時InfluxDB是排名第一的時序數據庫，到2017年的時候已經比較穩定，所以我們萌生了用InfluxDB替換ES作為存儲的方案。但是InfluxDB並沒有開源的集群方案，因此我們自研了Incluster集群方案。

在元數據管理這塊使用了Raft來保證一致性和分區容錯性。集群大致的實現思路是，客戶端通過Incluster節點寫入數據，Incluster按照數據分布策略將寫入請求轉發到相關的InfluxDB節點上，查詢的時候按照數據分布策略進行數據讀取和合併。在用戶查詢方面，實現了類Graphite語法用於配圖，兼容上一代語法，從而可以減少用戶遷移配圖的成本。

第三階段：ClickHouse列式存儲，SQL查詢語法

2019年，我們逐步開始推進應用埋點存儲的統一接入。在這個階段，InfluxDB在高基數場景下，查詢表現並不是很好，集群穩定性也受到了較大的挑戰。因此我們調研了當時大火的ClickHouse，開始接入應用埋點，並且提供SQL語法查詢。攜程的機票部門率先接入，在自定義應用埋點場景取得了比較好的效果。

第四階段：基於開源的VictoriaMetrics TSDB，PromQL查詢語法

2020年，隨着雲原生技術的發展，內部對雲監控的需求越來越強烈。因此我們在2020年調研並測試了業界開源的VictoriaMetrics TSDB，這款TSDB作為Prometheus的遠端持久存儲解決方案，提供了相較於傳統TSDB較好的性能和天然兼容Prometheus協議的查詢語法和接口。

這款TSDB經過測試在綜合寫入性能和查詢方面表現較好。目前我們內部主要分了三個大集群，集群規模已經達百餘台物理機，成為攜程統一的Metrics存儲方案。

圖2

3.7 監控可視化的演進

由於內部使用的可視化工具是基於Grafana二次開發，伴隨着存儲技術的升級，2020年我們還進行了一次Grafana2版本到6版本的全面升級，新版本增加了多種新的數據源，所見即所得的告警能力，更多的圖表類型展現，可視化方面大大提升了用戶體驗。

圖3

四、平台現狀

隨着多年的發展，目前平台指標數據量寫入量峰值在千萬級/秒，查詢量數千qps，接入各類告警規則10萬+，查詢P99控制在1s內。數據粒度最小支持到10s級，時序數據默認保存一年。計算+存儲集群規模達百餘台物理機，並且主要組件都上了k8s平台。數據統計如圖4所示。

圖4

五、目前架構

從數據流向看，目前總體大致架構如圖5所示，可見數據流和告警是走的最短路徑。

1）數據：data->Proxy->TSDB

2）告警：data->Proxy->Trigger

這從根本上規避數據延遲和告警延遲問題。下面會主要介紹Hickwall所依賴的幾個核心組件。

圖5

Collector組件：

數據採集，提供多種客戶端，包括了Hickwall SDK（應用埋點），Hickwall agent（機器數據採集），Prometheus SDK，Beacon（容器數據採集）。

Proxy組件：

提供給Hickwall SDK，Hickwall agent，Prometheus SDK的統一支持多協議的數據收集服務，主要是thrift protocol和line protocol。作為數據接收的統一入口，承擔了流量接入，分發，流量保護，數據統計等功能。Proxy默認為每個應用ID提供了固定的流量配額，具備了基於指標，應用ID的限流能力，目前是基於固定時間窗口進行數據量流控。

告警組件：

提供了Trigger流式告警和基於Bosun的統一pull告警。通過推拉結合的告警引擎解決了大規模閾值告警和複雜同環比告警場景。

DownSample組件：

數據降採樣，支持可以配置的聚合採樣粒度，節省存儲成本。同時提供數據保存更長的時間。

Piper組件：

統一的告警通知服務，支持告警通知升級。

Transfer組件：

負責監控數據分發給第三方系統，供數據分析，容量規則，AI智能告警等用途。

Grafana看板服務：

所見即所得的查詢，提供豐富的圖表展現以及監控大盤。

TSDB Cluster：

是最核心的時序存儲集群，時序類的查詢一般QPS都比較高（主要有很多告警規則），通常都是range查詢，每次查詢某一個單一的指標/時間線，或者一組時間線進行聚合。所以對於這類數據都會有專門的時序引擎來支撐，目前主流的時序引擎基本上都是用類似於LSM Tree的思想來實現，以適應高吞吐的寫入和查詢。

ClickHouse Cluster：

ClickHouse作為優秀的OLAP列式數據庫，早期是我們採用的第三代時序存儲引擎，現在慢慢退居二線，目前現在用來導入一些時序數據和高基數指標數據，提供一些額外的數據分析能力。

Hickwall Portal：

一站式的監控日誌告警治理平台，目前提供了指標接入，指標查詢，告警配置，通知配置，日誌接入，日誌管理，機器agent治理等模塊。

從存儲集群來看，TSDB Cluster的架構如下：

1）總體架構分為三層結構，vminsert寫入層，vmstorage存儲層，vmselect查詢層。這三個組件都可以單獨進行擴展，並運行在大多數合適軟件上。

2）寫入層無狀態，支持多協議的寫入，寫入層支持多協議，包括InfluxDB，OpenTSDB，Prometheus，Graphite等。接受程序寫入的數據，通過對metric+tag組合進行一致性hash寫入到對應的存儲節點，當有存儲節點失聯，會進行數據重路由分發到好的節點上面。重路由的過程中，由於數據分發策略的變化，可能會導致寫入變慢，等待存儲節點倒排索引重建完成，就會恢復寫入速度正常。

3）存儲層有狀態，採用shared nothing的結構，每個節點數據不共享，獨立存儲，增加了集群的可用性，簡化集群的運維和集群的擴展。支持多租戶，採用了ZSTD壓縮，列式存儲，支持副本配置。

存儲層的基本原理可以理解為存儲了原始的數據，並且會依據查詢層發來的time range和label filter進行數據查找並且返回。在存儲層，針對時序數據做了很多存儲優化。存儲層要求配置一個數據保存的時間，俗稱Retention Period。Retention Period到期後，會進行倒排索引的清理和重建，cpu和io通常會大幅提升，會影響寫入效率。

從壓縮來看，壓縮能夠很好節省內存和磁盤空間，時序數據的壓縮特徵比較明顯，TSDB Cluster採用先做時序壓縮，再做通用壓縮的方法。比如，先做delta-of-delta計算或者異或計算，然後根據情況做zig-zag，最後再根據情況做一次ZSTD壓縮。據測試統計，在生產環境中，每個數據點（8字節時間戳 + 8字節value共計16字節）壓縮後小於1個字節，最高可達 0.4字節，能提供比Gorilla算法更好的壓縮率。

4）查詢層無狀態，支持PromQL查詢。

基本原理可以理解為進行查詢語法解析，從存儲層獲取時序數據並且返回標準的格式，查詢層往往會進行一些查詢QPS，查詢耗時的限制，以保證後端服務不被拖垮。

TSDB的部署架構圖如下：

圖6

六、未來規劃

隨着可觀測性技術的不斷發展，僅僅局限於Metrics監控是不行的，我們對未來的展望如下。

1）指標分級

指標管理沒有優先級，希望提供分級管理的模式。

2）雲原生可觀測性的探索

eBPF指標採集的引入，提升主機端的可觀測性能力。

3）Logging，Metrics，Tracing的結合。

多套方案交織：可能要使用至少Metrics、Logging、Tracing3種方案，維護代價巨大。在這種多套方案組合的場景下，問題排查需要和多套系統打交道，若這些系統歸屬不同的團隊，還需要和多個團隊進行交互才能解決問題，整體的維護和使用代價非常巨大。因此我們希望能夠使用一套系統去解決所有類型可觀測性數據的採集、存儲、分析的功能。

4）兼容業界主流協議，OpenTelemetry的標準。

OpenTelemetry旨在提供統一的可觀測性數據收集，未來服務端可以提供兼容OpenTelemetry協議的接入，擁抱開源社區，我們在保持關注中。

5）agent邊緣計算，前置數據聚合。

現在是服務端基於Flink做預聚合，希望可以在agent端提供一些預聚合能力，比如採集日誌的agent能夠聚合Metrics輸出。

團隊招聘信息

我們是攜程技術保障中心系統研發團隊，主要負責攜程私有雲，混合雲和PaaS平台的建設，管理數以萬計服務器規模的集群，負責數萬台計算/存儲混合部署和在線/離線混合部署，支持海量數據的穩定存儲。

團隊積極擁抱開源和創新的軟硬件架構，在這裡你除了可以學習到業界最流行最先進的技術，還能接觸到最新最酷的硬件產品，我們長期招聘有志於從事基礎設施方向並願意深耕的同學，目前容器/存儲/大數據等方向都有均有開放職位。

簡歷投遞郵箱：tech@trip.com，郵件標題：【姓名】-【系統研發】-【投遞職位方向】。

【推薦閱讀】

高效線上問題排查——套路化和工具化攜程持久化KV存儲實踐攜程數據庫發布系統演進之路數萬實例數百TB數據量，攜程Redis治理演進之路

「攜程技術」公眾號

分享，交流，成長