大家好，我是來自阿里云的李煌東，今天由我為大家分享 Kubernetes 監(jiān)控公開課的第二節(jié)內(nèi)容：如何發(fā)現(xiàn) Kubernetes 中服務(wù)和工作負(fù)載的異常。

本次分享由三個(gè)部分組成：

一、Kubernetes 異常定位存在痛點(diǎn)；

二、針對(duì)這些痛點(diǎn)，Kubernetes 監(jiān)控如何更快、更準(zhǔn)、更全的發(fā)現(xiàn)異常；

三、網(wǎng)絡(luò)性能監(jiān)控、中間件監(jiān)控等典型案例解析。

Kubernetes 異常定位存在痛點(diǎn)

當(dāng)下的互聯(lián)網(wǎng)架構(gòu)中，越來越多的公司采用微服務(wù) + Kubernetes 這樣的架構(gòu)，這樣的架構(gòu)有如下特點(diǎn)：

首先應(yīng)用層基于微服務(wù)，微服務(wù)由解耦開的幾個(gè)服務(wù)相互調(diào)用構(gòu)成，服務(wù)一般職責(zé)分明、邊界明確，造成的結(jié)果是一個(gè)簡(jiǎn)單的產(chǎn)品也有幾十、甚至上百個(gè)微服務(wù)，相互之間的依賴、調(diào)用是非常復(fù)雜的，這給定位問題帶來比較大的成本。同時(shí)，每個(gè)服務(wù)的 owner 可能來自不同團(tuán)隊(duì)，不同的開發(fā)，可能使用不同的語言，對(duì)我們監(jiān)控的影響是對(duì)每一種語言都需要進(jìn)行監(jiān)控工具的接入，投資回報(bào)率低。還有一個(gè)特點(diǎn)是多協(xié)議，幾乎每種中間件（Redis、MySQL、Kafka）都有他們獨(dú)特的協(xié)議，怎么要做到快速對(duì)這些協(xié)議進(jìn)行觀測(cè)，是不小的挑戰(zhàn)。

雖然 Kubernetes 和容器對(duì)上層應(yīng)用屏蔽了底層的復(fù)雜度，但是帶來的兩個(gè)結(jié)果是：基礎(chǔ)設(shè)施層越來越高；另一個(gè)是上層應(yīng)用和基礎(chǔ)設(shè)施之間信息變得越來越復(fù)雜了。舉個(gè)例子，用戶反饋網(wǎng)站訪問很慢，管理員查看訪問日志、服務(wù)狀態(tài)、資源水位發(fā)現(xiàn)都沒問題，這時(shí)候不知道問題出現(xiàn)在哪里，雖然懷疑基礎(chǔ)設(shè)施有問題，但無法定界的情況下只能一個(gè)一個(gè)排查效率低，問題的根源就是上層應(yīng)用和基礎(chǔ)設(shè)施之間缺少上下問題關(guān)聯(lián)，無法做到端到端串聯(lián)。

最后一個(gè)痛點(diǎn)是數(shù)據(jù)散、工具多、信息沒打通。舉個(gè)例子，假設(shè)我們收到一個(gè)告警，用 grafana 去查看指標(biāo)，指標(biāo)只能描述的比較粗略，我們得去看下日志，這時(shí)候我們要去 SLS 日志服務(wù)看下有沒有對(duì)應(yīng)的日志，日志也沒問題，這時(shí)候我們需要登錄到機(jī)器上去看，然而登錄到容器里面可能又因?yàn)橹貑?dǎo)致日志沒有了。查了一波之后，可能我們會(huì)覺得可能問題不是出現(xiàn)在這個(gè)應(yīng)用，于是我們又去看鏈路追蹤是不是下游有問題。總而言之，工具用了一大堆，瀏覽器開了十幾個(gè)窗口，效率低、體驗(yàn)差。

這三個(gè)痛點(diǎn)分別歸納為成本、效率、體驗(yàn)三個(gè)方面。針對(duì)這些痛點(diǎn)，接下來我們一起看下 Kubernetes 監(jiān)控的數(shù)據(jù)體系，看下怎么來更好的解決成本、效率、體驗(yàn)三大問題。

Kubernetes 監(jiān)控如何發(fā)現(xiàn)異常

下圖金子塔自頂向下表示信息的密度或者詳細(xì)程度，越往下面信息越詳細(xì)。我們從底部開始講，Trace 是我們通過eBPF技術(shù)以無入侵、多協(xié)議、多語言的方式采集應(yīng)用層協(xié)議數(shù)據(jù)，如 HTTP、MySQL、Redis，協(xié)議數(shù)據(jù)會(huì)進(jìn)一步解析成容易理解的請(qǐng)求詳情、響應(yīng)詳情、各個(gè)階段的耗時(shí)信息。

再上一層是指標(biāo)，指標(biāo)主要由黃金指標(biāo)、網(wǎng)絡(luò)、Kubernetes 體系中的指標(biāo)。其中黃金指標(biāo)和網(wǎng)絡(luò)指標(biāo)是基于 eBPF 采集的，所以同樣他們是沒有入侵的，支持各種協(xié)議的，有了黃金指標(biāo)，我們就能知道服務(wù)整體上是否有異常、是否有慢、是否影響用戶；網(wǎng)絡(luò)指標(biāo)主要是對(duì)socket的支持，如丟包率、重傳率、RTT 等，主要用來監(jiān)控網(wǎng)絡(luò)是否正常的指標(biāo)。Kubernetes 體系中的指標(biāo)是指原來 Kubernetes 監(jiān)控體系中的 cAdvisor/MetricServer/Node Exporter/NPD 這些指標(biāo)。

再上一層是事件，事件直接明確地告訴我們發(fā)生了什么，可能我們遇到最多的是 Pod 重啟、拉鏡像失敗等。我們對(duì) Kubernetes 事件進(jìn)行了持久化存儲(chǔ)，并保存一段時(shí)間，這樣方便定位問題。然后，我們的巡檢和健康檢查也是支持以事件的形式報(bào)出來。

最頂層是告警，告警是監(jiān)控系統(tǒng)的最后一環(huán)，當(dāng)我們發(fā)現(xiàn)某些特定異常可能對(duì)業(yè)務(wù)有損后，我們就需要對(duì)指標(biāo)、事件進(jìn)行告警配置。告警目前支持 PromQL，智能告警支持對(duì)歷史數(shù)據(jù)進(jìn)行智能算法檢測(cè)，從而發(fā)現(xiàn)潛在的異常事件。告警的配置支持動(dòng)態(tài)閾值，通過調(diào)節(jié)靈敏度的方式來配置告警，從而避免寫死閾值。

有了 Trace、指標(biāo)、事件、告警之后，我們用拓?fù)鋱D將這些數(shù)據(jù)和 Kubernetes 實(shí)體都關(guān)聯(lián)起來，每個(gè)節(jié)點(diǎn)對(duì)應(yīng) Kubernetes 實(shí)體中的服務(wù)和工作負(fù)載，服務(wù)之間調(diào)用用線表示。有了拓?fù)鋱D，我們就像拿到一張地圖，能快速識(shí)別拓?fù)鋱D中的異常，并對(duì)異常進(jìn)行進(jìn)一步的分析，對(duì)上下游、依賴、影響面進(jìn)行分析，從而對(duì)系統(tǒng)有了更全面的掌控。

最佳實(shí)踐&場(chǎng)景分析

接下來我們講下發(fā)現(xiàn) Kubernetes 中服務(wù)和工作負(fù)載的異常的最佳實(shí)踐。

首先還是先有指標(biāo)，指標(biāo)能反應(yīng)服務(wù)的監(jiān)控狀態(tài)，我們應(yīng)盡可能地收集各種指標(biāo)，并且越全越好，不限于黃金指標(biāo)、USE 指標(biāo)、Kubernetes 原生指標(biāo)等；然后，指標(biāo)是宏觀數(shù)據(jù)，需要做根因分析我們得有 Trace 數(shù)據(jù)，多語言、多協(xié)議的情況下要考慮采集這些 Trace 的成本，同樣盡可能地支持多一點(diǎn)協(xié)議、多一點(diǎn)語言；最后，用一張拓?fù)鋵⒅笜?biāo)、Trace、事件匯總起來、串聯(lián)起來，形成一張拓?fù)鋱D，用來做架構(gòu)感知分析、上下游分析。

通過這三種方法的分析，服務(wù)和工作負(fù)載的異常通常暴露無遺了，但我們不應(yīng)該就此停止前進(jìn)的腳步，加入這個(gè)異常下次再來，那么我們這些工作得重來一遍，最好的辦法是針對(duì)這類異常配置對(duì)應(yīng)的告警，自動(dòng)化地管理起來。

我們用幾個(gè)具體的場(chǎng)景來詳細(xì)介紹：

（一）網(wǎng)絡(luò)性能監(jiān)控

網(wǎng)絡(luò)性能監(jiān)控以重傳為例，重傳的意思是說發(fā)送方認(rèn)為發(fā)生了丟包現(xiàn)象，就重發(fā)這些數(shù)據(jù)包。以圖中的傳輸過程為例：

發(fā)送方發(fā)送編號(hào)為 1 的包，接收方接受了，返回 ACK 2

發(fā)送方發(fā)送編號(hào)為 2 的包，接收方返回 ACK 2

發(fā)送方發(fā)送編號(hào)為 3、4、5 的包，接收方都返回 ACK 2

直到發(fā)送方收到 3 次同樣的 ACK ，就會(huì)觸發(fā)重傳機(jī)制，重傳會(huì)導(dǎo)致延遲升高

代碼和日志是觀察不出來的，這種情形下最終很難找到根因。為了能快速定位這個(gè)問題，我們需要一組網(wǎng)絡(luò)性能指標(biāo)來提供定位依據(jù)，包含以下指標(biāo)，P50、P95、P99 指標(biāo)來表示延時(shí)，然后我們需要流量、重傳、RTT、丟包這些指標(biāo)來表征網(wǎng)絡(luò)情況。

以某個(gè)服務(wù) RT 高為例：首先我們看到拓?fù)涞倪吺羌t的，紅的判斷邏輯是根據(jù)延時(shí)、錯(cuò)誤來判斷的，當(dāng)發(fā)現(xiàn)這個(gè)紅邊的時(shí)候，點(diǎn)擊上面的邊，就可以看對(duì)應(yīng)的黃金指標(biāo)了。

點(diǎn)擊底部最左邊這個(gè)按鈕，可以查看當(dāng)前服務(wù)的網(wǎng)絡(luò)數(shù)據(jù)列表，我們可以按平均響應(yīng)時(shí)間、重傳、RTT 排下序，可以看到第一個(gè)服務(wù)調(diào)用延時(shí)比較高，快到一秒的返回時(shí)間，同時(shí)也看到重傳比較高，相比于其他服務(wù)高很多。這里其實(shí)是通過工具去注入了重傳高這么一個(gè)故障，看起來更明顯一些。這樣分析下來我們就知道可能是網(wǎng)絡(luò)的問題，就可以進(jìn)一步排查了。有經(jīng)驗(yàn)的開發(fā)一般會(huì)拿著網(wǎng)絡(luò)指標(biāo)、服務(wù)名、ip、域名這些信息去找網(wǎng)絡(luò)的同事排查，而不是只是告訴對(duì)方說我服務(wù)很慢，這樣對(duì)方知道的信息太少，就不會(huì)積極去排查，因?yàn)閯e人也不知道從哪里開始，當(dāng)我們提供了相關(guān)數(shù)據(jù)，對(duì)方就有了參考，會(huì)順藤摸瓜進(jìn)一步推進(jìn)。

（二）DNS 解析異常

第二個(gè)場(chǎng)景是 DNS 解析異常。DNS 通常是協(xié)議通信的第一步，比如 HTTP 請(qǐng)求，第一步就是先拿到 IP，也就是我們平常說的服務(wù)發(fā)現(xiàn)過程，第一步出現(xiàn)問題，整個(gè)調(diào)用就直接失敗了，這就是所謂關(guān)鍵路徑不能掉鏈子。在 Kubernetes 集群中所有的 DNS 都走 CoreDNS 的解析，所以 CoreDNS 上容易出現(xiàn)瓶頸，一旦出現(xiàn)問題，影響面也是非常大的，可能整個(gè)集群都不可用了。舉個(gè)兩個(gè)月前發(fā)生的鮮活的例子，著名的 CDN 公司 Akamai 就發(fā)生了一個(gè) DNS 故障，導(dǎo)致眾多網(wǎng)站像 Airbnb 網(wǎng)站無法訪問，事故持續(xù)了長(zhǎng)達(dá)一個(gè)小時(shí)。

在 Kubernetes 集群中 DNS 解析比較核心的幾個(gè)場(chǎng)景有三個(gè)：

調(diào)用外部 API 網(wǎng)關(guān)

調(diào)用云服務(wù)，云服務(wù)一般是公網(wǎng)的

調(diào)用外部中間件

這里對(duì) CoreDNS 常見的問題進(jìn)行了歸納，大家可以參考下，排查下自己的集群上有沒有類似問題：

配置問題（ndots 問題），ndots 是個(gè)數(shù)字，表示域名中點(diǎn)的個(gè)數(shù)要是小于 ndots，那么搜索就優(yōu)先走 search 列表中的域去查找，這樣的話會(huì)產(chǎn)生多次查詢，對(duì)性能的影響還是挺大的。

由于 Kubernetes 所有的域名解析都走 CoreDNS，非常容易成為性能瓶頸，有人統(tǒng)計(jì)過大概 qps 在 5000~8000 的時(shí)候就要關(guān)注性能問題了。尤其是依賴外部 Redis、MySQL 這種訪問量比較大的。

低版本的 CoreDNS 有穩(wěn)定性問題，這個(gè)也是需要關(guān)注的點(diǎn)。

有些語言，想 PHP 對(duì)連接池支持的不是很好，導(dǎo)致每次都要去解析 DNS，創(chuàng)建連接，這個(gè)現(xiàn)象也是比較常見的。

接下來，我們看下 Kubernetes CoreDNS 中可能會(huì)發(fā)生問題的地方，首先應(yīng)用和 CoreDNS 之間的網(wǎng)絡(luò)可能有問題；第二是 CoreDNS 本身問題，比如 CoreDNS 返回 SERVFAIL、REFUSE 這些錯(cuò)誤碼，甚至因?yàn)?Corefile 配置錯(cuò)了，導(dǎo)致返回值是錯(cuò)的；第三點(diǎn)是跟外部 DNS 通信的時(shí)候，發(fā)生網(wǎng)絡(luò)中斷、性能問題；最后一個(gè)是外部 DNS 不可用。

針對(duì)這些問題點(diǎn)總結(jié)出以下步驟來盤查：

第一、從客戶端側(cè)，先看下請(qǐng)求內(nèi)容和返回碼，如果是返回是錯(cuò)誤碼說明是服務(wù)端有問題。如果是慢解析，可以看下時(shí)間瀑布流看下時(shí)間耗費(fèi)在哪個(gè)階段。
第二、看網(wǎng)絡(luò)是否正常，看流量、重傳、丟包、RTT 這幾個(gè)指標(biāo)就夠了。
第三、查看服務(wù)端，看下流量、錯(cuò)誤、延時(shí)、飽和度這幾個(gè)指標(biāo)，再看下 CPU、內(nèi)存、磁盤等這幾個(gè)資源指標(biāo)，也能定位出是否有問題。
第四、看下外部 DNS，同理我們可以通過請(qǐng)求 Trace、返回碼、網(wǎng)路流量、重傳等指標(biāo)來定位。

接下來我們看下拓?fù)洹Ｊ紫瓤吹郊t色的線表示有異常的 DNS 解析調(diào)用，點(diǎn)擊這個(gè)我們能看到調(diào)用的黃金指標(biāo)；點(diǎn)擊查看列表，彈出詳情頁面，可查看請(qǐng)求的詳情，是請(qǐng)求這個(gè)域名，請(qǐng)求過程中經(jīng)歷發(fā)送、等待、下載三個(gè)過程，看起來指標(biāo)正常，接下來我們點(diǎn)擊看響應(yīng)，發(fā)現(xiàn)響應(yīng)是域名不存在。那么這時(shí)候我們可以進(jìn)一步看下外部 DNS 是否有問題，步驟也是一樣的，后面我會(huì)在 demo 中展示，所以這里就不展開先了。

（三）全鏈路壓測(cè)

第三個(gè)典型場(chǎng)景是全鏈路壓測(cè)，對(duì)于大促這種場(chǎng)景峰值是平常的數(shù)倍，怎么保障大促的穩(wěn)定，需要通過一系列的壓測(cè)來驗(yàn)證系統(tǒng)能力、系統(tǒng)穩(wěn)定性評(píng)估、做容量規(guī)劃、識(shí)別系統(tǒng)瓶頸。一般會(huì)有這么幾個(gè)步驟：先預(yù)熱下，這時(shí)候驗(yàn)證下鏈路是否正常的，逐步加流量直到峰值，然后開始摸高，也就是看下能支持的最大 TPS 是多少，接著再加流量，這時(shí)候主要就是看服務(wù)是否能正常限流了，因?yàn)橐呀?jīng)找過最大 TPS 了，再加大力量就是破壞性流量了。那么在這個(gè)過程中，我們需要關(guān)注哪些點(diǎn)呢？

首先針對(duì)我們多語言、多協(xié)議的微服務(wù)架構(gòu)，比如這里的 Java、Golang、Python 應(yīng)用，這里有 RPC、MySQL、Redis、Kafka 應(yīng)用層協(xié)議，我們得有各種語言、各種協(xié)議的黃金指標(biāo)，用來驗(yàn)證系統(tǒng)能力；針對(duì)系統(tǒng)的瓶頸、容量規(guī)劃這塊，我們需要 use 指標(biāo)，去看各種流量級(jí)別情況下資源的飽和度，來確定是不是要擴(kuò)容，每增加一次流量，對(duì)應(yīng)看下 use 指標(biāo)，對(duì)應(yīng)調(diào)整容量，逐步優(yōu)化；對(duì)于復(fù)雜架構(gòu)，需要有一張全局的大圖來幫助梳理上下游依賴、全鏈路架構(gòu)，確定爆炸報(bào)警，比如這里的 CheckoutService 就是個(gè)關(guān)鍵的服務(wù)，這個(gè)點(diǎn)如果出現(xiàn)問題，影響面會(huì)很大。

第一、各種語言、協(xié)議通信的黃金指標(biāo)，通過查看列表進(jìn)一步看調(diào)用的詳情
第二、點(diǎn)擊節(jié)點(diǎn)詳情下鉆查看 cpu、memory 等 use 資源指標(biāo)
第三、整個(gè)拓?fù)鋱D是能反映整個(gè)架構(gòu)的形態(tài)的，有了全局的架構(gòu)視角，就能識(shí)別哪個(gè)服務(wù)容易成為瓶頸、爆炸半徑有多大，是否需要做高可用保障。

（四）訪問外部 MySQL

第四個(gè)場(chǎng)景是訪問外部 MySQL，先看下訪問外部 MySQL 有哪些常見的問題：

首先是慢查詢，慢查詢提現(xiàn)為延時(shí)指標(biāo)高，這時(shí)候去看 trace 里面詳情請(qǐng)求是啥，查詢的是哪張表，哪些字段，進(jìn)而看下是不是查詢量太大了、表太大了、還是說沒有建索引等。

查詢語句過大，我們知道查詢語句太大會(huì)導(dǎo)致傳輸耗時(shí)高，網(wǎng)絡(luò)稍一抖動(dòng)就造成失敗重試，還會(huì)引發(fā)帶寬占用的問題。一般都是一些批量的更新、插入導(dǎo)致的，出現(xiàn)這種問題延時(shí)指標(biāo)會(huì)飆高，這時(shí)候我們可以選擇RT較高的一些 Trace 來看，看下語句怎么寫的、看下查詢語句的長(zhǎng)度是不是太大了。

錯(cuò)誤碼返回，比如表不存在這種，那么解析出其中的錯(cuò)誤碼就很有幫助了，再進(jìn)一步看里面的詳情，去看語句，就比較容易定位出根因了。

網(wǎng)絡(luò)問題，這個(gè)點(diǎn)也講過比較多了，一般配合著延時(shí)指標(biāo)加上 RTT、重傳、丟包來確定網(wǎng)絡(luò)是否有問題。

接下來看下拓?fù)鋱D，中間框住的應(yīng)用依賴了外部的 MySQL 服務(wù)，點(diǎn)擊拓?fù)渚€可以進(jìn)一步看黃金指標(biāo)，點(diǎn)擊查看列表可以進(jìn)一步看請(qǐng)求的詳情、響應(yīng)等。同時(shí)我們也可以看下網(wǎng)絡(luò)性能指標(biāo)，這個(gè) table 是將當(dāng)前拓?fù)渲械木W(wǎng)絡(luò)數(shù)據(jù)根據(jù)來源和目標(biāo)進(jìn)行歸類，可以分別查看請(qǐng)求數(shù)、錯(cuò)誤數(shù)、平均響應(yīng)時(shí)間、socket 重傳、socket rtt，點(diǎn)擊上面箭頭可以對(duì)應(yīng)地排序。

（五）多租戶架構(gòu)

第五個(gè)典型案例是多租戶架構(gòu)。多租戶指的是不同的租戶、工作負(fù)載、不同團(tuán)隊(duì)，公用一個(gè)集群，通常一個(gè)租戶對(duì)應(yīng)一個(gè)命名空間，同時(shí)保證資源的邏輯隔離或者物理隔離，互不影響、互不干擾。常見的場(chǎng)景有：企業(yè)內(nèi)部用戶，一個(gè)團(tuán)隊(duì)對(duì)應(yīng)一個(gè)租戶，同一個(gè)命名空間內(nèi)網(wǎng)絡(luò)不受限制，用網(wǎng)絡(luò)策略去控制不同命名空間之間的網(wǎng)絡(luò)流量。第二種是 SaaS 提供商多租戶架構(gòu)，每個(gè)用戶對(duì)應(yīng)一個(gè)命名空間，同時(shí)租戶和平臺(tái)分別處于不同的命名空間。雖然 Kubernetes 的命名空間特性給多租戶架構(gòu)帶來了便利，但也給可觀測(cè)帶來兩個(gè)挑戰(zhàn)：第一命名空間非常多，查找信息變得很繁瑣，增加了管理成本、理解成本。第二是租戶之間有流量隔離的要求，在命名空間比較多的情況下往往無法做到準(zhǔn)確、全面的發(fā)現(xiàn)異常流量。第三是對(duì)多協(xié)議、多語言的 Trace 支持。曾經(jīng)遇到過一個(gè)客戶，一個(gè)集群里面有 400 多個(gè)命名空間，管理起來非常痛苦，而且應(yīng)用是多協(xié)議、多語言的，要支持 Trace，得一個(gè)個(gè)改造。

這是我們產(chǎn)品的集群首頁，Kubernetes 的實(shí)體以命名空間的方式劃分，支持查詢來定位到我想看的集群。氣泡圖上展示對(duì)應(yīng)命名空間上的實(shí)體數(shù)，以及有異常的實(shí)體數(shù)，比如框子里 3 個(gè)命名空間里存在有異常的 pod，點(diǎn)進(jìn)去可以進(jìn)一步看異常。首頁下面是按黃金指標(biāo)排序的性能概覽，也就是場(chǎng)景的 Top 功能，這樣能快速查看哪幾個(gè)命名空間是有異常的。

在拓?fù)鋱D中，如果命名空間比較多，可以通過過濾功能查看想看的命名空間，或者通過搜索方式快速定位到想看的命名空間。由于節(jié)點(diǎn)是以命名空間分組的，能通過命名空間之間的線來查看命名空間的流量，這樣就能方便地查看有來自哪些命名空間的流量、是否有異常流量等等。

我們將上述場(chǎng)景介紹總結(jié)如下：

網(wǎng)絡(luò)監(jiān)控：如何能分析網(wǎng)絡(luò)導(dǎo)致的服務(wù)的錯(cuò)慢、中斷，如何分析網(wǎng)絡(luò)問題帶來的影響

服務(wù)監(jiān)控：如何通過黃金指標(biāo)確定服務(wù)是否健康？如何通過支持多協(xié)議的 Trace 查看詳情？

中間件、基礎(chǔ)設(shè)施監(jiān)控：如何用黃金指標(biāo)、trace 分析中間件、基礎(chǔ)設(shè)施的異常，如何快速定界是網(wǎng)絡(luò)問題，還是自身問題，還是下游服務(wù)問題

架構(gòu)感知：如何通過拓?fù)涓兄麄€(gè)架構(gòu)，梳理上下游、內(nèi)部外部依賴，進(jìn)而能掌控全局？如何通過拓?fù)浔Ｕ霞軜?gòu)有足夠的觀測(cè)性、穩(wěn)定性保障，如何通過拓?fù)浞治觥l(fā)現(xiàn)系統(tǒng)中的瓶頸、爆炸半徑。

從這幾個(gè)場(chǎng)景中又進(jìn)一步列舉常見的 case：網(wǎng)絡(luò)、服務(wù)的可用性檢測(cè)，健康檢查；中間件架構(gòu)升級(jí)可觀測(cè)性保障；新業(yè)務(wù)上線驗(yàn)證；服務(wù)性能優(yōu)化；中間件性能監(jiān)控；方案選型；全鏈路壓測(cè)等。

產(chǎn)品價(jià)值

經(jīng)過以上內(nèi)容介紹，我們將 Kubernetes 的產(chǎn)品價(jià)值總結(jié)如下：

通過多協(xié)議、多語言、無入侵的方式采集服務(wù)的指標(biāo)和 Trace 數(shù)據(jù)，最大限度地減少接入的成本，同時(shí)提供覆蓋度全面的指標(biāo)和Trace；

有了這些指標(biāo)和 Trace 之后我們就能，對(duì)服務(wù)和工作負(fù)載進(jìn)行科學(xué)的分析、下鉆；

將這些指標(biāo)、Trace 關(guān)聯(lián)起來串成一張拓?fù)鋱D，能在一張大圖上進(jìn)行架構(gòu)感知、上下游分析、上下文關(guān)聯(lián)等，充分得理解架構(gòu)，評(píng)估潛在的性能瓶頸等，方便做進(jìn)一步的架構(gòu)優(yōu)化；

提供配置簡(jiǎn)單的告警配置方法，將經(jīng)驗(yàn)知識(shí)沉淀到告警中，做到主動(dòng)發(fā)現(xiàn)。

本節(jié)課的內(nèi)容到這里就結(jié)束了，歡迎大家前往釘釘搜索群號(hào)（31588365）加入答疑交流群進(jìn)行交流。

目前 Kubernetes 監(jiān)控已經(jīng)全面免費(fèi)公測(cè)，點(diǎn)擊下方鏈接，立即開啟試用！
https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n

總結(jié)

以上是生活随笔為你收集整理的如何发现 Kubernetes 中服务和工作负载的异常的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。