在线观看亚洲免费,91久久欧美极品XXXXⅩ,做爱视频毛片,四虎成人免费视频,大鸡巴在线视频,久久精品一区二区,一级日本在线,网红操逼视频在线观看免费视频在线观看

作者：李煌東

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

Cloud Native

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

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

1、混沌的微服務(wù)架構(gòu)，多語(yǔ)言和多網(wǎng)絡(luò)協(xié)議混雜

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

無(wú)法準(zhǔn)確清晰了解、掌控全局的系統(tǒng)運(yùn)行架構(gòu)；
無(wú)法回答應(yīng)用之間的連通性是否正確；

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

2、下沉的基礎(chǔ)設(shè)施能力屏蔽實(shí)現(xiàn)細(xì)節(jié)，問(wèn)題定界越發(fā)困難

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

3、繁多監(jiān)測(cè)系統(tǒng)，造成監(jiān)測(cè)界面不一致

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

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

Cloud Native

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

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

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

eBPF 相當(dāng)于在內(nèi)核中構(gòu)建了一個(gè)執(zhí)行引擎，通過(guò)內(nèi)核調(diào)用將這段程序 attach 到某個(gè)內(nèi)核事件上，實(shí)現(xiàn)監(jiān)聽(tīng)內(nèi)核事件。有了事件我們就能進(jìn)一步做協(xié)議推導(dǎo)，篩選出感興趣的協(xié)議，對(duì)事件進(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ù)后推送到存儲(chǔ)端。這是整體處理過(guò)程。

eBPF 的超能力體現(xiàn)在能訂閱各種內(nèi)核事件，如文件讀寫(xiě)、網(wǎng)絡(luò)流量等，運(yùn)行在 Kubernetes 中的容器或者 Pod 里的一切行為都是通過(guò)內(nèi)核系統(tǒng)調(diào)用來(lái)實(shí)現(xiàn)的，內(nèi)核知道機(jī)器上所有進(jìn)程中發(fā)生的所有事情，所以內(nèi)核幾乎是可觀測(cè)性的最佳觀測(cè)點(diǎn)，這也是我們?yōu)槭裁催x擇 eBPF 的原因。另一個(gè)在內(nèi)核上做監(jiān)測(cè)的好處是應(yīng)用不需要變更，也不需要重新編譯內(nèi)核，做到了真正意義上的無(wú)侵入。當(dāng)集群里有幾十上百個(gè)應(yīng)用的時(shí)候，無(wú)侵入的解決方案會(huì)幫上大忙。

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

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

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

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

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

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

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

Cloud Native

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

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

那么具體怎么關(guān)聯(lián)呢？信息怎么組織呢？主要從兩方面來(lái)看：

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

2、自頂向下全棧關(guān)聯(lián)：以 Pod 為媒介，Kubernetes 層面關(guān)聯(lián) Workload、Service 等對(duì)象，基礎(chǔ)設(shè)施層面可以關(guān)聯(lián)節(jié)點(diǎn)、存儲(chǔ)設(shè)備、網(wǎng)絡(luò)等，應(yīng)用層面關(guān)聯(lián)日志、調(diào)用鏈路等。

接下來(lái)介紹下 Kubernetes 監(jiān)測(cè)的核心功能。

?永不過(guò)時(shí)的黃金指標(biāo)

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

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

請(qǐng)求數(shù)/QPS
響應(yīng)時(shí)間及分位數(shù)（P50、P90、P95、P99）

錯(cuò)誤數(shù)
慢調(diào)用數(shù)

如下圖所示：

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

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

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

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

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

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

?開(kāi)箱即用的告警功能

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

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

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

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

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

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

Kubernetes?可觀測(cè)性全景視角

Cloud Native

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

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

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

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

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

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

Kubernetes 的網(wǎng)絡(luò)架構(gòu)復(fù)雜度高，節(jié)點(diǎn)、Pod、容器、服務(wù)、VPC 交相輝映，簡(jiǎn)直能讓你眼花繚亂；
網(wǎng)絡(luò)問(wèn)題排查需要一定的專業(yè)知識(shí)，大多數(shù)對(duì)網(wǎng)絡(luò)問(wèn)題都有種天生的恐懼；
分布式 8 大謬誤告訴我們網(wǎng)絡(luò)不是穩(wěn)定的、網(wǎng)絡(luò)拓?fù)湟膊灰怀刹蛔兊?、延時(shí)不可忽視，造成了端到端之間的網(wǎng)絡(luò)拓?fù)洳淮_定性。

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

conntrack 記錄滿問(wèn)題；
IP 沖突；

CoreDNS 解析慢、解析失??；
節(jié)點(diǎn)沒(méi)開(kāi)外網(wǎng)。（對(duì)，你沒(méi)聽(tīng)錯(cuò)）；

服務(wù)訪問(wèn)不通；
配置問(wèn)題（LoadBalance 配置、路由配置、device 配置、網(wǎng)卡配置）；

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

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

網(wǎng)絡(luò)流量和帶寬；
丟包數(shù)（率）和重傳數(shù)（率）；

RTT。

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

?節(jié)點(diǎn)問(wè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)行的問(wèn)題后，將節(jié)點(diǎn)置為 NotReady 或不可調(diào)度，通過(guò) kubelet 把業(yè)務(wù) Pod 從問(wèn)題節(jié)點(diǎn)中驅(qū)逐出去。這是 Kubernetes 的第一道防線，第二道防線是云廠商針對(duì)節(jié)點(diǎn)高頻異常場(chǎng)景設(shè)計(jì)的節(jié)點(diǎn)自愈組件，如阿里云的?node repairer：發(fā)現(xiàn)問(wèn)題節(jié)點(diǎn)后，執(zhí)行排水驅(qū)逐、置換機(jī)器，從而做到自動(dòng)化地保障業(yè)務(wù)正常運(yùn)行。即便如此，節(jié)點(diǎn)在長(zhǎng)期使用過(guò)程中不可避免地會(huì)產(chǎn)生各種奇奇怪怪的問(wèn)題，定位起來(lái)比較費(fèi)時(shí)耗力。常見(jiàn)問(wèn)題分類和級(jí)別:

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

以一個(gè) CPU 打滿為例：

1、節(jié)點(diǎn)狀態(tài)?OK，CPU?使用率超過(guò)了?90%

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

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

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

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

縱向：確定應(yīng)用本身對(duì)外的延時(shí)高了，下一步就是確定具體哪個(gè)原因了，確定哪一步/哪個(gè)方法慢可以用火焰圖來(lái)看。如果代碼沒(méi)有問(wèn)題，那么可能執(zhí)行代碼的環(huán)境是有問(wèn)題的，這時(shí)可以查看系統(tǒng)的 CPU/Memory 等資源是否有問(wèn)題來(lái)做進(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 探針識(shí)別到 MySQL 協(xié)議后，組裝、還原了 MySQL 協(xié)議內(nèi)容，任何語(yǔ)言執(zhí)行的 SQL 語(yǔ)句都能采集到。

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

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

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)綜合來(lái)看。Pod 流量問(wèn)題是生產(chǎn)環(huán)境高頻問(wèn)題，比如數(shù)據(jù)庫(kù)流量陡增，當(dāng)環(huán)境中有成千上萬(wàn)個(gè) Pod 時(shí)，排查流量主要來(lái)自哪個(gè) Pod 就顯得特別困難。

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

總結(jié)

Cloud Native

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

- END -
?推薦閱讀?






31天拿下K8s含金量最高的CKA+CKS證書(shū)！
一文掌握 Ansible 自動(dòng)化運(yùn)維
Linux 使用 Systemd 管理進(jìn)程服務(wù)，劃重點(diǎn)~
Linux的10個(gè)最危險(xiǎn)命令
Kubernetes網(wǎng)絡(luò)難懂？可能是沒(méi)看到這篇文章
100個(gè)Linux Shell腳本經(jīng)典案例（附PDF）
24 個(gè) Docker 常見(jiàn)問(wèn)題處理技巧
23 款 DevOps 工具建設(shè)云原生時(shí)代
Shell分析日志文件，全面解鎖新姿勢(shì)！
這篇文章帶你全面掌握 Nginx ！
一文搞懂 Kubernetes 網(wǎng)絡(luò)通信原理
SRE本質(zhì)就是一個(gè)懂運(yùn)維的資深開(kāi)發(fā)
Kubernetes 4000節(jié)點(diǎn)運(yùn)維經(jīng)驗(yàn)分享
Kubernetes 的高級(jí)部署策略，你不一定知道！
基于Nginx實(shí)現(xiàn)灰度發(fā)布與AB測(cè)試
搭建一套完整的企業(yè)級(jí) K8s 集群（kubeadm方式）


點(diǎn)亮，服務(wù)器三年不宕機(jī)

基于 eBPF 的 Kubernetes 問(wèn)題排查全景圖發(fā)布