一、引言

隨著分布式系統和微服務的日益發展，系統的開發和運維對于可觀測性的需求越來越迫切。可觀測性[1]一詞的來源最初是從控制理論中借鑒而來的。目前我們在談論可觀測性的時候，我們通常是指以下三個方面：

• 鏈路 Tracing
• 指標 Metrics
• 日志 Logging

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

二、收錢吧監控系統的歷史發展

收錢吧從在2017年開始逐步建設應用監控系統，系統建設主要的方向是提供鏈路追蹤(Tracing)以及性能監控(Metrics)兩方面的能力。

在監控系統的選型方面，我們盡量使用開源的系統：

• Tracing

我們選擇的是twitter開源的Zipkin[3]，它為我們提供了鏈路追蹤的后端系統，使用Elasticsearch作為Tracing的后端存儲。

• Metrics

我們在Tracing數據的基礎上，通過從Kafka中消費Zipkin格式的數據聚合得到分鐘級別的指標，時序數據簡單地使用MySQL作為后端存儲。

在接入層，我們采用最原始的方式，為各個Java的模塊、組件提供各種各樣的instrumentation工具包來進行埋點，業務研發同學以pom依賴的形式引用到自己的業務服務中，比如：

• 通過MySQL Driver提供的攔截器機制[4]來對MySQL數據庫的請求進行采樣；
• 通過封裝一個新的JSON-RPC包來實現對RPC層的埋點；
• 通過Spring的HandlerInterceptor[5]來實現Rest風格接口的攔截；
• 通過Spring AOP來進行Redis訪問的鏈路采集；
• ...

這套系統支撐我們走過了業務發展最迅猛的一段時間，為大量的問題排查和故障診斷提供了一些線索，然而業務開發逐漸開始對這套系統產生不滿，主要集中在以下幾個方面，

1）由于我們在初期采用MySQL作為底層時序數據的存儲，這在當時看起來是一個主流的方案[6]，但我們碰到了很大的性能問題，畢竟MySQL這類數據庫提供的存儲引擎并沒有對此類場景進行優化[7]。同時，MySQL并沒有提供豐富的針對時間序列的查詢算子。

PgSQL 9.6.2 數據插入的吞吐量隨著表大小的變化關系[8]。

在鏈路追蹤或者說應用監控的場景，我們需要的是高吞吐量以及線性的性能[9]，同時我們也需要增加數據的生命周期管理的功能：因為隨著新數據的寫入，歷史數據的價值會隨著時間的流逝而價值降低。

2）由于我們需要從Tracing數據反推得到指標數據Metrics，我們“魔改“了Zipkin傳輸部分的邏輯，對所有不采樣數據（Unsampled）在客戶端進行聚合以后批量上報，導致我們在Zipkin的升級方面產生了很大的困難。尤其是在https://github.com/openzipkin/zipkin/pull/1968，以后不再允許用戶定制開發服務端。

3）業務方升級依賴需要采集器組件升級支持，從而產生了額外的工作量。同時，也有大量的組件難以通過這種侵入性的方式進行支持，或者需要投入很大的人力成本來進行研發、適配。

三、新一代應用監控系統 - Hera

基于以上原因，我們決定研發一套新的系統來同時滿足幾個條件：

• 低存儲成本：能夠以低成本存儲較長周期的數據，對于指標能夠存儲至少四周，對于鏈路存儲一周，這讓我們排除了ElasticSearch這個選項；
• 高實時查詢性能、高靈活度：不再使用MySQL這類關系型數據庫作為時間序列的存儲，使用Prometheus或Prometheus兼容的存儲系統；
• 優化研發效率：使用字節碼編織技術，無侵入地進行埋點，并更緊密地與DevOps流程結合。

1、鏈路追蹤

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

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.

在一個Dapper鏈路樹中，各個Span之間存在因果和時序關系。

在鏈路追蹤的系統選型方面，我們對比了在當時比較活躍的幾個開源項目：

• Zipkin
• Apache/Skywalking v6.6.0
• Jaeger v1.16

Jaeger是Uber[11]在2016年開源的鏈路追蹤平臺，并捐獻給了CNCF云原生基金會。

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

Jaeger受到了開源社區的廣泛支持，比如：

• Istio[12]原生支持使用Jaeger增強Service Mesh服務網格的可觀測性；
• 服務網格的數據面實現Envoy[13]支持使用Jaeger作為鏈路追蹤的服務提供方；
• ...

1）鏈路追蹤后端系統和存儲的選型

我們重點考慮的是他們對于存儲系統方面的支持情況和擴展能力。

① 各個開源鏈路追蹤實現的存儲能力

Jaeger社區對于存儲的擴展性極佳，提供了基于gRPC的插件機制[14]，方便定制擴展。

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




       parent process                                        child sub-process

在存儲的具體選擇方面，我們在當時注意到了Aliyun SLS能夠支持作為鏈路追蹤的后端，并且官方提供了一個實現https://github.com/aliyun/aliyun-log-jaeger，我們內部基于這個思路實現了gRPC插件版本的SLS后端實現，目前穩定運行在生產環境。

• 存儲周期：SLS能夠提供長達30天的存儲周期。
• 存儲量：一天存儲的Span數量超過4億，使用約6TB存儲空間。
• 性能：在SLS Query界面進行條件查詢可以在3-5s以內返回結果。
• 成本：每天成本約為70元，一年約2萬元左右（大約為2臺8U32G的ECS的按年付費的價格）。

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

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

2）業務方接入優化

SkyWalking 的美妙不僅在于其強大的功能，還在于其優秀的代碼實現[16]。

在過去我們使用侵入性的方式提供應用監控接入，監控服務的提供方需要為各個業務方提供的插件、模塊，并且需要花費大量的精力來實現版本兼容性等工作，這種方式缺乏統一的切面和工作機制，需要對各個組件逐個”攻破”。Skywalking是華為的吳晟等人在2015年開源的一款APM產品，并成為Apache的頂級項目，Skywalking-Java使用了字節碼增強技術，提供了無侵入性的鏈路埋點，大大降低了使用成本。在Java中，常用的字節碼工具有以下幾種。

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

對于字節碼技術的具體分析可以參考StackOverflow上的回答[17]。

其中ByteBuddy的易用性和性能都達到一流的水準：

ByteBuddy官方提供的性能測試結果。

為了充分利用Skywalking-Java提供的插件，我們在OpenTracing的接口上實現了整套Skywalking鏈路追蹤的模型。具體來說，Skywalking的鏈路追蹤語義包括三層：

① Skywalking中的Trace與OpenTracing語義中的Trace類似

② Skywalking中的Span與OpenTracing語義中的Span類似

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

③ Skywalking增加了一層Segment的概念

一個Segment被約束在一個線程上，其中包含的所有AbstractTracingSpan 都在此線程上創建和銷毀。這里SegmentID對應于OT中的SpanID，在Skywalking中的Span 是按照創建的順序從0開始編號的。

當然模型上也有不同之處：

• 跨線程

OpenTracing的標準要求實現者將Span 設計成線程安全的，因為Span允許被跨線程傳遞。而在Skywalking中，跨線程是通過對當前Segment進行快照[18]實現的，而Span 在絕大部分場景下不需要保證是線程安全的。

• 異步

異步Span主要應用于記錄異步操作真正的起始和結束時刻。以Spring Reactive為例[19]：用戶編寫的Controller返回的是一個可被執行任務（通常是Mono類型），而不是最后的結果，Dispatcher會將任務通過線程池去執行，那么我們需要記錄的是真正這個請求從任務創建到被“計算“完成的整個周期。在OpenTracing標準中沒有提及這部分的實現。而Skywalking的多個插件中使用了這個機制，比如Redis客戶端Lettuce，Spring Webflux，Apache AsyncHttpClient等。

我們通過在OpenTracing接口上實現與Skywalking一致的語義從而實現幾乎零成本地移植并使用它所有的插件。我們在使用Skywalking-Java的過程中也發現了不少問題，也與社區積極地反饋，做出了一些貢獻，主要包括：

• JSON日志格式的實現：https://github.com/apache/skywalking/pull/5357
• Spring Kafka 1.x插件：https://github.com/apache/skywalking/pull/5879
• Spring DevTools支持和多類加載器優化：https://github.com/apache/skywalking/pull/6973
• Jedis Transaction支持：https://github.com/apache/skywalking-java/pull/57

3）服務依賴分析

服務的依賴分析在公司內部一直是業務開發迫切需要的功能，它在服務容量規劃、問題診斷和服務強弱性依賴判斷中都有比較實用的價值。在Jeager社區的實現中，推薦生產使用Spark批處理[20]的方式實現了全局的依賴分析，也有基于Flink的實時處理[21]，但已經沒有在維護狀態。

為了實現這個功能，我們使用了Apache Flink，通過消費Kafka中的鏈路數據，實時計算出服務之間的依賴關系，將Tuple<downsampled timestamp, caller, sub-caller, callee, sub-callee> 格式的數據通過OpenTSDB協議傳輸到我們的時序數據庫VictoriaMetrics 。

前端根據用戶提供的時間窗口，通過Java服務暴露的API進行上游/下游的查詢：

后續我們將在用戶交互和調用量的分析展示方面進行進一步的優化。

2、指標監控

在老版本的監控程序中，我們使用了關系型數據庫作為時序數據的存儲系統，使得我們在查詢的靈活性和性能方面遭遇到了很大的瓶頸，我們有必要在新系統設計的時候去進行一定的反思。在過去幾年中，云原生的概念逐漸深入人心，而Prometheus是云原生時代監控的事實標準。

在進行了一些調研之后，我們認為單機版本的Prometheus并不能支撐超過百萬級別活躍的指標和超過一周的數據存儲。我們的目光主要聚焦到了Thanos、Cortex和VictoriaMetrics，在國內技術社區分享比較多的是Cortex和Thanos，但我們對比發現Cortex的架構非常復雜，對系統運維提出了新的挑戰，而Thanos也有一定的運維復雜性，且由于使用對象存儲（S3等）作為冷數據存儲，查詢可能存在一部分服務不可用導致返回部分數據。同時，我們也發現國內的知乎在QCon 2020[22]上分享了他們使用VictoriaMetrics的經驗。我們基于以下原因最終選擇了VictoriaMetrics。

• VictoriaMetrics在各項性能測試[23]中都表現卓著；
• 作者Aliaksandr Valialkin精于Go語言的性能優化，是fasthttp等高性能Go語言組件的作者；
• 最重要的是VM的集群架構簡單，易于運維。

VM的各個組件都是獨立的，可以水平擴展，只有核心的vmstorage是有狀態的，其他組件均是無狀態的。

1）推還是拉 (push or pull)

對于指標類的數據，采用主動推還是被動拉的模式，一直以來都是存在較大的爭議[24]。我們與Prometheus一樣使用推的模式，基于以下原因，

• 服務發現?

一個詬病Pull模式的原因是認為Pull模式需要大規模的服務發現，但這一問題在Kubernetes上反而不存在任何問題，我們借助CRD[25]可以很輕易地實現服務抓取目標的定義。同時可以將Pod，Service上的標簽附加到指標上，幫助查詢的時候區分實例，服務所屬的業務團隊等。反而，這在Push模式中是不容易實現，或者需要業務研發去改造的。

• 問題排查?

當指標查詢失敗的時候，我們通常需要去判斷到底是哪一步出了問題。在Push模式中，我們需要去檢查業務的代碼和日志來判斷問題。然而在Pull模式，我們可以手動在瀏覽器中去請求指標暴露的接口（比如/metrics ）就可以判斷服務的健康狀況，業務是否正常導出指標。

目前我們使用VictoriaMetrics的一些統計信息：

• 存儲周期60天，共有6990億個數據點，占用磁盤空間800GB；
• 活躍時間序列約500萬，數據點插入的QPS約13萬每秒；
• 范圍查詢的P99線平均值約為1.5s。

我們也自研了查詢面板，以限定查詢的時間范圍（最長3天）和查詢的模式（針對服務job查詢）。

我們自研了一些重要的指標插件，其中在應用性能分析、故障定位中比較實用的維度有：

• Servlet容器指標：Tomcat忙碌線程數，百分比；
• 數據庫連接池指標：支持HikariCP和Alibaba/Druid連接池，等待連接池的線程數，數據庫連接獲取時間，數據庫連接池使用占比；
• 緩存指標：支持Redis，Caffeine和EhCache。緩存命中率；
• Kubernetes監控：Pod CPU、內存使用量，我們也在系統中也集成了Kubernetes事件的查看和搜索。

由于公司部分核心服務還使用Docker部署在ECS上，我們在VictoriaMetrics中實現了基于Dockerd API的服務發現機制[26]，也已經合并到社區版本。

3、全面擁抱云原生

在2020年，Kubernetes已然成為了分布式操作系統的事實標準，公司內部的絕大多數服務也已經全面遷移到自建的Kubernetes集群。為了更好的利用新特性，我們在2020年中啟動Kubernetes的集群升級計劃，將集群升級到1.16版本（目前已經升級到1.20），并遷移至阿里云的ACK托管集群。監控系統的落地將全面依賴于Kubernetes系統。

1）我們提供Docker鏡像版本的Java Agent，方便業務開發接入。

2）在生產環境，我們使用InitContainer[27]在容器啟動階段注入Java Agent，兩者之間通過貢獻的EmptyDir[28]來傳遞Agent Jar包。這便于我們在生產環境中靜默升級Agent版本：即使Agent在生產出現問題，我們可以快速修復問題，然后升級初始化容器即可。

3）時序數據庫VictoriaMetrics的運維和Jaeger組件的運維也是通過Kubernetes Operator實現的：

• 我們對jaeger-ingester和jaeger-collector組件啟用了HPA，即基于CPU和內存使用率的水平動態擴容。
• VictoriaMetrics集群版本的各個組件也是通過Kubernetes operator[29]進行維護的。

四、展望

1、后采樣的實現

由于我們目前采樣的是頭采樣（Head-Based Sampling）方案，一旦在鏈路中間的服務發生拋出異常且這條鏈路沒有被采樣，那么就會出現有錯誤日志和報警，但鏈路追蹤系統無法查詢到這條鏈路的情況，這給開發排查問題帶來很大的阻礙。目前，業界有幾種典型的實現方案，

1）OpenTelemetry方案

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

OT社區的tailsampling方案[30]主要來自于Grafana公司的貢獻[31]，同時可以利用以下幾個processor和exporter實現高伸縮性。

• （第一層）loadbalancingexporter：把屬于同一個TraceID的所有Trace和Log分發給一組固定的下游Collector；
• groupbytraceprocessor：等待足夠長的一段時間，將屬于一個TraceID的所有Span(s)打包傳遞到下游；
• tailsamplingprocessor：通過預定義的組合策略進行采樣。

2）字節跳動方案

發生錯誤的服務將采樣決定強制進行翻轉，如果這條鏈路沒有進行采樣的話。但這樣的話會丟失采樣決策改變之前的所有鏈路以及其他分支鏈路的數據。

3）貨拉拉方案

基于Kafka延遲消費+布隆過濾器實現：

?

• 實時消費隊列：根據采樣規則寫入Bloom過濾器，熱數據全量寫入熱存儲。
• 延遲消費隊列：根據Bloom過濾器實現條件過濾邏輯，冷數據寫入冷存儲。

2、時間序列的異常檢測

時間序列的異常檢測一直是一個比較火的話題，尤其是針對具有時間周期特征的數據。

1）Gitlab方案

Gitlab在2019年分享了他們基于Prometheus實現的簡單的異常檢測[32]，比如我們想判斷 t 當前時間對應的值 f (t) ，我們可以根據前三周的數據的中位數通過最近一周的增量進行修正，得到當前時間的預測值 f ' (t)。

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

2）其他的方案

• Prophet - 攜程實時智能異常檢測平臺實踐[33]
• 外賣訂單量預測異常報警模型實踐[34]

從業界發展的大勢來看，通過大數據、AI手段對系統異常進行檢測也是大勢所趨。