近幾年，“可觀測”是一個熱門的話題。作為積極擁抱微服務架構的企業，作業幫團隊在快速的業務拓展中，解決了一個又一個隨之而來的技術挑戰。

日前，在51CTO主辦的WOT全球技術創新大會上，作業幫基礎架構部資深架構師莫仁鵬帶來了主題演講《作業幫服務觀測體系建設與實踐》，基于多年來作業幫云原生建設的實踐經驗和成果，分享了作業幫團隊在構建服務觀測體系的過程中的創新思考。

本文將摘選其中精彩內容，統一整理，希望為諸君帶來啟發。

服務觀測的流量挑戰

眾多周知，服務觀測來源于近年來很流行的一個詞：Observability，即可以由其外部輸出推斷其內部狀態的程度。

具體來講，“可觀測”主要分為三個部分。首先是日志，它主要是涉及到單個離散的事件。第二是監控，它是可聚合、按時間維度變化的狀態。第三是Tracing，是單次請求范圍內的信息。

服務觀測最大的難題就在于流量挑戰。目前，作業幫的日志數據量已達到了峰值百GB/s的級別，每天的日志大小在PB級左右，整體的監控數據量在千萬級/s，追蹤數據量也是在千萬級左右。

因此，構建一套高可用、高擴縮、低成本的一套服務觀測體系，勢在必行。

日志體系

在觀測體系中，日志部分是大家接觸最多的，也是最重要的一環，它有四個目標：

• 第一，高可用。因為許多下游業務，如業務服務的監控、業務數據的報表、大數據模型訓練等都對會對日志的可用性要求很高，甚至要做到一條數據也不能丟失。
• 第二，高吞吐。特別是在作業幫內部場景中，它的高峰流量可能是低峰流量的10倍以上，這就要求我們有足夠高的吞吐性能。
• 第三，低延遲。下游的部分日志消費服務他們對延遲要求也很敏感。
• 第四，低成本。日志的數量巨大，想要長期保存它們，就需要用足夠低成本的保存方式。

下圖是作業幫整個日志體系的架構。

第一，日志輸出的部分。跑在K8s中的服務，都是一個個容器，容器首先會把日志輸入到容器的日志文件中，然后在每個機器和節點上會部署一個日志采集的服務，由它來負責采集每個容器的日志。采集完成后，全部的日志將上傳到Kafka，并通過Kafka完成日志的傳輸。

接下來是日志的處理和消費，主要涉及到：日志的存儲和檢索，日志監控、日志追蹤和大數據部分。

最后，在存儲部分，作業幫最終是采用了對象存儲的方式。

接下來，重點分析下日志輸出、采集、處理、消費、存儲的構建過程。

日志輸出方面，作業幫所有服務都采取了標準輸出的模式來打印日志。對于老服務，引入了日志邊車模式來幫助完成標準輸出的改造。主要流程是通過一個管道文件：服務容器將日志寫入管道文件，然后日志邊車從管道文件中讀取并打印到標準輸出中。標準輸出的好處包括統一日志輸出方式、服務不需要管理日志的生命周期、采集友好、以及知曉日志的輸出時間。

日志采集方面，作業幫最初使用Filebeat，但遇到了一些問題，如可用性、穩定性和性能方面的問題。因此，采用了自研的方式進行優化，包括優化json解析邏輯、降低獲取容器元數據的開銷、更輕量的采集邏輯以及更好的采集隔離。最終的性能表現是支持單核75B/S的采集速率，提升了三倍的單機采集性能，并且采集整體使用的CPU下降了70%。

傳輸方面，作業幫重新設計了消息分裝格式，按照依賴Kafka的Header模式，將各種日志的元數據放到Kafka消息的Header中，然后在body中保存日志原文。這樣下游可以不用關心日志的分裝格式，從而省去了序列化與反序列化的開銷。在Header中保存各種數據信息，也可以幫助各個日志下游提取需要的日志信息。

日志檢索方面，莫仁鵬重點介紹了ELK這套方案在日志檢索中經常遇到的幾個問題，如要求結構化數據、寫入性能低、運行成本高和存儲成本高等。然后重新審視了日志檢索的場景特點，包括非結構化數據、寫多讀少的場景、查詢時延不敏感以及數據規模比較大。

這里值得注意的是，日志檢索的理想方案應具備以下特點：

• 不需要對日志建立索引，也不需要對各種日志做反序列化，去做結構化的存儲。查詢操作是全文檢索，但通過分布式和并行化處理，檢索速度可以滿足需求。
• 日志按塊存儲，每個日志塊是一類日志的聚合，例如某個pod在某段時間內的日志都會寫入一個日志塊中。
• 通過并行檢索的方式，按照服務名稱、時間、機器名稱等標簽建立索引，可以通過選擇查詢條件，一級索引快速呈現所需的各類日志塊。

基于此，作業幫提出了一套可以實際落地的新方案，旨在更好地滿足微服務場景下的日志檢索需求。新方案包括以下組件：

• Ingester組件：負責寫入各個日志塊，并將索引信息寫入數據庫。
• 查詢組件(query-proxy組件)：負責接收用戶查詢命令，分發給各個不同的查詢組件，并返回最終結果給用戶。
• query組件：在本地存儲中完成各個檢索命令，返回結果給proxy組件。
• manager組件：負責管理機器上的日志塊生命周期，包括上傳本地存儲的日志塊到對象存儲、從對象存儲下載日志塊到本地存儲、淘汰過期的日志塊等任務。

日志存儲方面，作業幫采用了分級存儲的方式。首先，日志塊被寫入到本地存儲中。一旦超過一定時間，這些chunk會被按照策略上傳到對象存儲中，并以壓縮的方式進行保存。對象存儲主要用于長期存儲，超過一定時間的日志塊會被統一歸檔到歸檔存儲中。

為了提高檢索效率，涉及到日志沉降的概念。如果只需要檢索近幾個小時的日志，可以直接在本地存儲中完成;如果需要查詢更早時間的日志，則需要從對象存儲甚至歸檔存儲中取回歸檔日志進行檢索。

在成本方面，本地存儲的成本最高，而對象存儲的成本大約是本地存儲的1/3，歸檔存儲的成本是本地存儲的1/10。此外，對象存儲和歸檔存儲中的重要日志都是以zstd壓縮的方式保存，進一步降低了存儲成本。

總體來說，該日志檢索方案具有以下優勢和表現：

• 方便接入：對日志格式沒有任何要求，所有云原生服務都可以默認接入。支持shell查詢命令，客戶無需額外學習成本。
• 高吞吐：由于不對日志進行反序列化或全量索引，單核可以支持50M/s的日志寫入。
• 成本低：采用分級存儲方式，通過zstd壓縮保存日志，相比傳統存儲方式可以降低一到兩個數量級的成本。
• 速度快：采用分布式并行檢索，支持橫向擴容。可以在30秒內完成1TB大小日志的檢索。

監控體系

這里，我們把監控主要分為三個部分。

第一是集群監控。主要包括：一是系統監控，系統監控主要是K8S事件、K8S組件、APIServer和Etcd的各種指標;二是資源監控，主要是涉及到pod和Node的各種資源使用;三是網絡監控，主要涉及到節點和各種網絡延遲;四是基礎組件監控，會涉及到各種注冊發現、服務觀測組件;五是中間件監控。

第二是服務監控。主要涉及到對服務pod上各種指標進行監控，主要分為兩部分。第一是Runtime監控，主要會涉及到各種運行時和各種語言的指標。第二是自定義監控，我們可以支持業務暴露Metrics接口，以供Prometheus采集，實現業務的自定義指標。

第三是流量監控。由于業務流量上會對時延敏感，不便直接做埋點，作業幫是統一通過消費日志的方式來完成流量方向的監控，主要涉及到指標包括：其一是入流量，即請求QPS、請求時延、成功率、錯誤碼數量等指標;其二是出流量，主要是觀測服務對于數據庫、緩存、依賴服務等流量的整體監控指標;其三是網關監控，涉及到QPS時延和請求碼數量等相關監控;其四是異步流量的，也就是消息隊列，主要涉及到生產/消費QPS、生產/消費耗時、消費延遲的一些指標。

通過上面這些指標，可以觀測到平臺側以及資源層、服務層的各種監控指標，進而了解所有服務的運行狀態。

在監控采集方面，Prometheus當前是云原生監控領域的一個事實標準，它有著高效的時序數據存儲，單次可以處理大量的數據。這里也有一個問題，它是單機部署的，不支持集群化部署，遇到數據持久化甚至是大數據量的監控數據持久化上，可能就無法滿足我們的要求。我們通過引入時序數據庫方式來解決這個問題。

Prometheus會把監控數據通過Remote Write的方式寫入到時序數據庫中。接下來所有的對于監控數據的讀取操作都是在時序數據庫中進行的，主要包括在Grafana上的各種數據展示、告警以及對于監控數據的一些API的訪問。

監控存儲方面，我們選擇用Prometheus，并用Metrics作為時序數據庫存儲，主要是基于以下幾個點考慮。第一，它兼容Prometheus，它可以支持Prometheus的各種查詢語句，下游也可以把它當做一個Prometheus來使用。第二，它的架構比較簡單，方便做各種橫向的擴展。第三，它的數據壓縮率比較高，平均每個點位會占用32B左右。第四，它支持高吞吐，它單核可以支持6W/S的監控數據的寫入。

在使用VM的過程中需要注意數據容量的問題。因為監控數據的保存時間要求比較高，整個存儲就成了一個瓶頸。這可以通過降準的方式來解決。

事實上，監控場景也是有明顯冷熱之分，研發人員最常訪問的是一個月內的監控數據，在一個月外的監控數據就較少訪問了。基于這個思路，就可以把監控數據做一個標準和降準的區分。降準即原來10秒打一個監控數據的點，會被改造成為100秒打一個點。

具體實現方式上，首先通過Prometheus來完成寫入，在寫入前使用一個proxy來完成它的代理，同時在proxy上就可以會做一個降準的操作，按比例把所有的寫入點做一個抽樣;然后分別把抽樣前的數據和抽樣后的數據寫入到不同的VM存儲中;最后Select組件會按照時間把不同的請求做一個拆分，打到不同的VM集群中，最后做一個聚合，返回給前端用戶。通過這種方式，就可以把我們一個月前的數據做一個標準存儲，一個月后的數據做降準存儲。

值得一提的是，落地了這種方式之后，我們在整體的存儲成本下降了80%左右。

追蹤體系

隨著微服務的興起，單個請求可能需要跨越多個系統和服務，一旦某個服務或網絡出現延遲，可能導致整個請求出現問題。因此，需要一種能夠觀察和追蹤整個請求鏈路執行情況的方式，這就是追蹤體系的作用。

追蹤體系主要分為采集、處理和分析三個部分。

其中，采集部分通過邊車、服務和日志三種方式獲取追蹤數據，其中邊車和服務數據通過Agent和collocter上報到Kafka，日志數據則直接投遞到Kafka;處理部分使用Clickhouse作為存儲，并引入Ingester和Query組件以支持寫入和查詢操作;分析部分則包括服務拓撲分析和請求鏈路分析，通過統計聚合追蹤數據來形成可聚合的指標，并使用Prometheus進行時序數據的采集和存儲。

關于采集方式，具體分為兩種：

邊車上報：在邊車上進行埋點，將各種服務RPC流量進行打點，通過Agent的方式完成上報。這種方式只能觀測到服務邊界上的流量，對服務內部的流量無法深入。為了解決這個問題，引入了服務上報的方式。

服務上報：服務可以通過接入SDK的方式完成上報。對于部分流量或服務不好接入的情況，可以通過日志方式完成上報，例如各種訪問DB流量、訪問緩存流量以及異步流量(如消息隊列、生產和消費)。

在數據存儲方面，最初使用ElasticSearch，但遇到了寫入性能不足和數據壓縮率不理想等問題，導致整體集群成本很高。后來切換到Clickhouse后，存儲性能和效率大幅提升，單核可以支持1.5W/s的磁盤寫入，整體存儲集群的寫入性能提升了40%，CPU的使用下降了80%，磁盤占用下降了50%左右。這使得整體的存儲成本可以下降80%左右，是之前的1/5。

最后是關于服務的追蹤分析：通過追蹤服務的請求，可以獲得服務間的依賴關系，構建出一張服務拓撲圖。從服務的維度對這些追蹤數據做統計分析，可以支持實時服務拓撲圖查看以及請求鏈路分析。請求鏈路分析可以展示核心鏈路服務的調用次數、依賴的新增情況以及請求鏈路中是否存在閉環。這些功能可以幫助研發人員更好地了解服務的運行狀態和潛在問題。

總結來講，追蹤體系通過采集、處理和分析三個主要部分來解決微服務中的問題定位和瓶頸發現等挑戰。通過引入高效的存儲和數據分析方式，以及提供豐富的服務追蹤分析功能，可以幫助研發人員更好地了解服務的運行狀態和性能表現，及時發現和解決問題。

Serverless可觀測的前瞻思考

在Serverless服務觀測的實踐方面，作業幫面臨著高擴縮的問題，高峰時期的流量是低谷時期的十倍以上，為了降低運行成本，決定將服務統一套入到Serverless上運行。然而，在Serverless上直接部署觀測組件并不容易。云廠商為此提供了觀測解決方案，但仍存在一些問題。

首先，日志方面，我們一般會通過云廠商的日志采集器統一完成采集，投遞到Kafka。不同云廠商提供的采集器功能不一致，而且功能不夠全面，對于投遞方式和數據的分裝方式可自定義程度不夠多，不太能夠滿足采集需求。

對于監控方面，需要重點關注Serverless pod的資源指標，如CPU和內存的使用。這些資源都會暴露在虛擬節點上，可以通過Prometheus來采集這些Metrics接口。

最后，追蹤方面，當前云廠商不提供采集的支持，需要對服務和架構去做自身適配。

為了解決這些問題，作業幫團隊采用了容器注入的方式，統一解決Serverless上的服務觀測問題。通過聲明DS編排，云廠商將各個DS編排注入到容器中，例如日志組件、日志觀測組件、追蹤采集組件等，注入到Serverless運行的pod中。這種方式類似于邊車的方式，但無需在編排中做額外聲明，服務編排無感。此外，作業幫團隊還通過注入自己的采集組件，并針對自主架構在組件層面為多家云廠商做適配，同時支持自定義的采集策略，通過agent完成采集，在底層實現了采集鏈路的統一。

最后，有了全景的觀測數據之后，還需要建立起一套服務評價體系，通過統一的標準評價服務質量的好壞。

利用觀測數據建立了服務評價體系，通過統一的標準評價服務質量的好壞，從而幫助

研發人員發現和管理那些微服務中“無法察覺的角落”。

作業幫團隊目前主要依據服務觀測的指標建立服務質量指標，包括：

• 服務接口質量，需要關注接口成功率、接口響應時延。
• 服務依賴情況，主要有資源請求成功率，是否有跨云的依賴、循環依賴。
• 服務資源使用，主要關注CPU和內存的使用率，如果已經接近或達到瓶頸的情況，就需要做及時的擴容和優化。
• 服務錯誤數，包括panic次數、panic/error日志數量以及各種5XX狀態碼的數量。

基于這些指標，就可以制作一個服務評價報表，定期發送給研發人員，幫助他們了解自己服務的運行狀態和質量。進而，他們就可以針對問題進行優化，提高服務的穩定性和性能。

觀測手段不是獨立的

最后，這里拿這張圖做一個總結。

需要主義的是，日志、監控、追蹤是我們觀測服務的三種手段，但它們不是完全獨立的，而是有交叉的。它們的數據是有不同的組織形式，而且觀測的層面也是各不相同的。當前，我們只有結合好這三者，才能更好、更全面、更深入地去觀測我們的服務。