近幾年，“可觀測(cè)”是一個(gè)熱門(mén)的話題。作為積極擁抱微服務(wù)架構(gòu)的企業(yè)，作業(yè)幫團(tuán)隊(duì)在快速的業(yè)務(wù)拓展中，解決了一個(gè)又一個(gè)隨之而來(lái)的技術(shù)挑戰(zhàn)。

日前，在51CTO主辦的WOT全球技術(shù)創(chuàng)新大會(huì)上，作業(yè)幫基礎(chǔ)架構(gòu)部資深架構(gòu)師莫仁鵬帶來(lái)了主題演講《作業(yè)幫服務(wù)觀測(cè)體系建設(shè)與實(shí)踐》，基于多年來(lái)作業(yè)幫云原生建設(shè)的實(shí)踐經(jīng)驗(yàn)和成果，分享了作業(yè)幫團(tuán)隊(duì)在構(gòu)建服務(wù)觀測(cè)體系的過(guò)程中的創(chuàng)新思考。

本文將摘選其中精彩內(nèi)容，統(tǒng)一整理，希望為諸君帶來(lái)啟發(fā)。

服務(wù)觀測(cè)的流量挑戰(zhàn)

眾多周知，服務(wù)觀測(cè)來(lái)源于近年來(lái)很流行的一個(gè)詞：Observability，即可以由其外部輸出推斷其內(nèi)部狀態(tài)的程度。

具體來(lái)講，“可觀測(cè)”主要分為三個(gè)部分。首先是日志，它主要是涉及到單個(gè)離散的事件。第二是監(jiān)控，它是可聚合、按時(shí)間維度變化的狀態(tài)。第三是Tracing，是單次請(qǐng)求范圍內(nèi)的信息。

服務(wù)觀測(cè)最大的難題就在于流量挑戰(zhàn)。目前，作業(yè)幫的日志數(shù)據(jù)量已達(dá)到了峰值百GB/s的級(jí)別，每天的日志大小在PB級(jí)左右，整體的監(jiān)控?cái)?shù)據(jù)量在千萬(wàn)級(jí)/s，追蹤數(shù)據(jù)量也是在千萬(wàn)級(jí)左右。

因此，構(gòu)建一套高可用、高擴(kuò)縮、低成本的一套服務(wù)觀測(cè)體系，勢(shì)在必行。

日志體系

在觀測(cè)體系中，日志部分是大家接觸最多的，也是最重要的一環(huán)，它有四個(gè)目標(biāo)：

• 第一，高可用。因?yàn)樵S多下游業(yè)務(wù)，如業(yè)務(wù)服務(wù)的監(jiān)控、業(yè)務(wù)數(shù)據(jù)的報(bào)表、大數(shù)據(jù)模型訓(xùn)練等都對(duì)會(huì)對(duì)日志的可用性要求很高，甚至要做到一條數(shù)據(jù)也不能丟失。
• 第二，高吞吐。特別是在作業(yè)幫內(nèi)部場(chǎng)景中，它的高峰流量可能是低峰流量的10倍以上，這就要求我們有足夠高的吞吐性能。
• 第三，低延遲。下游的部分日志消費(fèi)服務(wù)他們對(duì)延遲要求也很敏感。
• 第四，低成本。日志的數(shù)量巨大，想要長(zhǎng)期保存它們，就需要用足夠低成本的保存方式。

下圖是作業(yè)幫整個(gè)日志體系的架構(gòu)。

第一，日志輸出的部分。跑在K8s中的服務(wù)，都是一個(gè)個(gè)容器，容器首先會(huì)把日志輸入到容器的日志文件中，然后在每個(gè)機(jī)器和節(jié)點(diǎn)上會(huì)部署一個(gè)日志采集的服務(wù)，由它來(lái)負(fù)責(zé)采集每個(gè)容器的日志。采集完成后，全部的日志將上傳到Kafka，并通過(guò)Kafka完成日志的傳輸。

接下來(lái)是日志的處理和消費(fèi)，主要涉及到：日志的存儲(chǔ)和檢索，日志監(jiān)控、日志追蹤和大數(shù)據(jù)部分。

最后，在存儲(chǔ)部分，作業(yè)幫最終是采用了對(duì)象存儲(chǔ)的方式。

接下來(lái)，重點(diǎn)分析下日志輸出、采集、處理、消費(fèi)、存儲(chǔ)的構(gòu)建過(guò)程。

日志輸出方面，作業(yè)幫所有服務(wù)都采取了標(biāo)準(zhǔn)輸出的模式來(lái)打印日志。對(duì)于老服務(wù)，引入了日志邊車(chē)模式來(lái)幫助完成標(biāo)準(zhǔn)輸出的改造。主要流程是通過(guò)一個(gè)管道文件：服務(wù)容器將日志寫(xiě)入管道文件，然后日志邊車(chē)從管道文件中讀取并打印到標(biāo)準(zhǔn)輸出中。標(biāo)準(zhǔn)輸出的好處包括統(tǒng)一日志輸出方式、服務(wù)不需要管理日志的生命周期、采集友好、以及知曉日志的輸出時(shí)間。

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

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

日志檢索方面，莫仁鵬重點(diǎn)介紹了ELK這套方案在日志檢索中經(jīng)常遇到的幾個(gè)問(wèn)題，如要求結(jié)構(gòu)化數(shù)據(jù)、寫(xiě)入性能低、運(yùn)行成本高和存儲(chǔ)成本高等。然后重新審視了日志檢索的場(chǎng)景特點(diǎn)，包括非結(jié)構(gòu)化數(shù)據(jù)、寫(xiě)多讀少的場(chǎng)景、查詢(xún)時(shí)延不敏感以及數(shù)據(jù)規(guī)模比較大。

這里值得注意的是，日志檢索的理想方案應(yīng)具備以下特點(diǎn)：

• 不需要對(duì)日志建立索引，也不需要對(duì)各種日志做反序列化，去做結(jié)構(gòu)化的存儲(chǔ)。查詢(xún)操作是全文檢索，但通過(guò)分布式和并行化處理，檢索速度可以滿(mǎn)足需求。
• 日志按塊存儲(chǔ)，每個(gè)日志塊是一類(lèi)日志的聚合，例如某個(gè)pod在某段時(shí)間內(nèi)的日志都會(huì)寫(xiě)入一個(gè)日志塊中。
• 通過(guò)并行檢索的方式，按照服務(wù)名稱(chēng)、時(shí)間、機(jī)器名稱(chēng)等標(biāo)簽建立索引，可以通過(guò)選擇查詢(xún)條件，一級(jí)索引快速呈現(xiàn)所需的各類(lèi)日志塊。

基于此，作業(yè)幫提出了一套可以實(shí)際落地的新方案，旨在更好地滿(mǎn)足微服務(wù)場(chǎng)景下的日志檢索需求。新方案包括以下組件：

• Ingester組件：負(fù)責(zé)寫(xiě)入各個(gè)日志塊，并將索引信息寫(xiě)入數(shù)據(jù)庫(kù)。
• 查詢(xún)組件(query-proxy組件)：負(fù)責(zé)接收用戶(hù)查詢(xún)命令，分發(fā)給各個(gè)不同的查詢(xún)組件，并返回最終結(jié)果給用戶(hù)。
• query組件：在本地存儲(chǔ)中完成各個(gè)檢索命令，返回結(jié)果給proxy組件。
• manager組件：負(fù)責(zé)管理機(jī)器上的日志塊生命周期，包括上傳本地存儲(chǔ)的日志塊到對(duì)象存儲(chǔ)、從對(duì)象存儲(chǔ)下載日志塊到本地存儲(chǔ)、淘汰過(guò)期的日志塊等任務(wù)。

日志存儲(chǔ)方面，作業(yè)幫采用了分級(jí)存儲(chǔ)的方式。首先，日志塊被寫(xiě)入到本地存儲(chǔ)中。一旦超過(guò)一定時(shí)間，這些chunk會(huì)被按照策略上傳到對(duì)象存儲(chǔ)中，并以壓縮的方式進(jìn)行保存。對(duì)象存儲(chǔ)主要用于長(zhǎng)期存儲(chǔ)，超過(guò)一定時(shí)間的日志塊會(huì)被統(tǒng)一歸檔到歸檔存儲(chǔ)中。

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

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

總體來(lái)說(shuō)，該日志檢索方案具有以下優(yōu)勢(shì)和表現(xiàn)：

• 方便接入：對(duì)日志格式?jīng)]有任何要求，所有云原生服務(wù)都可以默認(rèn)接入。支持shell查詢(xún)命令，客戶(hù)無(wú)需額外學(xué)習(xí)成本。
• 高吞吐：由于不對(duì)日志進(jìn)行反序列化或全量索引，單核可以支持50M/s的日志寫(xiě)入。
• 成本低：采用分級(jí)存儲(chǔ)方式，通過(guò)zstd壓縮保存日志，相比傳統(tǒng)存儲(chǔ)方式可以降低一到兩個(gè)數(shù)量級(jí)的成本。
• 速度快：采用分布式并行檢索，支持橫向擴(kuò)容?？梢栽?0秒內(nèi)完成1TB大小日志的檢索。

監(jiān)控體系

這里，我們把監(jiān)控主要分為三個(gè)部分。

第一是集群監(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é)點(diǎn)和各種網(wǎng)絡(luò)延遲;四是基礎(chǔ)組件監(jiān)控，會(huì)涉及到各種注冊(cè)發(fā)現(xiàn)、服務(wù)觀測(cè)組件;五是中間件監(jiān)控。

第二是服務(wù)監(jiān)控。主要涉及到對(duì)服務(wù)pod上各種指標(biāo)進(jìn)行監(jiān)控，主要分為兩部分。第一是Runtime監(jiān)控，主要會(huì)涉及到各種運(yùn)行時(shí)和各種語(yǔ)言的指標(biāo)。第二是自定義監(jiān)控，我們可以支持業(yè)務(wù)暴露Metrics接口，以供Prometheus采集，實(shí)現(xiàn)業(yè)務(wù)的自定義指標(biāo)。

第三是流量監(jiān)控。由于業(yè)務(wù)流量上會(huì)對(duì)時(shí)延敏感，不便直接做埋點(diǎn)，作業(yè)幫是統(tǒng)一通過(guò)消費(fèi)日志的方式來(lái)完成流量方向的監(jiān)控，主要涉及到指標(biāo)包括：其一是入流量，即請(qǐng)求QPS、請(qǐng)求時(shí)延、成功率、錯(cuò)誤碼數(shù)量等指標(biāo);其二是出流量，主要是觀測(cè)服務(wù)對(duì)于數(shù)據(jù)庫(kù)、緩存、依賴(lài)服務(wù)等流量的整體監(jiān)控指標(biāo);其三是網(wǎng)關(guān)監(jiān)控，涉及到QPS時(shí)延和請(qǐng)求碼數(shù)量等相關(guān)監(jiān)控;其四是異步流量的，也就是消息隊(duì)列，主要涉及到生產(chǎn)/消費(fèi)QPS、生產(chǎn)/消費(fèi)耗時(shí)、消費(fèi)延遲的一些指標(biāo)。

通過(guò)上面這些指標(biāo)，可以觀測(cè)到平臺(tái)側(cè)以及資源層、服務(wù)層的各種監(jiān)控指標(biāo)，進(jìn)而了解所有服務(wù)的運(yùn)行狀態(tài)。

在監(jiān)控采集方面，Prometheus當(dāng)前是云原生監(jiān)控領(lǐng)域的一個(gè)事實(shí)標(biāo)準(zhǔn)，它有著高效的時(shí)序數(shù)據(jù)存儲(chǔ)，單次可以處理大量的數(shù)據(jù)。這里也有一個(gè)問(wèn)題，它是單機(jī)部署的，不支持集群化部署，遇到數(shù)據(jù)持久化甚至是大數(shù)據(jù)量的監(jiān)控?cái)?shù)據(jù)持久化上，可能就無(wú)法滿(mǎn)足我們的要求。我們通過(guò)引入時(shí)序數(shù)據(jù)庫(kù)方式來(lái)解決這個(gè)問(wèn)題。

Prometheus會(huì)把監(jiān)控?cái)?shù)據(jù)通過(guò)Remote Write的方式寫(xiě)入到時(shí)序數(shù)據(jù)庫(kù)中。接下來(lái)所有的對(duì)于監(jiān)控?cái)?shù)據(jù)的讀取操作都是在時(shí)序數(shù)據(jù)庫(kù)中進(jìn)行的，主要包括在Grafana上的各種數(shù)據(jù)展示、告警以及對(duì)于監(jiān)控?cái)?shù)據(jù)的一些API的訪問(wèn)。

監(jiān)控存儲(chǔ)方面，我們選擇用Prometheus，并用Metrics作為時(shí)序數(shù)據(jù)庫(kù)存儲(chǔ)，主要是基于以下幾個(gè)點(diǎn)考慮。第一，它兼容Prometheus，它可以支持Prometheus的各種查詢(xún)語(yǔ)句，下游也可以把它當(dāng)做一個(gè)Prometheus來(lái)使用。第二，它的架構(gòu)比較簡(jiǎn)單，方便做各種橫向的擴(kuò)展。第三，它的數(shù)據(jù)壓縮率比較高，平均每個(gè)點(diǎn)位會(huì)占用32B左右。第四，它支持高吞吐，它單核可以支持6W/S的監(jiān)控?cái)?shù)據(jù)的寫(xiě)入。

在使用VM的過(guò)程中需要注意數(shù)據(jù)容量的問(wèn)題。因?yàn)楸O(jiān)控?cái)?shù)據(jù)的保存時(shí)間要求比較高，整個(gè)存儲(chǔ)就成了一個(gè)瓶頸。這可以通過(guò)降準(zhǔn)的方式來(lái)解決。

事實(shí)上，監(jiān)控場(chǎng)景也是有明顯冷熱之分，研發(fā)人員最常訪問(wèn)的是一個(gè)月內(nèi)的監(jiān)控?cái)?shù)據(jù)，在一個(gè)月外的監(jiān)控?cái)?shù)據(jù)就較少訪問(wèn)了?；谶@個(gè)思路，就可以把監(jiān)控?cái)?shù)據(jù)做一個(gè)標(biāo)準(zhǔn)和降準(zhǔn)的區(qū)分。降準(zhǔn)即原來(lái)10秒打一個(gè)監(jiān)控?cái)?shù)據(jù)的點(diǎn)，會(huì)被改造成為100秒打一個(gè)點(diǎn)。

具體實(shí)現(xiàn)方式上，首先通過(guò)Prometheus來(lái)完成寫(xiě)入，在寫(xiě)入前使用一個(gè)proxy來(lái)完成它的代理，同時(shí)在proxy上就可以會(huì)做一個(gè)降準(zhǔn)的操作，按比例把所有的寫(xiě)入點(diǎn)做一個(gè)抽樣;然后分別把抽樣前的數(shù)據(jù)和抽樣后的數(shù)據(jù)寫(xiě)入到不同的VM存儲(chǔ)中;最后Select組件會(huì)按照時(shí)間把不同的請(qǐng)求做一個(gè)拆分，打到不同的VM集群中，最后做一個(gè)聚合，返回給前端用戶(hù)。通過(guò)這種方式，就可以把我們一個(gè)月前的數(shù)據(jù)做一個(gè)標(biāo)準(zhǔn)存儲(chǔ)，一個(gè)月后的數(shù)據(jù)做降準(zhǔn)存儲(chǔ)。

值得一提的是，落地了這種方式之后，我們?cè)谡w的存儲(chǔ)成本下降了80%左右。

追蹤體系

隨著微服務(wù)的興起，單個(gè)請(qǐng)求可能需要跨越多個(gè)系統(tǒng)和服務(wù)，一旦某個(gè)服務(wù)或網(wǎng)絡(luò)出現(xiàn)延遲，可能導(dǎo)致整個(gè)請(qǐng)求出現(xiàn)問(wèn)題。因此，需要一種能夠觀察和追蹤整個(gè)請(qǐng)求鏈路執(zhí)行情況的方式，這就是追蹤體系的作用。

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

其中，采集部分通過(guò)邊車(chē)、服務(wù)和日志三種方式獲取追蹤數(shù)據(jù)，其中邊車(chē)和服務(wù)數(shù)據(jù)通過(guò)Agent和collocter上報(bào)到Kafka，日志數(shù)據(jù)則直接投遞到Kafka;處理部分使用Clickhouse作為存儲(chǔ)，并引入Ingester和Query組件以支持寫(xiě)入和查詢(xún)操作;分析部分則包括服務(wù)拓?fù)浞治龊驼?qǐng)求鏈路分析，通過(guò)統(tǒng)計(jì)聚合追蹤數(shù)據(jù)來(lái)形成可聚合的指標(biāo)，并使用Prometheus進(jìn)行時(shí)序數(shù)據(jù)的采集和存儲(chǔ)。

關(guān)于采集方式，具體分為兩種：

邊車(chē)上報(bào)：在邊車(chē)上進(jìn)行埋點(diǎn)，將各種服務(wù)RPC流量進(jìn)行打點(diǎn)，通過(guò)Agent的方式完成上報(bào)。這種方式只能觀測(cè)到服務(wù)邊界上的流量，對(duì)服務(wù)內(nèi)部的流量無(wú)法深入。為了解決這個(gè)問(wèn)題，引入了服務(wù)上報(bào)的方式。

服務(wù)上報(bào)：服務(wù)可以通過(guò)接入SDK的方式完成上報(bào)。對(duì)于部分流量或服務(wù)不好接入的情況，可以通過(guò)日志方式完成上報(bào)，例如各種訪問(wèn)DB流量、訪問(wèn)緩存流量以及異步流量(如消息隊(duì)列、生產(chǎn)和消費(fèi))。

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

最后是關(guān)于服務(wù)的追蹤分析：通過(guò)追蹤服務(wù)的請(qǐng)求，可以獲得服務(wù)間的依賴(lài)關(guān)系，構(gòu)建出一張服務(wù)拓?fù)鋱D。從服務(wù)的維度對(duì)這些追蹤數(shù)據(jù)做統(tǒng)計(jì)分析，可以支持實(shí)時(shí)服務(wù)拓?fù)鋱D查看以及請(qǐng)求鏈路分析。請(qǐng)求鏈路分析可以展示核心鏈路服務(wù)的調(diào)用次數(shù)、依賴(lài)的新增情況以及請(qǐng)求鏈路中是否存在閉環(huán)。這些功能可以幫助研發(fā)人員更好地了解服務(wù)的運(yùn)行狀態(tài)和潛在問(wèn)題。

總結(jié)來(lái)講，追蹤體系通過(guò)采集、處理和分析三個(gè)主要部分來(lái)解決微服務(wù)中的問(wèn)題定位和瓶頸發(fā)現(xiàn)等挑戰(zhàn)。通過(guò)引入高效的存儲(chǔ)和數(shù)據(jù)分析方式，以及提供豐富的服務(wù)追蹤分析功能，可以幫助研發(fā)人員更好地了解服務(wù)的運(yùn)行狀態(tài)和性能表現(xiàn)，及時(shí)發(fā)現(xiàn)和解決問(wèn)題。

Serverless可觀測(cè)的前瞻思考

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

首先，日志方面，我們一般會(huì)通過(guò)云廠商的日志采集器統(tǒng)一完成采集，投遞到Kafka。不同云廠商提供的采集器功能不一致，而且功能不夠全面，對(duì)于投遞方式和數(shù)據(jù)的分裝方式可自定義程度不夠多，不太能夠滿(mǎn)足采集需求。

對(duì)于監(jiān)控方面，需要重點(diǎn)關(guān)注Serverless pod的資源指標(biāo)，如CPU和內(nèi)存的使用。這些資源都會(huì)暴露在虛擬節(jié)點(diǎn)上，可以通過(guò)Prometheus來(lái)采集這些Metrics接口。

最后，追蹤方面，當(dāng)前云廠商不提供采集的支持，需要對(duì)服務(wù)和架構(gòu)去做自身適配。

為了解決這些問(wèn)題，作業(yè)幫團(tuán)隊(duì)采用了容器注入的方式，統(tǒng)一解決Serverless上的服務(wù)觀測(cè)問(wèn)題。通過(guò)聲明DS編排，云廠商將各個(gè)DS編排注入到容器中，例如日志組件、日志觀測(cè)組件、追蹤采集組件等，注入到Serverless運(yùn)行的pod中。這種方式類(lèi)似于邊車(chē)的方式，但無(wú)需在編排中做額外聲明，服務(wù)編排無(wú)感。此外，作業(yè)幫團(tuán)隊(duì)還通過(guò)注入自己的采集組件，并針對(duì)自主架構(gòu)在組件層面為多家云廠商做適配，同時(shí)支持自定義的采集策略，通過(guò)agent完成采集，在底層實(shí)現(xiàn)了采集鏈路的統(tǒng)一。

最后，有了全景的觀測(cè)數(shù)據(jù)之后，還需要建立起一套服務(wù)評(píng)價(jià)體系，通過(guò)統(tǒng)一的標(biāo)準(zhǔn)評(píng)價(jià)服務(wù)質(zhì)量的好壞。

利用觀測(cè)數(shù)據(jù)建立了服務(wù)評(píng)價(jià)體系，通過(guò)統(tǒng)一的標(biāo)準(zhǔn)評(píng)價(jià)服務(wù)質(zhì)量的好壞，從而幫助

研發(fā)人員發(fā)現(xiàn)和管理那些微服務(wù)中“無(wú)法察覺(jué)的角落”。

作業(yè)幫團(tuán)隊(duì)目前主要依據(jù)服務(wù)觀測(cè)的指標(biāo)建立服務(wù)質(zhì)量指標(biāo)，包括：

• 服務(wù)接口質(zhì)量，需要關(guān)注接口成功率、接口響應(yīng)時(shí)延。
• 服務(wù)依賴(lài)情況，主要有資源請(qǐng)求成功率，是否有跨云的依賴(lài)、循環(huán)依賴(lài)。
• 服務(wù)資源使用，主要關(guān)注CPU和內(nèi)存的使用率，如果已經(jīng)接近或達(dá)到瓶頸的情況，就需要做及時(shí)的擴(kuò)容和優(yōu)化。
• 服務(wù)錯(cuò)誤數(shù)，包括panic次數(shù)、panic/error日志數(shù)量以及各種5XX狀態(tài)碼的數(shù)量。

基于這些指標(biāo)，就可以制作一個(gè)服務(wù)評(píng)價(jià)報(bào)表，定期發(fā)送給研發(fā)人員，幫助他們了解自己服務(wù)的運(yùn)行狀態(tài)和質(zhì)量。進(jìn)而，他們就可以針對(duì)問(wèn)題進(jìn)行優(yōu)化，提高服務(wù)的穩(wěn)定性和性能。

觀測(cè)手段不是獨(dú)立的

最后，這里拿這張圖做一個(gè)總結(jié)。

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