應(yīng)用監(jiān)控系統(tǒng)演進(jìn)：從選型到落地，鏈路追蹤一氣呵成

作者：陸家靖 2022-09-14 09:21:41

這套系統(tǒng)支撐我們走過(guò)了業(yè)務(wù)發(fā)展最迅猛的一段時(shí)間，為大量的問(wèn)題排查和故障診斷提供了一些線索。

一、引言

隨著分布式系統(tǒng)和微服務(wù)的日益發(fā)展，系統(tǒng)的開(kāi)發(fā)和運(yùn)維對(duì)于可觀測(cè)性的需求越來(lái)越迫切?？捎^測(cè)性[1]一詞的來(lái)源最初是從控制理論中借鑒而來(lái)的。目前我們?cè)谡務(wù)摽捎^測(cè)性的時(shí)候，我們通常是指以下三個(gè)方面：

鏈路 Tracing
指標(biāo) Metrics
日志 Logging

這三者并不完全是三個(gè)獨(dú)立的概念，而是相輔相成的。談及這三個(gè)方面，我們總是不得不提及Peter Bourgon的文章[2]，以及其中最經(jīng)典的Venn diagram：

二、收錢(qián)吧監(jiān)控系統(tǒng)的歷史發(fā)展

收錢(qián)吧從在2017年開(kāi)始逐步建設(shè)應(yīng)用監(jiān)控系統(tǒng)，系統(tǒng)建設(shè)主要的方向是提供鏈路追蹤(Tracing)以及性能監(jiān)控(Metrics)兩方面的能力。

在監(jiān)控系統(tǒng)的選型方面，我們盡量使用開(kāi)源的系統(tǒng)：

Tracing

我們選擇的是twitter開(kāi)源的Zipkin[3]，它為我們提供了鏈路追蹤的后端系統(tǒng)，使用Elasticsearch作為T(mén)racing的后端存儲(chǔ)。

Metrics

我們?cè)赥racing數(shù)據(jù)的基礎(chǔ)上，通過(guò)從Kafka中消費(fèi)Zipkin格式的數(shù)據(jù)聚合得到分鐘級(jí)別的指標(biāo)，時(shí)序數(shù)據(jù)簡(jiǎn)單地使用MySQL作為后端存儲(chǔ)。

在接入層，我們采用最原始的方式，為各個(gè)Java的模塊、組件提供各種各樣的instrumentation工具包來(lái)進(jìn)行埋點(diǎn)，業(yè)務(wù)研發(fā)同學(xué)以pom依賴的形式引用到自己的業(yè)務(wù)服務(wù)中，比如：

通過(guò)MySQL Driver提供的攔截器機(jī)制[4]來(lái)對(duì)MySQL數(shù)據(jù)庫(kù)的請(qǐng)求進(jìn)行采樣；
通過(guò)封裝一個(gè)新的JSON-RPC包來(lái)實(shí)現(xiàn)對(duì)RPC層的埋點(diǎn)；
通過(guò)Spring的HandlerInterceptor[5]來(lái)實(shí)現(xiàn)Rest風(fēng)格接口的攔截；
通過(guò)Spring AOP來(lái)進(jìn)行Redis訪問(wèn)的鏈路采集；
...

這套系統(tǒng)支撐我們走過(guò)了業(yè)務(wù)發(fā)展最迅猛的一段時(shí)間，為大量的問(wèn)題排查和故障診斷提供了一些線索，然而業(yè)務(wù)開(kāi)發(fā)逐漸開(kāi)始對(duì)這套系統(tǒng)產(chǎn)生不滿，主要集中在以下幾個(gè)方面，

1）由于我們?cè)诔跗诓捎肕ySQL作為底層時(shí)序數(shù)據(jù)的存儲(chǔ)，這在當(dāng)時(shí)看起來(lái)是一個(gè)主流的方案[6]，但我們碰到了很大的性能問(wèn)題，畢竟MySQL這類數(shù)據(jù)庫(kù)提供的存儲(chǔ)引擎并沒(méi)有對(duì)此類場(chǎng)景進(jìn)行優(yōu)化[7]。同時(shí)，MySQL并沒(méi)有提供豐富的針對(duì)時(shí)間序列的查詢算子。

PgSQL 9.6.2 數(shù)據(jù)插入的吞吐量隨著表大小的變化關(guān)系[8]。

在鏈路追蹤或者說(shuō)應(yīng)用監(jiān)控的場(chǎng)景，我們需要的是高吞吐量以及線性的性能[9]，同時(shí)我們也需要增加數(shù)據(jù)的生命周期管理的功能：因?yàn)殡S著新數(shù)據(jù)的寫(xiě)入，歷史數(shù)據(jù)的價(jià)值會(huì)隨著時(shí)間的流逝而價(jià)值降低。

2）由于我們需要從Tracing數(shù)據(jù)反推得到指標(biāo)數(shù)據(jù)Metrics，我們“魔改“了Zipkin傳輸部分的邏輯，對(duì)所有不采樣數(shù)據(jù)（Unsampled）在客戶端進(jìn)行聚合以后批量上報(bào)，導(dǎo)致我們?cè)赯ipkin的升級(jí)方面產(chǎn)生了很大的困難。尤其是在https://github.com/openzipkin/zipkin/pull/1968，以后不再允許用戶定制開(kāi)發(fā)服務(wù)端。

3）業(yè)務(wù)方升級(jí)依賴需要采集器組件升級(jí)支持，從而產(chǎn)生了額外的工作量。同時(shí)，也有大量的組件難以通過(guò)這種侵入性的方式進(jìn)行支持，或者需要投入很大的人力成本來(lái)進(jìn)行研發(fā)、適配。

三、新一代應(yīng)用監(jiān)控系統(tǒng) - Hera

基于以上原因，我們決定研發(fā)一套新的系統(tǒng)來(lái)同時(shí)滿足幾個(gè)條件：

低存儲(chǔ)成本：能夠以低成本存儲(chǔ)較長(zhǎng)周期的數(shù)據(jù)，對(duì)于指標(biāo)能夠存儲(chǔ)至少四周，對(duì)于鏈路存儲(chǔ)一周，這讓我們排除了ElasticSearch這個(gè)選項(xiàng)；
高實(shí)時(shí)查詢性能、高靈活度：不再使用MySQL這類關(guān)系型數(shù)據(jù)庫(kù)作為時(shí)間序列的存儲(chǔ)，使用Prometheus或Prometheus兼容的存儲(chǔ)系統(tǒng)；
優(yōu)化研發(fā)效率：使用字節(jié)碼編織技術(shù)，無(wú)侵入地進(jìn)行埋點(diǎn)，并更緊密地與DevOps流程結(jié)合。

1、鏈路追蹤

分布式鏈路追蹤的概念和心智模型(Mental Model)大多是受到2010年發(fā)表的Google’s Dapper論文[10]的影響。在Dapper論文中，作者明確地指出了Trace的樹(shù)形結(jié)構(gòu)：

We tend to think of a Dapper trace as a tree of nested RPCs.

以及提出了所謂Span的概念：

In a Dapper trace tree, the tree nodes are basic units of work which we refer to as spans. The edges indicate a casual relationship between a span and its parent span.

在一個(gè)Dapper鏈路樹(shù)中，各個(gè)Span之間存在因果和時(shí)序關(guān)系。

在鏈路追蹤的系統(tǒng)選型方面，我們對(duì)比了在當(dāng)時(shí)比較活躍的幾個(gè)開(kāi)源項(xiàng)目：

Zipkin
Apache/Skywalking v6.6.0
Jaeger v1.16

Jaeger是Uber[11]在2016年開(kāi)源的鏈路追蹤平臺(tái)，并捐獻(xiàn)給了CNCF云原生基金會(huì)。

Jaeger的主要組件和控制流、數(shù)據(jù)流示意圖，其中使用Kafka作為緩沖管道。

Jaeger受到了開(kāi)源社區(qū)的廣泛支持，比如：

Istio[12]原生支持使用Jaeger增強(qiáng)Service Mesh服務(wù)網(wǎng)格的可觀測(cè)性；
服務(wù)網(wǎng)格的數(shù)據(jù)面實(shí)現(xiàn)Envoy[13]支持使用Jaeger作為鏈路追蹤的服務(wù)提供方；
...

1）鏈路追蹤后端系統(tǒng)和存儲(chǔ)的選型

我們重點(diǎn)考慮的是他們對(duì)于存儲(chǔ)系統(tǒng)方面的支持情況和擴(kuò)展能力。

① 各個(gè)開(kāi)源鏈路追蹤實(shí)現(xiàn)的存儲(chǔ)能力

Jaeger社區(qū)對(duì)于存儲(chǔ)的擴(kuò)展性極佳，提供了基于gRPC的插件機(jī)制[14]，方便定制擴(kuò)展。

+----------------------------------+                  +-----------------------------+
|                                  |                  |                             |
|                  +-------------+ |   unix-socket    | +-------------+             |
|                  |             | |                  | |             |             |
| jaeger-component | grpc-client +----------------------> grpc-server | plugin-impl |
|                  |             | |                  | |             |             |
|                  +-------------+ |                  | +-------------+             |
|                                  |                  |                             |
+----------------------------------+                  +-----------------------------+




       parent process                                        child sub-process

在存儲(chǔ)的具體選擇方面，我們?cè)诋?dāng)時(shí)注意到了Aliyun SLS能夠支持作為鏈路追蹤的后端，并且官方提供了一個(gè)實(shí)現(xiàn)https://github.com/aliyun/aliyun-log-jaeger，我們內(nèi)部基于這個(gè)思路實(shí)現(xiàn)了gRPC插件版本的SLS后端實(shí)現(xiàn)，目前穩(wěn)定運(yùn)行在生產(chǎn)環(huán)境。

存儲(chǔ)周期：SLS能夠提供長(zhǎng)達(dá)30天的存儲(chǔ)周期。
存儲(chǔ)量：一天存儲(chǔ)的Span數(shù)量超過(guò)4億，使用約6TB存儲(chǔ)空間。
性能：在SLS Query界面進(jìn)行條件查詢可以在3-5s以內(nèi)返回結(jié)果。
成本：每天成本約為70元，一年約2萬(wàn)元左右（大約為2臺(tái)8U32G的ECS的按年付費(fèi)的價(jià)格）。

Jaeger operator在 https://github.com/jaegertracing/jaeger-operator/pull/1517 中引入了對(duì)gRPC插件的原生支持，gRPC插件可以作為InitContainer[15]在啟動(dòng)時(shí)將插件的二進(jìn)制文件復(fù)制到共享的EmptyDir存儲(chǔ)卷中。同時(shí)，我們也積極向社區(qū)反饋，向社區(qū)提供了gRPC插件的自觀測(cè)功能(Self Observability)：

aeger-grpc插件支持opentracing上下文傳遞：https://github.com/jaegertracing/jaeger/pull/2870
go-plugin插件支持參數(shù)配置: https://github.com/hashicorp/go-plugin/pull/168

2）業(yè)務(wù)方接入優(yōu)化

SkyWalking 的美妙不僅在于其強(qiáng)大的功能，還在于其優(yōu)秀的代碼實(shí)現(xiàn)[16]。

在過(guò)去我們使用侵入性的方式提供應(yīng)用監(jiān)控接入，監(jiān)控服務(wù)的提供方需要為各個(gè)業(yè)務(wù)方提供的插件、模塊，并且需要花費(fèi)大量的精力來(lái)實(shí)現(xiàn)版本兼容性等工作，這種方式缺乏統(tǒng)一的切面和工作機(jī)制，需要對(duì)各個(gè)組件逐個(gè)”攻破”。Skywalking是華為的吳晟等人在2015年開(kāi)源的一款A(yù)PM產(chǎn)品，并成為Apache的頂級(jí)項(xiàng)目，Skywalking-Java使用了字節(jié)碼增強(qiáng)技術(shù)，提供了無(wú)侵入性的鏈路埋點(diǎn)，大大降低了使用成本。在Java中，常用的字節(jié)碼工具有以下幾種。

ASM，BCEL屬于Low Level，而CGLib、Javassist和ByteBuddy更易用。

對(duì)于字節(jié)碼技術(shù)的具體分析可以參考StackOverflow上的回答[17]。

其中ByteBuddy的易用性和性能都達(dá)到一流的水準(zhǔn)：

ByteBuddy官方提供的性能測(cè)試結(jié)果。

為了充分利用Skywalking-Java提供的插件，我們?cè)贠penTracing的接口上實(shí)現(xiàn)了整套Skywalking鏈路追蹤的模型。具體來(lái)說(shuō)，Skywalking的鏈路追蹤語(yǔ)義包括三層：

① Skywalking中的Trace與OpenTracing語(yǔ)義中的Trace類似

② Skywalking中的Span與OpenTracing語(yǔ)義中的Span類似

EntrySpan: 等價(jià)于OpenTracing中Kind=Consumer或者Server的Span；
ExitSpan: 等價(jià)于OpenTracing中Kind=Producer或者Client的Span；
LocalSpan: 不屬于上述兩者的其他類型。

③ Skywalking增加了一層Segment的概念

一個(gè)Segment被約束在一個(gè)線程上，其中包含的所有AbstractTracingSpan 都在此線程上創(chuàng)建和銷毀。這里SegmentID對(duì)應(yīng)于OT中的SpanID，在Skywalking中的Span 是按照創(chuàng)建的順序從0開(kāi)始編號(hào)的。

當(dāng)然模型上也有不同之處：

跨線程

OpenTracing的標(biāo)準(zhǔn)要求實(shí)現(xiàn)者將Span 設(shè)計(jì)成線程安全的，因?yàn)镾pan允許被跨線程傳遞。而在Skywalking中，跨線程是通過(guò)對(duì)當(dāng)前Segment進(jìn)行快照[18]實(shí)現(xiàn)的，而Span 在絕大部分場(chǎng)景下不需要保證是線程安全的。

異步

異步Span主要應(yīng)用于記錄異步操作真正的起始和結(jié)束時(shí)刻。以Spring Reactive為例[19]：用戶編寫(xiě)的Controller返回的是一個(gè)可被執(zhí)行任務(wù)（通常是Mono類型），而不是最后的結(jié)果，Dispatcher會(huì)將任務(wù)通過(guò)線程池去執(zhí)行，那么我們需要記錄的是真正這個(gè)請(qǐng)求從任務(wù)創(chuàng)建到被“計(jì)算“完成的整個(gè)周期。在OpenTracing標(biāo)準(zhǔn)中沒(méi)有提及這部分的實(shí)現(xiàn)。而Skywalking的多個(gè)插件中使用了這個(gè)機(jī)制，比如Redis客戶端Lettuce，Spring Webflux，Apache AsyncHttpClient等。

我們通過(guò)在OpenTracing接口上實(shí)現(xiàn)與Skywalking一致的語(yǔ)義從而實(shí)現(xiàn)幾乎零成本地移植并使用它所有的插件。我們?cè)谑褂肧kywalking-Java的過(guò)程中也發(fā)現(xiàn)了不少問(wèn)題，也與社區(qū)積極地反饋，做出了一些貢獻(xiàn)，主要包括：

JSON日志格式的實(shí)現(xiàn)：https://github.com/apache/skywalking/pull/5357
Spring Kafka 1.x插件：https://github.com/apache/skywalking/pull/5879
Spring DevTools支持和多類加載器優(yōu)化：https://github.com/apache/skywalking/pull/6973
Jedis Transaction支持：https://github.com/apache/skywalking-java/pull/57

3）服務(wù)依賴分析

服務(wù)的依賴分析在公司內(nèi)部一直是業(yè)務(wù)開(kāi)發(fā)迫切需要的功能，它在服務(wù)容量規(guī)劃、問(wèn)題診斷和服務(wù)強(qiáng)弱性依賴判斷中都有比較實(shí)用的價(jià)值。在Jeager社區(qū)的實(shí)現(xiàn)中，推薦生產(chǎn)使用Spark批處理[20]的方式實(shí)現(xiàn)了全局的依賴分析，也有基于Flink的實(shí)時(shí)處理[21]，但已經(jīng)沒(méi)有在維護(hù)狀態(tài)。

為了實(shí)現(xiàn)這個(gè)功能，我們使用了Apache Flink，通過(guò)消費(fèi)Kafka中的鏈路數(shù)據(jù)，實(shí)時(shí)計(jì)算出服務(wù)之間的依賴關(guān)系，將Tuple<downsampled timestamp, caller, sub-caller, callee, sub-callee> 格式的數(shù)據(jù)通過(guò)OpenTSDB協(xié)議傳輸?shù)轿覀兊臅r(shí)序數(shù)據(jù)庫(kù)VictoriaMetrics 。

前端根據(jù)用戶提供的時(shí)間窗口，通過(guò)Java服務(wù)暴露的API進(jìn)行上游/下游的查詢：

后續(xù)我們將在用戶交互和調(diào)用量的分析展示方面進(jìn)行進(jìn)一步的優(yōu)化。

2、指標(biāo)監(jiān)控

在老版本的監(jiān)控程序中，我們使用了關(guān)系型數(shù)據(jù)庫(kù)作為時(shí)序數(shù)據(jù)的存儲(chǔ)系統(tǒng)，使得我們?cè)诓樵兊撵`活性和性能方面遭遇到了很大的瓶頸，我們有必要在新系統(tǒng)設(shè)計(jì)的時(shí)候去進(jìn)行一定的反思。在過(guò)去幾年中，云原生的概念逐漸深入人心，而Prometheus是云原生時(shí)代監(jiān)控的事實(shí)標(biāo)準(zhǔn)。

在進(jìn)行了一些調(diào)研之后，我們認(rèn)為單機(jī)版本的Prometheus并不能支撐超過(guò)百萬(wàn)級(jí)別活躍的指標(biāo)和超過(guò)一周的數(shù)據(jù)存儲(chǔ)。我們的目光主要聚焦到了Thanos、Cortex和VictoriaMetrics，在國(guó)內(nèi)技術(shù)社區(qū)分享比較多的是Cortex和Thanos，但我們對(duì)比發(fā)現(xiàn)Cortex的架構(gòu)非常復(fù)雜，對(duì)系統(tǒng)運(yùn)維提出了新的挑戰(zhàn)，而Thanos也有一定的運(yùn)維復(fù)雜性，且由于使用對(duì)象存儲(chǔ)（S3等）作為冷數(shù)據(jù)存儲(chǔ)，查詢可能存在一部分服務(wù)不可用導(dǎo)致返回部分?jǐn)?shù)據(jù)。同時(shí)，我們也發(fā)現(xiàn)國(guó)內(nèi)的知乎在QCon 2020[22]上分享了他們使用VictoriaMetrics的經(jīng)驗(yàn)。我們基于以下原因最終選擇了VictoriaMetrics。

VictoriaMetrics在各項(xiàng)性能測(cè)試[23]中都表現(xiàn)卓著；
作者Aliaksandr Valialkin精于Go語(yǔ)言的性能優(yōu)化，是fasthttp等高性能Go語(yǔ)言組件的作者；
最重要的是VM的集群架構(gòu)簡(jiǎn)單，易于運(yùn)維。

VM的各個(gè)組件都是獨(dú)立的，可以水平擴(kuò)展，只有核心的vmstorage是有狀態(tài)的，其他組件均是無(wú)狀態(tài)的。

1）推還是拉 (push or pull)

對(duì)于指標(biāo)類的數(shù)據(jù)，采用主動(dòng)推還是被動(dòng)拉的模式，一直以來(lái)都是存在較大的爭(zhēng)議[24]。我們與Prometheus一樣使用推的模式，基于以下原因，

服務(wù)發(fā)現(xiàn)?

一個(gè)詬病Pull模式的原因是認(rèn)為Pull模式需要大規(guī)模的服務(wù)發(fā)現(xiàn)，但這一問(wèn)題在Kubernetes上反而不存在任何問(wèn)題，我們借助CRD[25]可以很輕易地實(shí)現(xiàn)服務(wù)抓取目標(biāo)的定義。同時(shí)可以將Pod，Service上的標(biāo)簽附加到指標(biāo)上，幫助查詢的時(shí)候區(qū)分實(shí)例，服務(wù)所屬的業(yè)務(wù)團(tuán)隊(duì)等。反而，這在Push模式中是不容易實(shí)現(xiàn)，或者需要業(yè)務(wù)研發(fā)去改造的。

問(wèn)題排查?

當(dāng)指標(biāo)查詢失敗的時(shí)候，我們通常需要去判斷到底是哪一步出了問(wèn)題。在Push模式中，我們需要去檢查業(yè)務(wù)的代碼和日志來(lái)判斷問(wèn)題。然而在Pull模式，我們可以手動(dòng)在瀏覽器中去請(qǐng)求指標(biāo)暴露的接口（比如/metrics ）就可以判斷服務(wù)的健康狀況，業(yè)務(wù)是否正常導(dǎo)出指標(biāo)。

目前我們使用VictoriaMetrics的一些統(tǒng)計(jì)信息：

存儲(chǔ)周期60天，共有6990億個(gè)數(shù)據(jù)點(diǎn)，占用磁盤(pán)空間800GB；
活躍時(shí)間序列約500萬(wàn)，數(shù)據(jù)點(diǎn)插入的QPS約13萬(wàn)每秒；
范圍查詢的P99線平均值約為1.5s。

我們也自研了查詢面板，以限定查詢的時(shí)間范圍（最長(zhǎng)3天）和查詢的模式（針對(duì)服務(wù)job查詢）。

我們自研了一些重要的指標(biāo)插件，其中在應(yīng)用性能分析、故障定位中比較實(shí)用的維度有：

Servlet容器指標(biāo)：Tomcat忙碌線程數(shù)，百分比；
數(shù)據(jù)庫(kù)連接池指標(biāo)：支持HikariCP和Alibaba/Druid連接池，等待連接池的線程數(shù)，數(shù)據(jù)庫(kù)連接獲取時(shí)間，數(shù)據(jù)庫(kù)連接池使用占比；
緩存指標(biāo)：支持Redis，Caffeine和EhCache。緩存命中率；
Kubernetes監(jiān)控：Pod CPU、內(nèi)存使用量，我們也在系統(tǒng)中也集成了Kubernetes事件的查看和搜索。

由于公司部分核心服務(wù)還使用Docker部署在ECS上，我們?cè)赩ictoriaMetrics中實(shí)現(xiàn)了基于Dockerd API的服務(wù)發(fā)現(xiàn)機(jī)制[26]，也已經(jīng)合并到社區(qū)版本。

3、全面擁抱云原生

在2020年，Kubernetes已然成為了分布式操作系統(tǒng)的事實(shí)標(biāo)準(zhǔn)，公司內(nèi)部的絕大多數(shù)服務(wù)也已經(jīng)全面遷移到自建的Kubernetes集群。為了更好的利用新特性，我們?cè)?020年中啟動(dòng)Kubernetes的集群升級(jí)計(jì)劃，將集群升級(jí)到1.16版本（目前已經(jīng)升級(jí)到1.20），并遷移至阿里云的ACK托管集群。監(jiān)控系統(tǒng)的落地將全面依賴于Kubernetes系統(tǒng)。

1）我們提供Docker鏡像版本的Java Agent，方便業(yè)務(wù)開(kāi)發(fā)接入。

2）在生產(chǎn)環(huán)境，我們使用InitContainer[27]在容器啟動(dòng)階段注入Java Agent，兩者之間通過(guò)貢獻(xiàn)的EmptyDir[28]來(lái)傳遞Agent Jar包。這便于我們?cè)谏a(chǎn)環(huán)境中靜默升級(jí)Agent版本：即使Agent在生產(chǎn)出現(xiàn)問(wèn)題，我們可以快速修復(fù)問(wèn)題，然后升級(jí)初始化容器即可。

3）時(shí)序數(shù)據(jù)庫(kù)VictoriaMetrics的運(yùn)維和Jaeger組件的運(yùn)維也是通過(guò)Kubernetes Operator實(shí)現(xiàn)的：

我們對(duì)jaeger-ingester和jaeger-collector組件啟用了HPA，即基于CPU和內(nèi)存使用率的水平動(dòng)態(tài)擴(kuò)容。
VictoriaMetrics集群版本的各個(gè)組件也是通過(guò)Kubernetes operator[29]進(jìn)行維護(hù)的。

四、展望

1、后采樣的實(shí)現(xiàn)

由于我們目前采樣的是頭采樣（Head-Based Sampling）方案，一旦在鏈路中間的服務(wù)發(fā)生拋出異常且這條鏈路沒(méi)有被采樣，那么就會(huì)出現(xiàn)有錯(cuò)誤日志和報(bào)警，但鏈路追蹤系統(tǒng)無(wú)法查詢到這條鏈路的情況，這給開(kāi)發(fā)排查問(wèn)題帶來(lái)很大的阻礙。目前，業(yè)界有幾種典型的實(shí)現(xiàn)方案，

1）OpenTelemetry方案

https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/4958

OT社區(qū)的tailsampling方案[30]主要來(lái)自于Grafana公司的貢獻(xiàn)[31]，同時(shí)可以利用以下幾個(gè)processor和exporter實(shí)現(xiàn)高伸縮性。

（第一層）loadbalancingexporter：把屬于同一個(gè)TraceID的所有Trace和Log分發(fā)給一組固定的下游Collector；
groupbytraceprocessor：等待足夠長(zhǎng)的一段時(shí)間，將屬于一個(gè)TraceID的所有Span(s)打包傳遞到下游；
tailsamplingprocessor：通過(guò)預(yù)定義的組合策略進(jìn)行采樣。

2）字節(jié)跳動(dòng)方案

發(fā)生錯(cuò)誤的服務(wù)將采樣決定強(qiáng)制進(jìn)行翻轉(zhuǎn)，如果這條鏈路沒(méi)有進(jìn)行采樣的話。但這樣的話會(huì)丟失采樣決策改變之前的所有鏈路以及其他分支鏈路的數(shù)據(jù)。

3）貨拉拉方案

基于Kafka延遲消費(fèi)+布隆過(guò)濾器實(shí)現(xiàn)：

實(shí)時(shí)消費(fèi)隊(duì)列：根據(jù)采樣規(guī)則寫(xiě)入Bloom過(guò)濾器，熱數(shù)據(jù)全量寫(xiě)入熱存儲(chǔ)。
延遲消費(fèi)隊(duì)列：根據(jù)Bloom過(guò)濾器實(shí)現(xiàn)條件過(guò)濾邏輯，冷數(shù)據(jù)寫(xiě)入冷存儲(chǔ)。

2、時(shí)間序列的異常檢測(cè)

時(shí)間序列的異常檢測(cè)一直是一個(gè)比較火的話題，尤其是針對(duì)具有時(shí)間周期特征的數(shù)據(jù)。

1）Gitlab方案

Gitlab在2019年分享了他們基于Prometheus實(shí)現(xiàn)的簡(jiǎn)單的異常檢測(cè)[32]，比如我們想判斷 t 當(dāng)前時(shí)間對(duì)應(yīng)的值 f (t) ，我們可以根據(jù)前三周的數(shù)據(jù)的中位數(shù)通過(guò)最近一周的增量進(jìn)行修正，得到當(dāng)前時(shí)間的預(yù)測(cè)值 f ' (t)。

其中增量 ?offset 是指最近一周的指標(biāo)的時(shí)間平均值與往前偏移offset 以后的時(shí)間平均值，比如 ?1w 是指最近一周的平均值與上一個(gè)周期的平均值之差（用PromQL表示為job:http_requests:rate5m:avg_over_time_1w - job:http_requests:rate5m:avg_over_time_1w offset 1w），用于補(bǔ)償周期之間的平均值變化。

2）其他的方案