背 景

容器、Serverless 編程方式的誕生極大提升了軟件交付與部署的效率。在架構的演化過程中，可以看到兩個變化：

• 應用架構開始從單體系統逐步轉變為微服務，其中的業務邏輯隨之而來就會變成微服務之間的調用與請求。

• 資源角度來看，傳統服務器這個物理單位也逐漸淡化，變成了看不見摸不到的虛擬資源模式。

從以上兩個變化可以看到這種彈性、標準化的架構背后，原先運維與診斷的需求也變得越來越復雜。為了應對這種變化趨勢，誕生一系列面向 DevOps 的診斷與分析系統，包括集中式日志系統（Logging），集中式度量系統（Metrics）和分布式追蹤系統（Tracing）。

服務觀測體系的基礎

日志、監控、分布式追蹤

Logging，Metrics 和 Tracing 有各自專注的部分。

• Metrics 的特點是：它是可累加的，具有原子性，每個都是一個邏輯計量單元

• Logging 的特點是：它描述離散的 (不連續的) 事件， 非結構化的數據。

• Tracing 的最大特點就是：它在單次請求的范圍內，處理信息。 任何的數據、元數據信息都被綁定到系統中的單個事務上。

以比喻手段來說的話，日志數據就是系統中的一個個點，追蹤數據則是系統中一條條線，而監控數據則是系統中一個個面。

通過日志、監控、追蹤服務我們才能全面實時地觀測服務運行狀態 ; 我們通過日志來查看服務運行中的各個正常和異常的事件, 通過監控來觀察服務的總體指標是否符合預期, 通過追蹤來確認服務的上下游依賴是否正常。

同時我們需要注意到日志、監控和追蹤的數據不是完全獨立的，而是互有交集的。一個事件可能是一個可以被量化的指標，也可能是一個請求維度內的數據，日志、監控和追蹤間的數據是互通的，通過不同數據間的聯系我們從而將日志系統、監控系統、追蹤系統互相打通，方便業務研發跳轉于各個系統間，快捷且深入地來排查問題。

我們可以通過一次具體排查問題的流程來看它們的數據是如何打通的

• 收到報警: 最開始服務觸發報警然后發送告警出去, 比如某個監控指標超過閾值

• 報警 =>監控: 報警信息里會攜帶監控面板的 URL, 點擊就可以跳轉對應監控指標面板, 查看監控數據的時間變化趨勢

• 監控 =>日志: 通過監控中的關鍵字 (如錯誤信息, URL 等), 可以直接跳轉到日志系統中直接查詢出服務日志包含關鍵字的日志

• 監控 =>追蹤: 通過監控中的請求信息 (如 URL, 錯誤碼等), 可以直接跳轉到追蹤系統中, 查看包含對應請求信息的失敗請求鏈路

• 日志<=>追蹤: 日志與追蹤數據通過 RequestID 互相打通, 服務日志中均包含了請求的 RequestID 點擊可以直接跳轉到對應的追蹤頁面, 在追蹤頁面處可以點擊服務名稱查看對應的所有鏈路日志, 上下游服務對應的請求日志也支持從追蹤頁面跳轉查看, 方便上下游間研發交流和排查問題

服務觀測體系的規模

當前作業幫服務觀測體系上支撐著海量日志、監控和追蹤數據的流轉

• 日志: 支持峰值每秒 4000W+ 的日志數據流通, 每天處理萬億量級的日志數據, 每天的日志數據 PB 級

• 分布式追蹤: 支持峰值每秒 1000W+ 的追蹤數據流通, 每天處理千億量級的追蹤數據, 每天的追蹤數據 TB 級

• 監控: 支持峰值每秒 800W+ 的監控數據流通, 每天處理 5 千億量級的監控數據, 每天的監控數據 TB 級

通過以上數據說明，作業幫服務觀測體系的建設在互聯網企業有一定的代表性的。

服務觀測體系的技術方案

日志

作業幫所有服務節點都會部署自研的 log-agent 組件來采集服務、中間件和節點的日志。

在日志采集后，通過 Kafka 做日志數據傳輸，后端同時對接著大數據、日志檢索、業務監控等多個消費服務。

最后，所有日志數據最終都會上傳到對象存儲中，以 zstd 的格式壓縮保存。

監控

作業幫的監控系統圍繞 Prometheus 進行構建，Prometheus 當前已經是云原生監控的事實標準。它在作業幫的監控體系里承擔著數據采集的角色, 并將監控數據實時寫入到 VictoriaMetrics 時序數據庫中。

Prometheus 模塊本身不做數據持久化, 從而保證了整個 Prometheus 服務是無狀態的, 如果發生機器宕機可以快速自愈。

為了應對龐大的監控數據量, 我們通過 hashmod 的方式對 Prometheus 進行了分片, 按數據量的大小在集群內部署一個或多個 Prometheus 實例。

VictoriaMetrics

我們使用 VictoriaMetrics 做為監控數據的持久化存儲。選擇它主要有 3 個原因:

• 兼容 Prometheus 的查詢語句: 可以像 Pormetheus 一樣使用它, 從而做到對外無感透明

• 高性能: 相比其他主流的時序數據庫, 有著更高的性能和更少的內存使用

• 高壓縮率: 能更有效地使用存儲空間, 這個能減少存儲監控數據使用的機器成本

分布式追蹤

追蹤體系在作業幫內部落地時, 采用了 jaeger 作為底層來采集服務請求, 用 Kafka 來傳遞追蹤數據, 最后將追蹤數據寫入到 clickhouse 中保存,。

同時還有拓撲分析服務對接著流式追蹤數據，提供實時的服務拓撲分析聚合數據，以時序數據的方式保存在 prometheus 中。

服務觀測體系落地的核心要素

成本低廉

成本在服務觀測體系落地上至關重要，一般來說服務觀測成本不能超過業務總體成本的 15%。但是對于大部分企業來說實際應該位于 10% 以下才能說服決策者進行大規模應用。比如全量而非采樣進行分布式追蹤采集，日志保存時效長短。這些數據對后期高級觀測能力的效果至關重要。

作業幫在成本優化上幾個探索：

日志檢索服務通過自研分布式計算替代 ES

ELK 是大部分公司日構建志體系的基礎方案，但現在隨著服務和流量的增長，在海量日志數據場景下顯得越來越力不從心。最主要的問題在于 ES 上，ES 是一個搜索引擎，會付出大量的資源用于索引的構建和維護，以提升檢索速率，最終形成數據膨脹。

日志檢索是一個明顯的寫多讀少的場景，絕大部分日志在寫入后可能就沒有任何訪問。為此構建大量索引帶來的問題就是寫入性能劣化，同時也會導致日志數據的膨脹，這些都會帶來額外的成本開銷。另外日志檢索是一個時延不敏感的場景，查詢多花一秒少花一秒對用戶體驗不會有大的影響。

作業幫的日志檢索系統就是基于 indexless 的方向設計實現的。在日志寫入階段，不會對日志做解析格式化，而是直接批量寫入到文件中，以實現最大的寫入性能。日志文件則會按塊切分并壓縮，每個壓縮日志塊大小保證在 8M 左右，同時會按時間、所屬服務、實例名、日志類型等數據為日志塊編制索引。通過這種設計，單核可以支持 50MB/S 的日志寫入。

在用戶查詢時，日志檢索系統會基于檢索條件圈定符合條件的日志塊，然后并發對這些日志塊數據做全文檢索。如果檢索的并發量足夠，即是全文檢索也能保證一個相對短的查詢時間。作業幫的檢索系統可以支持 1TB 的日志在 10s 內完成查詢。

日志采集組件性能優化

眾所周知大部分互聯網企業的用戶流量非常巨大，并且有明顯的高低峰，高峰時單臺機器的日志寫入可以到 1GB+/S，并且后端的日志鏈路要求傳輸時延要保證在 10S 內。

面對這種需求，市面上的日志采集器都難以滿足需求，為此我們自研了日志采集器。主要做了以下幾點優化：

• 第一個是優化了 json 解析邏輯, 容器記錄的日志默認就是 json 格式并且格式都是固定的, 我們選擇通過字節處理的方式實現日志的對反序列化

• 第二個是優化容器的生命周期監聽, 基于節點 kubectl 實現 pod 生命周期監聽和元數據獲取，避免了連接 apiserver 和頻繁獲取的開銷

• 第三個是針對容器的采集場景進行優化, 讓采集流程更加輕量化, 降低采集器的開銷

• 第四個我們保證了每個采集協程資源隔離, 避免資源競爭的情況, 從而不會出現一個 Pod 日志量太大影響到其他 Pod 日志的上送

如此, 全新的采集器單核可以支持 100MB/S 的采集速率, 上線后單機的采集性能提升 3 倍, 采集所使用的 CPU 降低了 70%。

分布式追蹤使用 clickhouse 替代 ES

作業幫的分布式追蹤采用的是 100% 采樣的策略，這樣就導致了線上的追蹤數據量極其龐大，特別是在晚高峰的時候。作業幫最早存儲追蹤數據使用的是 ES，實踐發現 ES 的寫入性能不夠理想，在高峰時總是出現寫入延遲的情況，影響追蹤服務的正常使用。

為此我們調整了 jaeger 服務的寫入和查詢代碼，增加了 clickhouse 的實現，將數據的存儲遷移到了 CK 上，得益于 CK 的高性能索引和存儲設計，系統性能有了很大的改善：

• 寫入性能提升了 40%

• CPU 使用下降了 80%

• 磁盤占用降低了 50%

• 整體成本降低為之前的 20%.

穩定可靠

日志可靠性

日志可靠性最重要的就是保證日志不丟失，丟失日志會直接影響到監控、統計、BI 的數據準確性。

為此我們建立了端到端的監控指標，在采集端按日志輸出時間統計每個時間段內發送的日志數量，又在消費端同樣按日志的輸出時間統計每個時間段內接受的日志數量，保證了統計口徑的一致， 不會因日志傳輸延遲而影響統計。

日志 SLA 全年可以保證在 6 個 9 以上。

監控可靠性

監控可靠性的核心在于存儲，存儲層需要保證高可用，監控數據的延遲和失敗都是不可接受的，會直接影響到監控告警的準確性。

為此我們在 VictoriaMetrics 上新增了一層 Proxy 組件，用于代理 prometheus 的讀寫流量，基于 Proxy 實現了存儲多活、歸檔數據降準、指標自動老化等能力，去掉冗余的監控數據，并通過多活自動切換機制保證監控數據高可用。

監控 SLA 全年可以保證在 5 個 9 以上。

追蹤可靠性

相比于日志和監控，對于追蹤數據的可靠性要求會相對低一點，我們主要依賴 ClickHouse 來保證數據可靠性。

• ClickHouse 更優的穩定性：相比于 ES，CK 的的運維成本相對更低，其架構設計使得日常維護相對簡單。

• ClickHouse 多副本機制：單點宕機不會影響系統可用性。

追蹤 SLA 全年保證在 4 個 9 以上。

無感全覆蓋

日志全采集

• 應采盡采: 日志系統會對系統內的所有日志均進行采集，包括服務日志、中間件日志、系統日志，保證系統中所有發生的事件都能被回溯。

• 平滑接入, 支持各種語言, 支持非結構化日志：服務可以無感知地接入整個日志系統，對接入的日志格式不做要求，無需調整日志模塊，日志對服務來說是一個透明的基礎設施。

• Serverless 覆蓋：云廠商的 serverless 虛擬節點上不支持部署自定義的采集器，為此我們實現了多云上的 daemonset 自動注入能力，serverless 上的 pod 會自動注入日志采集邊車，做到無感的采集覆蓋。

監控自下而上

作業幫內部的監控指標主要有以下幾大類:

資源監控

支持了 Pod 和 Node 的 CPU、內存、磁盤、網絡和 GPU 監控，同時會對機器中的內核參數選擇性地進行采集和記錄

系統監控

采集了 K8S 系統中的各項指標, 包括 apiserver, etcd, k8s 調度器等數據 ; 同時依賴的各種組件和中間件 (Ingess, Egress, DNS 等) 也會統一監控。

存儲監控

作業幫內部使用最廣泛的存儲有 mysql, redis 和 ES; 通過對其數據 Proxy 的監控, 提供了存儲視角的監控數據。

Runtime 監控

作業幫內部通過框架收斂讓服務暴露了 Runtime 監控數據, 通過持續的 Runtime 監控數據可以更深入地來定位內存泄漏、CPU 打滿等深層問題

流量監控

作業幫的所有服務都會接入 ServiceMesh, 通過 ServiceMesh 的監控我們可以看到服務所有出入流量的數據, 包括了 QPS, 請求 / 響應耗時, 成功率, 狀態碼分布和失敗情況等數據

MQ 監控

消息隊列作為服務異步通信的核心, 它的健康情況也緊密關系著服務的可用性。通過 MQ-Proxy 和統一框架, 我們支持了服務對 MQ 使用情況的監控, 包括消息生產 / 消費數量, 生產 / 消費失敗, 消費延遲及死信數量等數據。

服務監控

通過一致的框架提供了基礎的異常監控 (服務 panic, 服務 core) 和業務結果碼分布的數據。如果服務有更進一步的業務監控需求，也支持暴露 metrics 指標接口來接入監控體系。

在以上監控指標的落地上, 我們優先選擇通過暴露 Metrcis 來采集，K8S 的組件原生都支持 Metrcis 接口, 而我們自研的各種組件和中間件 (gpu-exporter, mysql-proxy, redis-proxy) 也盡量遵循了這一標準。只有在時延非常敏感的模塊上，如 Ingress 和 Egress, 通過日志來采集數據。

追蹤全采樣

追蹤上我們采用的是全采樣的策略, 這樣當研發遇到問題時可以通過 requestID 直接查看請求鏈路定位問題了。當前提供了 3 種追蹤數據采集方式

• 基于 Mesh 的服務出入流量采集：作業幫 ServiceMesh 組件會對服務的所有出入流量進行埋點，并自動上報到追蹤系統中。這種接入方式不受語言限制，對服務透明，只要服務有請求皆可在追蹤鏈路中體現。

• 基于框架的存儲流量采集：因為 mysql 和 redis 等存儲的請求對于時延敏感，作業幫內部在框架上做了統一埋點，基于存儲訪問日志的形式上報相關追蹤數據。這種接入方式同樣對于服務無感，可以完成存儲流量的覆蓋。

• 基于 SDK 的業務行為打點：上述埋點策略可能無法覆蓋到服務內部的業務操作部分。對此我們提供了 SDK，服務可以基于 SDK 生成打點數據并自動上報，從而完成業務操作的追蹤覆蓋。

通過這 3 種埋點方式及全采集的策略，追蹤系統可以覆蓋到服務和流量的方方面面。

結 語

以上就是作業幫對于整個基礎觀測能力的一個整體介紹。在基礎觀測能力上我們認為后續要圍繞著這幾個方向繼續演進：

• 更低廉的成本

觀測的核心成本在于存儲，而進一步降低成本的關鍵我們認為就在于存儲介質的演進。在日志的存儲實踐后上我們認為對象存儲是一個理想的存儲介質，支持多副本，數據歸檔，無限擴展等能力。后續我們也計劃將監控和追蹤的存儲與對象存儲做整合，系統上存算分離，擁有更低廉的成本和更好的擴展性。

• 更廣泛，更透明的覆蓋

當前的觀測數據中有不少對語言和框架還存在著依賴，理想中基礎觀測需要對所有服務提供一致的觀測體驗，是一個透明層，并覆蓋所有服務的核心指標。作業幫后續會在 ServiceMesh 尋求觀測能力的進一步拓展，提供出一個不限制語言的觀測基礎能力。

• 高級觀測能力演化

在有了完善的觀測數據后，我們就可以在這些數據上進一步挖掘探索高級觀測能力，當前作業幫已經開始做故障預測和根因分析能力等能力的探索和落地。