建站
咨詢
售后
建站咨詢
新聞中心
近幾年，“可觀測”是一個熱門的話題。作為積極擁抱微服務(wù)架構(gòu)的企業(yè)，作業(yè)幫團(tuán)隊在快速的業(yè)務(wù)拓展中，解決了一個又一個隨之而來的技術(shù)挑戰(zhàn)。
站在用戶的角度思考問題，與客戶深入溝通，找到臨汾網(wǎng)站設(shè)計與臨汾網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、空間域名、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋臨汾地區(qū)。
日前，在主辦的WOT全球技術(shù)創(chuàng)新大會上，作業(yè)幫基礎(chǔ)架構(gòu)部資深架構(gòu)師莫仁鵬帶來了主題演講《作業(yè)幫服務(wù)觀測體系建設(shè)與實踐》，基于多年來作業(yè)幫云原生建設(shè)的實踐經(jīng)驗和成果，分享了作業(yè)幫團(tuán)隊在構(gòu)建服務(wù)觀測體系的過程中的創(chuàng)新思考。
本文將摘選其中精彩內(nèi)容，統(tǒng)一整理，希望為諸君帶來啟發(fā)。
服務(wù)觀測的流量挑戰(zhàn)
眾多周知，服務(wù)觀測來源于近年來很流行的一個詞：Observability，即可以由其外部輸出推斷其內(nèi)部狀態(tài)的程度。
具體來講，“可觀測”主要分為三個部分。首先是日志，它主要是涉及到單個離散的事件。第二是監(jiān)控，它是可聚合、按時間維度變化的狀態(tài)。第三是Tracing，是單次請求范圍內(nèi)的信息。
服務(wù)觀測最大的難題就在于流量挑戰(zhàn)。目前，作業(yè)幫的日志數(shù)據(jù)量已達(dá)到了峰值百GB/s的級別，每天的日志大小在PB級左右，整體的監(jiān)控數(shù)據(jù)量在千萬級/s，追蹤數(shù)據(jù)量也是在千萬級左右。
因此，構(gòu)建一套高可用、高擴(kuò)縮、低成本的一套服務(wù)觀測體系，勢在必行。
日志體系
在觀測體系中，日志部分是大家接觸最多的，也是最重要的一環(huán)，它有四個目標(biāo)：
- 第一，高可用。因為許多下游業(yè)務(wù)，如業(yè)務(wù)服務(wù)的監(jiān)控、業(yè)務(wù)數(shù)據(jù)的報表、大數(shù)據(jù)模型訓(xùn)練等都對會對日志的可用性要求很高，甚至要做到一條數(shù)據(jù)也不能丟失。
- 第二，高吞吐。特別是在作業(yè)幫內(nèi)部場景中，它的高峰流量可能是低峰流量的10倍以上，這就要求我們有足夠高的吞吐性能。
- 第三，低延遲。下游的部分日志消費服務(wù)他們對延遲要求也很敏感。
- 第四，低成本。日志的數(shù)量巨大，想要長期保存它們，就需要用足夠低成本的保存方式。
下圖是作業(yè)幫整個日志體系的架構(gòu)。
第一，日志輸出的部分。跑在K8s中的服務(wù)，都是一個個容器，容器首先會把日志輸入到容器的日志文件中，然后在每個機(jī)器和節(jié)點上會部署一個日志采集的服務(wù)，由它來負(fù)責(zé)采集每個容器的日志。采集完成后，全部的日志將上傳到Kafka，并通過Kafka完成日志的傳輸。
接下來是日志的處理和消費，主要涉及到：日志的存儲和檢索，日志監(jiān)控、日志追蹤和大數(shù)據(jù)部分。
最后，在存儲部分，作業(yè)幫最終是采用了對象存儲的方式。
接下來，重點分析下日志輸出、采集、處理、消費、存儲的構(gòu)建過程。
日志輸出方面，作業(yè)幫所有服務(wù)都采取了標(biāo)準(zhǔn)輸出的模式來打印日志。對于老服務(wù)，引入了日志邊車模式來幫助完成標(biāo)準(zhǔn)輸出的改造。主要流程是通過一個管道文件：服務(wù)容器將日志寫入管道文件，然后日志邊車從管道文件中讀取并打印到標(biāo)準(zhǔn)輸出中。標(biāo)準(zhǔn)輸出的好處包括統(tǒng)一日志輸出方式、服務(wù)不需要管理日志的生命周期、采集友好、以及知曉日志的輸出時間。
日志采集方面，作業(yè)幫最初使用Filebeat，但遇到了一些問題，如可用性、穩(wěn)定性和性能方面的問題。因此，采用了自研的方式進(jìn)行優(yōu)化，包括優(yōu)化json解析邏輯、降低獲取容器元數(shù)據(jù)的開銷、更輕量的采集邏輯以及更好的采集隔離。最終的性能表現(xiàn)是支持單核75B/S的采集速率，提升了三倍的單機(jī)采集性能，并且采集整體使用的CPU下降了70%。
傳輸方面，作業(yè)幫重新設(shè)計了消息分裝格式，按照依賴Kafka的Header模式，將各種日志的元數(shù)據(jù)放到Kafka消息的Header中，然后在body中保存日志原文。這樣下游可以不用關(guān)心日志的分裝格式，從而省去了序列化與反序列化的開銷。在Header中保存各種數(shù)據(jù)信息，也可以幫助各個日志下游提取需要的日志信息。
日志檢索方面，莫仁鵬重點介紹了ELK這套方案在日志檢索中經(jīng)常遇到的幾個問題，如要求結(jié)構(gòu)化數(shù)據(jù)、寫入性能低、運行成本高和存儲成本高等。然后重新審視了日志檢索的場景特點，包括非結(jié)構(gòu)化數(shù)據(jù)、寫多讀少的場景、查詢時延不敏感以及數(shù)據(jù)規(guī)模比較大。
這里值得注意的是，日志檢索的理想方案應(yīng)具備以下特點：
- 不需要對日志建立索引，也不需要對各種日志做反序列化，去做結(jié)構(gòu)化的存儲。查詢操作是全文檢索，但通過分布式和并行化處理，檢索速度可以滿足需求。
- 日志按塊存儲，每個日志塊是一類日志的聚合，例如某個pod在某段時間內(nèi)的日志都會寫入一個日志塊中。
- 通過并行檢索的方式，按照服務(wù)名稱、時間、機(jī)器名稱等標(biāo)簽建立索引，可以通過選擇查詢條件，一級索引快速呈現(xiàn)所需的各類日志塊。
基于此，作業(yè)幫提出了一套可以實際落地的新方案，旨在更好地滿足微服務(wù)場景下的日志檢索需求。新方案包括以下組件：
- Ingester組件：負(fù)責(zé)寫入各個日志塊，并將索引信息寫入數(shù)據(jù)庫。
- 查詢組件(query-proxy組件)：負(fù)責(zé)接收用戶查詢命令，分發(fā)給各個不同的查詢組件，并返回最終結(jié)果給用戶。
- query組件：在本地存儲中完成各個檢索命令，返回結(jié)果給proxy組件。
- manager組件：負(fù)責(zé)管理機(jī)器上的日志塊生命周期，包括上傳本地存儲的日志塊到對象存儲、從對象存儲下載日志塊到本地存儲、淘汰過期的日志塊等任務(wù)。
日志存儲方面，作業(yè)幫采用了分級存儲的方式。首先，日志塊被寫入到本地存儲中。一旦超過一定時間，這些chunk會被按照策略上傳到對象存儲中，并以壓縮的方式進(jìn)行保存。對象存儲主要用于長期存儲，超過一定時間的日志塊會被統(tǒng)一歸檔到歸檔存儲中。
為了提高檢索效率，涉及到日志沉降的概念。如果只需要檢索近幾個小時的日志，可以直接在本地存儲中完成;如果需要查詢更早時間的日志，則需要從對象存儲甚至歸檔存儲中取回歸檔日志進(jìn)行檢索。
在成本方面，本地存儲的成本最高，而對象存儲的成本大約是本地存儲的1/3，歸檔存儲的成本是本地存儲的1/10。此外，對象存儲和歸檔存儲中的重要日志都是以zstd壓縮的方式保存，進(jìn)一步降低了存儲成本。
總體來說，該日志檢索方案具有以下優(yōu)勢和表現(xiàn)：
- 方便接入：對日志格式?jīng)]有任何要求，所有云原生服務(wù)都可以默認(rèn)接入。支持shell查詢命令，客戶無需額外學(xué)習(xí)成本。
- 高吞吐：由于不對日志進(jìn)行反序列化或全量索引，單核可以支持50M/s的日志寫入。
- 成本低：采用分級存儲方式，通過zstd壓縮保存日志，相比傳統(tǒng)存儲方式可以降低一到兩個數(shù)量級的成本。
- 速度快：采用分布式并行檢索，支持橫向擴(kuò)容?？梢栽?0秒內(nèi)完成1TB大小日志的檢索。
監(jiān)控體系
這里，我們把監(jiān)控主要分為三個部分。
第一是集群監(jiān)控。主要包括：一是系統(tǒng)監(jiān)控，系統(tǒng)監(jiān)控主要是K8S事件、K8S組件、APIServer和Etcd的各種指標(biāo);二是資源監(jiān)控，主要是涉及到pod和Node的各種資源使用;三是網(wǎng)絡(luò)監(jiān)控，主要涉及到節(jié)點和各種網(wǎng)絡(luò)延遲;四是基礎(chǔ)組件監(jiān)控，會涉及到各種注冊發(fā)現(xiàn)、服務(wù)觀測組件;五是中間件監(jiān)控。
第二是服務(wù)監(jiān)控。主要涉及到對服務(wù)pod上各種指標(biāo)進(jìn)行監(jiān)控，主要分為兩部分。第一是Runtime監(jiān)控，主要會涉及到各種運行時和各種語言的指標(biāo)。第二是自定義監(jiān)控，我們可以支持業(yè)務(wù)暴露Metrics接口，以供Prometheus采集，實現(xiàn)業(yè)務(wù)的自定義指標(biāo)。
第三是流量監(jiān)控。由于業(yè)務(wù)流量上會對時延敏感，不便直接做埋點，作業(yè)幫是統(tǒng)一通過消費日志的方式來完成流量方向的監(jiān)控，主要涉及到指標(biāo)包括：其一是入流量，即請求QPS、請求時延、成功率、錯誤碼數(shù)量等指標(biāo);其二是出流量，主要是觀測服務(wù)對于數(shù)據(jù)庫、緩存、依賴服務(wù)等流量的整體監(jiān)控指標(biāo);其三是網(wǎng)關(guān)監(jiān)控，涉及到QPS時延和請求碼數(shù)量等相關(guān)監(jiān)控;其四是異步流量的，也就是消息隊列，主要涉及到生產(chǎn)/消費QPS、生產(chǎn)/消費耗時、消費延遲的一些指標(biāo)。
通過上面這些指標(biāo)，可以觀測到平臺側(cè)以及資源層、服務(wù)層的各種監(jiān)控指標(biāo)，進(jìn)而了解所有服務(wù)的運行狀態(tài)。
在監(jiān)控采集方面，Prometheus當(dāng)前是云原生監(jiān)控領(lǐng)域的一個事實標(biāo)準(zhǔn)，它有著高效的時序數(shù)據(jù)存儲，單次可以處理大量的數(shù)據(jù)。這里也有一個問題，它是單機(jī)部署的，不支持集群化部署，遇到數(shù)據(jù)持久化甚至是大數(shù)據(jù)量的監(jiān)控數(shù)據(jù)持久化上，可能就無法滿足我們的要求。我們通過引入時序數(shù)據(jù)庫方式來解決這個問題。
Prometheus會把監(jiān)控數(shù)據(jù)通過Remote Write的方式寫入到時序數(shù)據(jù)庫中。接下來所有的對于監(jiān)控數(shù)據(jù)的讀取操作都是在時序數(shù)據(jù)庫中進(jìn)行的，主要包括在Grafana上的各種數(shù)據(jù)展示、告警以及對于監(jiān)控數(shù)據(jù)的一些API的訪問。
監(jiān)控存儲方面，我們選擇用Prometheus，并用Metrics作為時序數(shù)據(jù)庫存儲，主要是基于以下幾個點考慮。第一，它兼容Prometheus，它可以支持Prometheus的各種查詢語句，下游也可以把它當(dāng)做一個Prometheus來使用。第二，它的架構(gòu)比較簡單，方便做各種橫向的擴(kuò)展。第三，它的數(shù)據(jù)壓縮率比較高，平均每個點位會占用32B左右。第四，它支持高吞吐，它單核可以支持6W/S的監(jiān)控數(shù)據(jù)的寫入。
在使用VM的過程中需要注意數(shù)據(jù)容量的問題。因為監(jiān)控數(shù)據(jù)的保存時間要求比較高，整個存儲就成了一個瓶頸。這可以通過降準(zhǔn)的方式來解決。
事實上，監(jiān)控場景也是有明顯冷熱之分，研發(fā)人員最常訪問的是一個月內(nèi)的監(jiān)控數(shù)據(jù)，在一個月外的監(jiān)控數(shù)據(jù)就較少訪問了。基于這個思路，就可以把監(jiān)控數(shù)據(jù)做一個標(biāo)準(zhǔn)和降準(zhǔn)的區(qū)分。降準(zhǔn)即原來10秒打一個監(jiān)控數(shù)據(jù)的點，會被改造成為100秒打一個點。
具體實現(xiàn)方式上，首先通過Prometheus來完成寫入，在寫入前使用一個proxy來完成它的代理，同時在proxy上就可以會做一個降準(zhǔn)的操作，按比例把所有的寫入點做一個抽樣;然后分別把抽樣前的數(shù)據(jù)和抽樣后的數(shù)據(jù)寫入到不同的VM存儲中;最后Select組件會按照時間把不同的請求做一個拆分，打到不同的VM集群中，最后做一個聚合，返回給前端用戶。通過這種方式，就可以把我們一個月前的數(shù)據(jù)做一個標(biāo)準(zhǔn)存儲，一個月后的數(shù)據(jù)做降準(zhǔn)存儲。
值得一提的是，落地了這種方式之后，我們在整體的存儲成本下降了80%左右。
追蹤體系
隨著微服務(wù)的興起，單個請求可能需要跨越多個系統(tǒng)和服務(wù)，一旦某個服務(wù)或網(wǎng)絡(luò)出現(xiàn)延遲，可能導(dǎo)致整個請求出現(xiàn)問題。因此，需要一種能夠觀察和追蹤整個請求鏈路執(zhí)行情況的方式，這就是追蹤體系的作用。
追蹤體系主要分為采集、處理和分析三個部分。
其中，采集部分通過邊車、服務(wù)和日志三種方式獲取追蹤數(shù)據(jù)，其中邊車和服務(wù)數(shù)據(jù)通過Agent和collocter上報到Kafka，日志數(shù)據(jù)則直接投遞到Kafka;處理部分使用Clickhouse作為存儲，并引入Ingester和Query組件以支持寫入和查詢操作;分析部分則包括服務(wù)拓?fù)浞治龊驼埱箧溌贩治觯ㄟ^統(tǒng)計聚合追蹤數(shù)據(jù)來形成可聚合的指標(biāo)，并使用Prometheus進(jìn)行時序數(shù)據(jù)的采集和存儲。
關(guān)于采集方式，具體分為兩種：
邊車上報：在邊車上進(jìn)行埋點，將各種服務(wù)RPC流量進(jìn)行打點，通過Agent的方式完成上報。這種方式只能觀測到服務(wù)邊界上的流量，對服務(wù)內(nèi)部的流量無法深入。為了解決這個問題，引入了服務(wù)上報的方式。
服務(wù)上報：服務(wù)可以通過接入SDK的方式完成上報。對于部分流量或服務(wù)不好接入的情況，可以通過日志方式完成上報，例如各種訪問DB流量、訪問緩存流量以及異步流量(如消息隊列、生產(chǎn)和消費)。
在數(shù)據(jù)存儲方面，最初使用ElasticSearch，但遇到了寫入性能不足和數(shù)據(jù)壓縮率不理想等問題，導(dǎo)致整體集群成本很高。后來切換到Clickhouse后，存儲性能和效率大幅提升，單核可以支持1.5W/s的磁盤寫入，整體存儲集群的寫入性能提升了40%，CPU的使用下降了80%，磁盤占用下降了50%左右。這使得整體的存儲成本可以下降80%左右，是之前的1/5。
最后是關(guān)于服務(wù)的追蹤分析：通過追蹤服務(wù)的請求，可以獲得服務(wù)間的依賴關(guān)系，構(gòu)建出一張服務(wù)拓?fù)鋱D。從服務(wù)的維度對這些追蹤數(shù)據(jù)做統(tǒng)計分析，可以支持實時服務(wù)拓?fù)鋱D查看以及請求鏈路分析。請求鏈路分析可以展示核心鏈路服務(wù)的調(diào)用次數(shù)、依賴的新增情況以及請求鏈路中是否存在閉環(huán)。這些功能可以幫助研發(fā)人員更好地了解服務(wù)的運行狀態(tài)和潛在問題。
總結(jié)來講，追蹤體系通過采集、處理和分析三個主要部分來解決微服務(wù)中的問題定位和瓶頸發(fā)現(xiàn)等挑戰(zhàn)。通過引入高效的存儲和數(shù)據(jù)分析方式，以及提供豐富的服務(wù)追蹤分析功能，可以幫助研發(fā)人員更好地了解服務(wù)的運行狀態(tài)和性能表現(xiàn)，及時發(fā)現(xiàn)和解決問題。
Serverless可觀測的前瞻思考
在Serverless服務(wù)觀測的實踐方面，作業(yè)幫面臨著高擴(kuò)縮的問題，高峰時期的流量是低谷時期的十倍以上，為了降低運行成本，決定將服務(wù)統(tǒng)一套入到Serverless上運行。然而，在Serverless上直接部署觀測組件并不容易。云廠商為此提供了觀測解決方案，但仍存在一些問題。
首先，日志方面，我們一般會通過云廠商的日志采集器統(tǒng)一完成采集，投遞到Kafka。不同云廠商提供的采集器功能不一致，而且功能不夠全面，對于投遞方式和數(shù)據(jù)的分裝方式可自定義程度不夠多，不太能夠滿足采集需求。
對于監(jiān)控方面，需要重點關(guān)注Serverless pod的資源指標(biāo)，如CPU和內(nèi)存的使用。這些資源都會暴露在虛擬節(jié)點上，可以通過Prometheus來采集這些Metrics接口。
最后，追蹤方面，當(dāng)前云廠商不提供采集的支持，需要對服務(wù)和架構(gòu)去做自身適配。
為了解決這些問題，作業(yè)幫團(tuán)隊采用了容器注入的方式，統(tǒng)一解決Serverless上的服務(wù)觀測問題。通過聲明DS編排，云廠商將各個DS編排注入到容器中，例如日志組件、日志觀測組件、追蹤采集組件等，注入到Serverless運行的pod中。這種方式類似于邊車的方式，但無需在編排中做額外聲明，服務(wù)編排無感。此外，作業(yè)幫團(tuán)隊還通過注入自己的采集組件，并針對自主架構(gòu)在組件層面為多家云廠商做適配，同時支持自定義的采集策略，通過agent完成采集，在底層實現(xiàn)了采集鏈路的統(tǒng)一。
最后，有了全景的觀測數(shù)據(jù)之后，還需要建立起一套服務(wù)評價體系，通過統(tǒng)一的標(biāo)準(zhǔn)評價服務(wù)質(zhì)量的好壞。
利用觀測數(shù)據(jù)建立了服務(wù)評價體系，通過統(tǒng)一的標(biāo)準(zhǔn)評價服務(wù)質(zhì)量的好壞，從而幫助
研發(fā)人員發(fā)現(xiàn)和管理那些微服務(wù)中“無法察覺的角落”。
作業(yè)幫團(tuán)隊目前主要依據(jù)服務(wù)觀測的指標(biāo)建立服務(wù)質(zhì)量指標(biāo)，包括：
- 服務(wù)接口質(zhì)量，需要關(guān)注接口成功率、接口響應(yīng)時延。
- 服務(wù)依賴情況，主要有資源請求成功率，是否有跨云的依賴、循環(huán)依賴。
- 服務(wù)資源使用，主要關(guān)注CPU和內(nèi)存的使用率，如果已經(jīng)接近或達(dá)到瓶頸的情況，就需要做及時的擴(kuò)容和優(yōu)化。
- 服務(wù)錯誤數(shù)，包括panic次數(shù)、panic/error日志數(shù)量以及各種5XX狀態(tài)碼的數(shù)量。
基于這些指標(biāo)，就可以制作一個服務(wù)評價報表，定期發(fā)送給研發(fā)人員，幫助他們了解自己服務(wù)的運行狀態(tài)和質(zhì)量。進(jìn)而，他們就可以針對問題進(jìn)行優(yōu)化，提高服務(wù)的穩(wěn)定性和性能。
觀測手段不是獨立的
最后，這里拿這張圖做一個總結(jié)。
需要主義的是，日志、監(jiān)控、追蹤是我們觀測服務(wù)的三種手段，但它們不是完全獨立的，而是有交叉的。它們的數(shù)據(jù)是有不同的組織形式，而且觀測的層面也是各不相同的。當(dāng)前，我們只有結(jié)合好這三者，才能更好、更全面、更深入地去觀測我們的服務(wù)。
網(wǎng)站題目：作業(yè)幫服務(wù)觀測體系建設(shè)與實踐
分享URL：http://m.fisionsoft.com.cn/article/ccoegpd.html
