原文地址:?https://mp.weixin.qq.com/s/ggt-aCHSvhmfwz8-fFHN6w

作者：李煌東

01

當(dāng) Kubernetes?成為云原生事實(shí)標(biāo)準(zhǔn)，可觀測性挑戰(zhàn)隨之而來

Cloud Native

當(dāng)前，云原生技術(shù)以容器技術(shù)為基礎(chǔ)，通過標(biāo)準(zhǔn)可擴(kuò)展的調(diào)度、網(wǎng)絡(luò)、存儲、容器運(yùn)行時(shí)接口來提供基礎(chǔ)設(shè)施。同時(shí)，通過標(biāo)準(zhǔn)可擴(kuò)展的聲明式資源和控制器來提供運(yùn)維能力，兩層標(biāo)準(zhǔn)化推動了開發(fā)與運(yùn)維關(guān)注點(diǎn)分離，各領(lǐng)域進(jìn)一步提升規(guī)?；蛯I(yè)化，達(dá)到成本、效率、穩(wěn)定性的全面優(yōu)化。

在這樣的大技術(shù)背景下，越來越對的公司引入了云原生技術(shù)來開發(fā)、運(yùn)維業(yè)務(wù)應(yīng)用。正因?yàn)樵圃夹g(shù)帶來了越發(fā)紛繁復(fù)雜的可能性，業(yè)務(wù)應(yīng)用出現(xiàn)了微服務(wù)眾多、多語言開發(fā)、多通信協(xié)議的鮮明特征。同時(shí)，云原生技術(shù)本身將復(fù)雜度下移，給可觀測性帶來了更多挑戰(zhàn)：

1、混沌的微服務(wù)架構(gòu)，多語言和多網(wǎng)絡(luò)協(xié)議混雜
業(yè)務(wù)架構(gòu)因?yàn)榉止栴}，容易出現(xiàn)服務(wù)數(shù)量多，調(diào)用協(xié)議和關(guān)系非常復(fù)雜的現(xiàn)象，導(dǎo)致的常見問題包括：

• 無法準(zhǔn)確清晰了解、掌控全局的系統(tǒng)運(yùn)行架構(gòu)；

• 無法回答應(yīng)用之間的連通性是否正確；

• 多語言、多網(wǎng)絡(luò)調(diào)用協(xié)議帶來埋點(diǎn)成本呈線性增長，且重復(fù)埋點(diǎn) ROI 低，開發(fā)一般將這類需求優(yōu)先級降低，但可觀測數(shù)據(jù)又不得不采集。

2、下沉的基礎(chǔ)設(shè)施能力屏蔽實(shí)現(xiàn)細(xì)節(jié)，問題定界越發(fā)困難
基礎(chǔ)設(shè)施能力繼續(xù)下沉，開發(fā)和運(yùn)維關(guān)注點(diǎn)繼續(xù)分離，分層后彼此屏蔽了實(shí)現(xiàn)細(xì)節(jié)，數(shù)據(jù)方面不好關(guān)聯(lián)了，出現(xiàn)問題后不能迅速地定界問題出現(xiàn)在哪一層。開發(fā)同學(xué)只關(guān)注應(yīng)用是否正常工作，并不關(guān)心底層基礎(chǔ)設(shè)施細(xì)節(jié)，出現(xiàn)問題后需要運(yùn)維同學(xué)協(xié)同排查問題。運(yùn)維同學(xué)在問題排查過程中，需要開發(fā)同學(xué)提供足夠的上下游來推進(jìn)排查，否則只拿到“某某應(yīng)用延遲高”這么籠統(tǒng)的表述，這很難有進(jìn)一步結(jié)果。所以，開發(fā)同學(xué)和運(yùn)維同學(xué)之間需要共同語言來提高溝通效率，Kubernetes 的 Label、Namespace 等概念非常適合用來構(gòu)建上下文信息。

3、繁多監(jiān)測系統(tǒng)，造成監(jiān)測界面不一致
復(fù)雜系統(tǒng)帶來的一個(gè)嚴(yán)重副作用就是監(jiān)測系統(tǒng)繁多。數(shù)據(jù)鏈路不關(guān)聯(lián)、不統(tǒng)一，監(jiān)測界面體驗(yàn)不一致。很多運(yùn)維同學(xué)或許大多都有過這樣的體驗(yàn)：定位問題時(shí)瀏覽器打開幾十個(gè)窗口，在 Grafana、控制臺、日志等各種工具之間來回切換，不僅非常耗時(shí)巨大，且大腦能處理的信息有限，問題定位效率低下。如果有統(tǒng)一的可觀測性界面，數(shù)據(jù)和信息得到有效地組織，減少注意力分散和頁面切換，來提高問題定位效率，把寶貴時(shí)間投入到業(yè)務(wù)邏輯的構(gòu)建上去。

02

解決思路與技術(shù)方案

Cloud Native

為了解決上述問題，我們需要使用一種支持多語言，多通信協(xié)議的技術(shù)，并在產(chǎn)品層面盡可能覆蓋軟件棧端到端的可觀測性需求，通過調(diào)研，我們提出一種立足于容器界面和底層操作系統(tǒng)，向上關(guān)聯(lián)應(yīng)用性能監(jiān)測的可觀測性解決思路。

要采集容器、節(jié)點(diǎn)運(yùn)行環(huán)境、應(yīng)用、網(wǎng)絡(luò)各個(gè)維度的數(shù)據(jù)挑戰(zhàn)非常大，云原生社區(qū)針對不同需求給出了 cAdvisor、node exporter、kube-state-metics 等多種方式，但仍然無法滿足全部需求。維護(hù)眾多采集器的成本也不容小覷，引發(fā)的一個(gè)思考是能否有一種對應(yīng)用無侵入的、支持動態(tài)擴(kuò)展的數(shù)據(jù)采集方案？目前最好的答案是 eBPF。

1?「數(shù)據(jù)采集：eBPF 的超能力」

eBPF 相當(dāng)于在內(nèi)核中構(gòu)建了一個(gè)執(zhí)行引擎，通過內(nèi)核調(diào)用將這段程序 attach 到某個(gè)內(nèi)核事件上，實(shí)現(xiàn)監(jiān)聽內(nèi)核事件。有了事件我們就能進(jìn)一步做協(xié)議推導(dǎo)，篩選出感興趣的協(xié)議，對事件進(jìn)一步處理后放到 ringbuffer 或者 eBPF 自帶的數(shù)據(jù)結(jié)構(gòu) Map 中，供用戶態(tài)進(jìn)程讀取。用戶態(tài)進(jìn)程讀取這些數(shù)據(jù)后，進(jìn)一步關(guān)聯(lián) Kubernetes 元數(shù)據(jù)后推送到存儲端。這是整體處理過程。
eBPF 的超能力體現(xiàn)在能訂閱各種內(nèi)核事件，如文件讀寫、網(wǎng)絡(luò)流量等，運(yùn)行在 Kubernetes 中的容器或者 Pod 里的一切行為都是通過內(nèi)核系統(tǒng)調(diào)用來實(shí)現(xiàn)的，內(nèi)核知道機(jī)器上所有進(jìn)程中發(fā)生的所有事情，所以內(nèi)核幾乎是可觀測性的最佳觀測點(diǎn)，這也是我們?yōu)槭裁催x擇 eBPF 的原因。另一個(gè)在內(nèi)核上做監(jiān)測的好處是應(yīng)用不需要變更，也不需要重新編譯內(nèi)核，做到了真正意義上的無侵入。當(dāng)集群里有幾十上百個(gè)應(yīng)用的時(shí)候，無侵入的解決方案會幫上大忙。

但作為新技術(shù)，人們對 eBPF 也存在些許擔(dān)憂，比如安全性與探針性能。為了充分保證內(nèi)核運(yùn)行時(shí)的安全性，eBPF 代碼進(jìn)行了諸多限制，如最大堆棧空間當(dāng)前為 512、最大指令數(shù)為 100 萬。與此同時(shí)，針對性能擔(dān)憂，eBPF 探針控制在大約在 1%左右。其高性能主要體現(xiàn)在內(nèi)核中處理數(shù)據(jù)，減少數(shù)據(jù)在內(nèi)核態(tài)和用戶態(tài)之間的拷貝。簡單說就是數(shù)據(jù)在內(nèi)核里算好了再給用戶進(jìn)程，比如一個(gè) Gauge 值，以往的做法是將原始數(shù)據(jù)拷貝到用戶進(jìn)程再計(jì)算。

2?可編程的執(zhí)行引擎天然適合可觀測性

可觀測性工程通過幫助用戶更好的理解系統(tǒng)內(nèi)部狀態(tài)來消除知識盲區(qū)和及時(shí)消除系統(tǒng)性風(fēng)險(xiǎn)。eBPF 在可觀測性方面有何威力呢？

以應(yīng)用異常為例，當(dāng)發(fā)現(xiàn)應(yīng)用有異常后，解決問題過程中發(fā)現(xiàn)缺少應(yīng)用層面可觀測性，這時(shí)候通過埋點(diǎn)、測試、上線補(bǔ)充了應(yīng)用可觀測性，具體的問題得到了解決，但往往治標(biāo)不治本，下一次別的地方有問題，又需要走同樣的流程，另外多語言、多協(xié)議讓埋點(diǎn)的成本更高。更好的做法是用無侵入方式去解決，以避免需要觀測時(shí)沒有數(shù)據(jù)。

eBPF 執(zhí)行引擎可通過動態(tài)加載執(zhí)行 eBPF 腳本來采集可觀測性數(shù)據(jù)，舉個(gè)具體例子，假設(shè)原本的 Kubernetes 系統(tǒng)并沒有做進(jìn)程相關(guān)的監(jiān)測，有一天發(fā)現(xiàn)了某個(gè)惡意進(jìn)程（如挖礦程序）在瘋狂地占用 CPU，這時(shí)候我們會發(fā)現(xiàn)這類惡意的進(jìn)程創(chuàng)建應(yīng)該被監(jiān)測起來，這時(shí)候我們可以通過集成開源的進(jìn)程事件檢測庫來是實(shí)現(xiàn)，但這往往需要打包、測試、發(fā)布這一整套流程，全部走完可能一個(gè)月就過去了。

相比之下，eBPF 的方式顯得更為高效快捷，由于 eBPF 支持動態(tài)地加載到內(nèi)核監(jiān)聽進(jìn)程創(chuàng)建的事件，所以我們可以將 eBPF 腳本抽象成一個(gè)子模塊，采集客戶端每次只需要加載這個(gè)子模塊里的腳本完成數(shù)據(jù)采集，再通過統(tǒng)一的數(shù)據(jù)通道將數(shù)據(jù)推送到后端。這樣我們就省去了改代碼、打包、測試、發(fā)布的繁瑣流程，通過無侵入的方式動態(tài)地實(shí)現(xiàn)了進(jìn)程監(jiān)測這樣的需求。所以，eBPF 可編程的執(zhí)行引擎非常適合用來將增強(qiáng)可觀測性，將豐富的內(nèi)核數(shù)據(jù)采集上來，通過關(guān)聯(lián)業(yè)務(wù)應(yīng)用，方便問題排查。

03

從監(jiān)測系統(tǒng)到可觀測性

Cloud Native

隨著云原生浪潮，可觀測性概念正深入人心。但仍離不開日志、指標(biāo)、鏈路這三類可觀測領(lǐng)域的數(shù)據(jù)基石。做過運(yùn)維或 SRE 的同學(xué)經(jīng)常遇到這樣的問題：半夜被拉到應(yīng)急群里，披頭蓋地地被質(zhì)問為什么數(shù)據(jù)庫不工作了，在沒有上下文的情況下，無法立刻抓住問題核心。我們認(rèn)為好的可觀測性平臺應(yīng)該幫助用戶很好地反饋上下文，就像 Datadog 的 CEO 說的那樣：監(jiān)測工具不是功能越多功能越好，而是要思考怎樣在不同團(tuán)隊(duì)和成員之間架起橋梁，盡可能把信息放在同一個(gè)頁面中（to bridge the gap between the teams and get everything on the same page）。

因此，在可觀測性平臺產(chǎn)品設(shè)計(jì)上需要以指標(biāo)、鏈路、日志為基本，向外集成阿里云自家的各類云服務(wù)，同時(shí)也支持開源產(chǎn)品數(shù)據(jù)接入，將關(guān)鍵上下文信息關(guān)聯(lián)起來，方便不同背景的工程師理解，進(jìn)而加速問題排查。信息沒有有效地組織就會產(chǎn)生理解成本，信息粒度上以事件->指標(biāo)->鏈路->日志由粗到細(xì)地組織到一個(gè)頁面中，方便下鉆，不需要多個(gè)系統(tǒng)來回跳轉(zhuǎn)，從而提供一致體驗(yàn)。

那么具體怎么關(guān)聯(lián)呢？信息怎么組織呢？主要從兩方面來看：
1、端到端：展開說就是應(yīng)用到應(yīng)用，服務(wù)到服務(wù)，Kubernetes 的標(biāo)準(zhǔn)化和關(guān)注點(diǎn)分離，各自開發(fā)運(yùn)維各自關(guān)注各自領(lǐng)域，那么端到端的監(jiān)測很多時(shí)候成了”三不管“區(qū)域，出現(xiàn)問題的時(shí)候很難排查鏈路上哪個(gè)環(huán)節(jié)出了問題。因此從端到端的角度來看，兩者調(diào)用關(guān)系是關(guān)聯(lián)的基礎(chǔ)，因?yàn)橄到y(tǒng)調(diào)用才產(chǎn)生了聯(lián)系。通過 eBPF 技術(shù)非常方便地以無侵入的方式采集網(wǎng)絡(luò)調(diào)用，進(jìn)而將調(diào)用解析成我們熟知的應(yīng)用協(xié)議，如 HTTP、GRPC、MySQL 等，最后將拓?fù)潢P(guān)系構(gòu)建起來，形成一張清晰的服務(wù)拓?fù)浜蠓奖憧焖俣ㄎ粏栴}，如下圖中網(wǎng)關(guān)->Java 應(yīng)用->Python 應(yīng)用->云服務(wù)的完整鏈路中，任意一環(huán)出現(xiàn)延時(shí)，在服務(wù)拓?fù)渲袘?yīng)能一眼看出問題所在。這是第一個(gè)管線點(diǎn)端到端。
2、自頂向下全棧關(guān)聯(lián)：以 Pod 為媒介，Kubernetes 層面關(guān)聯(lián) Workload、Service 等對象，基礎(chǔ)設(shè)施層面可以關(guān)聯(lián)節(jié)點(diǎn)、存儲設(shè)備、網(wǎng)絡(luò)等，應(yīng)用層面關(guān)聯(lián)日志、調(diào)用鏈路等。

接下來介紹下 Kubernetes 監(jiān)測的核心功能。
1?永不過時(shí)的黃金指標(biāo)

黃金指標(biāo)是用來監(jiān)測系統(tǒng)性能和狀態(tài)的最小集合。黃金指標(biāo)有兩個(gè)好處：一，直接了然地表達(dá)了系統(tǒng)是否正常對外服務(wù)。二，能快速評估對用戶的影響或事態(tài)的嚴(yán)重性，能大量節(jié)省 SRE 或研發(fā)的時(shí)間，想象下如果我們?nèi)?CPU 使用率作為黃金指標(biāo)，那么 SRE 或研發(fā)將會奔于疲命，因?yàn)?CPU 使用率高可能并不會造成多大的影響。

Kubernetes 監(jiān)測支持這些指標(biāo)：

• 請求數(shù)/QPS

• 響應(yīng)時(shí)間及分位數(shù)（P50、P90、P95、P99）

• 錯(cuò)誤數(shù)

• 慢調(diào)用數(shù)

如下圖所示：

2?全局視角的服務(wù)拓?fù)?/span>

諸葛亮曾言“不謀全局者，不足謀一域 ”。隨著當(dāng)下技術(shù)架構(gòu)、部署架構(gòu)的復(fù)雜度越來越高，發(fā)生問題后定位問題變得越來越棘手，進(jìn)而導(dǎo)致 MTTR 越來越高。另一個(gè)影響是對影響面的分析帶來非常大的挑戰(zhàn)，通常會造成顧此失彼。因此，有一張像地圖一樣的拓?fù)浯髨D非常必要。全局拓?fù)渚哂幸韵绿攸c(diǎn)：

• 系統(tǒng)架構(gòu)感知：系統(tǒng)架構(gòu)圖是程序員了解一個(gè)新系統(tǒng)的重要參考，當(dāng)拿到一個(gè)系統(tǒng)，起碼需要知曉流量入口在哪里，有哪些核心模塊，依賴了哪些內(nèi)部外部組件等。在異常定位過程中，有一張全局架構(gòu)的圖對異常定位進(jìn)程有非常大推動作用。

• 依賴分析：有一些問題是出現(xiàn)在下游依賴，如果這個(gè)依賴不是自己團(tuán)隊(duì)維護(hù)就會比較麻煩，當(dāng)自己系統(tǒng)和下游系統(tǒng)沒有足夠的可觀測性的時(shí)候就更麻煩了，這種情況下就很難跟依賴的維護(hù)者講清楚問題。在我們的拓?fù)渲?，通過將黃金指標(biāo)的上下游用調(diào)用關(guān)系連起來，形成了一張調(diào)用圖。邊作為依賴的可視化，能查看對應(yīng)調(diào)用的黃金信號。有了黃金信號就能快速地分析下游依賴是否存在問題。

3?分布式 Tracing?助力根因定位

協(xié)議 Trace 同樣是無入侵、語言無關(guān)的。如果請求內(nèi)容中存在分布式鏈路 TraceID，能自動識別出來，方便進(jìn)一步下鉆到鏈路追蹤。應(yīng)用層協(xié)議的請求、響應(yīng)信息有助于對請求內(nèi)容、返回碼進(jìn)行分析，從而知道具體哪個(gè)接口有問題。如需查看代碼級別或請求界別的詳情，可點(diǎn)擊 Trace ID 下鉆到鏈路追蹤分析查看。

4?開箱即用的告警功能

開箱即用的告警模板，各個(gè)不同層次全覆蓋，不需要手動配置告警，將大規(guī)模 Kubernetes 運(yùn)維經(jīng)驗(yàn)融入到告警模板里面，精心設(shè)計(jì)的告警規(guī)則加上智能降噪和去重，我們能夠做到一旦告警就是有效的告警，并且告警里面帶有關(guān)聯(lián)信息，可以快速定位到異常實(shí)體。告警規(guī)則全棧覆蓋的好處是能及時(shí)、主動地將高風(fēng)險(xiǎn)事件報(bào)給用戶，用戶通過排查定位、解決告警、事后復(fù)盤、面向失敗設(shè)計(jì)等一系列手段，最終逐步達(dá)成更好的系統(tǒng)穩(wěn)定性。

5?網(wǎng)絡(luò)性能監(jiān)測

網(wǎng)絡(luò)性能問題在 Kubernetes 環(huán)境中很常見，由于 TCP 底層機(jī)制屏蔽了網(wǎng)絡(luò)傳輸?shù)膹?fù)雜性，應(yīng)用層對此是無感的，這對生產(chǎn)環(huán)境定位丟包率高、重傳率高這種問題帶來一定的麻煩。Kubernetes 監(jiān)測支持了 RTT、重傳&丟包、TCP 連接信息來表征網(wǎng)絡(luò)狀況，下面以 RTT 為例，支持從命名空間、節(jié)點(diǎn)、容器、Pod、服務(wù)、工作負(fù)載這幾個(gè)維度來看網(wǎng)絡(luò)性能，支持以下各種網(wǎng)絡(luò)問題的定位：

• 負(fù)載均衡無法訪問某個(gè) Pod，這個(gè) Pod 上的流量為 0，需要確定是否這個(gè) Pod 網(wǎng)絡(luò)有問題，還是負(fù)載均衡配置有問題；

• 某個(gè)節(jié)點(diǎn)上的應(yīng)用似乎性能都很差，需要確定是否節(jié)點(diǎn)網(wǎng)絡(luò)有問題，通過對別的節(jié)點(diǎn)網(wǎng)絡(luò)來達(dá)到；

• 鏈路上出現(xiàn)丟包，但不確定發(fā)生在那一層，可以通過節(jié)點(diǎn)、Pod、容器這樣的順序來排查。

??04

Kubernetes?可觀測性全景視角

Cloud Native

有了上述產(chǎn)品能力，基于阿里巴巴在容器、Kubernetes 方面有著豐富且極具深度的實(shí)踐，我們將這些寶貴生產(chǎn)實(shí)踐歸納、轉(zhuǎn)化成產(chǎn)品能力，以幫助用戶更有效、更快捷地定位生產(chǎn)環(huán)境問題。使用這個(gè)排查全景圖可以通過以下方法：

• 大體結(jié)構(gòu)上是以服務(wù)和 Deployment（應(yīng)用）為入口，大多數(shù)開發(fā)只需要關(guān)注這一層就行了。重點(diǎn)關(guān)注服務(wù)和應(yīng)用是否錯(cuò)慢，服務(wù)是否連通，副本數(shù)是否符合預(yù)期等

• 再往下一層是提供真正工作負(fù)載能力的 Pod。Pod 重點(diǎn)關(guān)注是否有錯(cuò)慢請求，是否健康，資源是否充裕，下游依賴是否健康等

• 最底下一層是節(jié)點(diǎn)，節(jié)點(diǎn)為 Pod 和服務(wù)提供運(yùn)行環(huán)境和資源。重點(diǎn)關(guān)注節(jié)點(diǎn)是否健康，是否處于可調(diào)度狀態(tài)，資源是否充裕等。

1?網(wǎng)絡(luò)問題

網(wǎng)絡(luò)是 Kubernetes 中最棘手、最常見的問題，因?yàn)橐韵聨讉€(gè)原因給我們定位生產(chǎn)環(huán)境網(wǎng)絡(luò)問題帶來麻煩：

• Kubernetes 的網(wǎng)絡(luò)架構(gòu)復(fù)雜度高，節(jié)點(diǎn)、Pod、容器、服務(wù)、VPC 交相輝映，簡直能讓你眼花繚亂；

• 網(wǎng)絡(luò)問題排查需要一定的專業(yè)知識，大多數(shù)對網(wǎng)絡(luò)問題都有種天生的恐懼；

• 分布式 8 大謬誤告訴我們網(wǎng)絡(luò)不是穩(wěn)定的、網(wǎng)絡(luò)拓?fù)湟膊灰怀刹蛔兊?、延時(shí)不可忽視，造成了端到端之間的網(wǎng)絡(luò)拓?fù)洳淮_定性。

Kubernetes 環(huán)境下場景的網(wǎng)絡(luò)問題有：

• conntrack 記錄滿問題；

• IP 沖突；

• CoreDNS 解析慢、解析失??；

• 節(jié)點(diǎn)沒開外網(wǎng)。（對，你沒聽錯(cuò)）；

• 服務(wù)訪問不通；

• 配置問題（LoadBalance 配置、路由配置、device 配置、網(wǎng)卡配置）；

• 網(wǎng)絡(luò)中斷造成整個(gè)服務(wù)不可用。

網(wǎng)絡(luò)問題千千萬萬，但萬變不離其宗的是網(wǎng)絡(luò)有其表征其是否正常運(yùn)行的”黃金指標(biāo)“：

• 網(wǎng)絡(luò)流量和帶寬；

• 丟包數(shù)（率）和重傳數(shù)（率）；

• RTT。

下面的示例展示了因網(wǎng)絡(luò)問題導(dǎo)致的慢調(diào)用問題。從 gateway 來看發(fā)生了慢調(diào)用，查看拓?fù)浒l(fā)現(xiàn)調(diào)下游 product 的 RT 比較高，但是 product 本身的黃金指標(biāo)來看 product 本身服務(wù)并沒有問題，進(jìn)一步查看兩者之間的網(wǎng)絡(luò)狀況，發(fā)現(xiàn) RTT 和重傳都比較高，說明網(wǎng)絡(luò)性能惡化了，導(dǎo)致了整體的網(wǎng)絡(luò)傳輸變慢，TCP 重傳機(jī)制掩蓋了這個(gè)事實(shí)，在應(yīng)用層面感知不到，日志也沒法看出問題所在。這時(shí)候網(wǎng)絡(luò)的黃金指標(biāo)有助于定界出問題，從而加速了問題的排查。

2?節(jié)點(diǎn)問題

Kubernetes 做了大量工作，盡可能確保提供給工作負(fù)載和服務(wù)的節(jié)點(diǎn)是正常的，節(jié)點(diǎn)控制器 7x24 小時(shí)地檢查節(jié)點(diǎn)的狀態(tài)，發(fā)現(xiàn)影響節(jié)點(diǎn)正常運(yùn)行的問題后，將節(jié)點(diǎn)置為 NotReady 或不可調(diào)度，通過 kubelet 把業(yè)務(wù) Pod 從問題節(jié)點(diǎn)中驅(qū)逐出去。這是 Kubernetes 的第一道防線，第二道防線是云廠商針對節(jié)點(diǎn)高頻異常場景設(shè)計(jì)的節(jié)點(diǎn)自愈組件，如阿里云的?node repairer：發(fā)現(xiàn)問題節(jié)點(diǎn)后，執(zhí)行排水驅(qū)逐、置換機(jī)器，從而做到自動化地保障業(yè)務(wù)正常運(yùn)行。即便如此，節(jié)點(diǎn)在長期使用過程中不可避免地會產(chǎn)生各種奇奇怪怪的問題，定位起來比較費(fèi)時(shí)耗力。常見問題分類和級別:

針對這些繁雜的問題，總結(jié)出?如下排查流程圖：

?以一個(gè) CPU??打滿為例：1、節(jié)點(diǎn)狀態(tài)??OK，CPU??使用率超過了??90%?
?

2、查看對應(yīng)的 CPU 的三元組：使用率、TopN、時(shí)序圖，首先每個(gè)核的使用率都很高，進(jìn)而導(dǎo)致整體 CPU 使用高；接下來我們自然要知道誰在瘋狂地使用 CPU，從 TopN 列表來看有個(gè) Pod 一枝獨(dú)秀地占用 CPU；最后我們得確認(rèn)下 CPU 飆高是什么時(shí)候開始的。

3?服務(wù)響應(yīng)慢

造成服務(wù)響應(yīng)非常多，場景可能的原因有代碼設(shè)計(jì)問題、網(wǎng)絡(luò)問題、資源競爭問題、依賴服務(wù)慢等原因。在復(fù)雜的 Kubernetes 環(huán)境下，定位慢調(diào)用可以從兩個(gè)方案去入手：首先，應(yīng)用自身是否慢；其次，下游或網(wǎng)絡(luò)是否慢；最后檢查下資源的使用情況。如下圖所示，Kubernetes 監(jiān)測分別從橫向和縱向來分析服務(wù)性能：

• 橫向：主要是端到端層面來看，首先看自己服務(wù)的黃金指標(biāo)是否有問題，再逐步看下游的網(wǎng)絡(luò)指標(biāo)。注意如果從客戶端來看調(diào)用下游耗時(shí)高，但從下游本身的黃金指標(biāo)來看是正常的，這時(shí)候非常有可能是網(wǎng)絡(luò)問題或者操作系統(tǒng)層面的問題，此時(shí)可以用網(wǎng)絡(luò)性能指標(biāo)（流量、丟包、重傳、RTT 等）來確定。

• 縱向：確定應(yīng)用本身對外的延時(shí)高了，下一步就是確定具體哪個(gè)原因了，確定哪一步/哪個(gè)方法慢可以用火焰圖來看。如果代碼沒有問題，那么可能執(zhí)行代碼的環(huán)境是有問題的，這時(shí)可以查看系統(tǒng)的 CPU/Memory 等資源是否有問題來做進(jìn)一步排查。

下面舉個(gè) SQL 慢查詢的例子（如下圖）。在這個(gè)例子中網(wǎng)關(guān)調(diào)用 product 服務(wù)， product 服務(wù)依賴了 MySQL 服務(wù)，逐步查看鏈路上的黃金指標(biāo)，最終發(fā)現(xiàn) product 執(zhí)行了一條特別復(fù)雜的 SQL，關(guān)聯(lián)了多張表，導(dǎo)致 MySQL 服務(wù)響應(yīng)慢。MySQL 協(xié)議基于 TCP 之上的，我們的 eBPF 探針識別到 MySQL 協(xié)議后，組裝、還原了 MySQL 協(xié)議內(nèi)容，任何語言執(zhí)行的 SQL 語句都能采集到。

第二個(gè)例子是應(yīng)用本身慢的例子，這時(shí)候自然會問具體哪一步、哪個(gè)函數(shù)造成了慢， ARMS 應(yīng)用監(jiān)控支持的火焰圖通過對 CPU 耗時(shí)定期采樣（如下圖），幫助快速定位到代碼級別問題。

4?應(yīng)用/Pod?狀態(tài)問題

Pod 負(fù)責(zé)管理容器，容器是真正執(zhí)行業(yè)務(wù)邏輯的載體。同時(shí) Pod 是 Kubernetes 調(diào)度的最小單元，所以 Pod 同時(shí)擁有了業(yè)務(wù)和基礎(chǔ)設(shè)施的復(fù)雜度，需要結(jié)合著日志、鏈路、系統(tǒng)指標(biāo)、下游服務(wù)指標(biāo)綜合來看。Pod 流量問題是生產(chǎn)環(huán)境高頻問題，比如數(shù)據(jù)庫流量陡增，當(dāng)環(huán)境中有成千上萬個(gè) Pod 時(shí)，排查流量主要來自哪個(gè) Pod 就顯得特別困難。

接下來我們看一個(gè)典型的案例：下游服務(wù)在發(fā)布過程中灰度了一個(gè) Pod，該 Pod 因代碼原因響應(yīng)非常慢，導(dǎo)致上游都超時(shí)了。之所以能做到 Pod 級別的可觀測，是因?yàn)槲覀冇?ebpf 的技術(shù)來采集 Pod 的流量、黃金指標(biāo)，因此可以通過拓?fù)?、大盤的方式方便地查看 Pod 與 Pod、Pod 與服務(wù)、Pod 與外部的流量。

05

總結(jié)

Cloud Native

通過 eBPF 無侵入地采集多語言、多網(wǎng)絡(luò)協(xié)議的黃金指標(biāo)/網(wǎng)絡(luò)指標(biāo)/Trace，通過關(guān)聯(lián) Kubernetes 對象、應(yīng)用、云服務(wù)等各種上下文，同時(shí)在需要進(jìn)一步下鉆的時(shí)候提供專業(yè)化的監(jiān)測工具（如火焰圖），實(shí)現(xiàn)了 Kubernetes 環(huán)境下的一站式可觀測性平臺。

如果您在架構(gòu)云原生監(jiān)測的過程中，有以下困擾，那么請毫不猶豫的聯(lián)系我們一起探討：

• 對 Kubernetes 不熟悉，需要一整套完整的統(tǒng)一監(jiān)測方案；

• Prometheus、Alertmanager、Grafana 等多個(gè)系統(tǒng)的數(shù)據(jù)割裂和上手難;

• 容器環(huán)境下應(yīng)用、基礎(chǔ)設(shè)施埋點(diǎn)成本過高，正在尋找低成本或無侵入的解決方案；