在阿里巴巴，我們?nèi)绾蜗扔谟脩舭l(fā)現(xiàn)和定位 Kubernetes 集群問題？

作者：彭南光(光南) 2022-03-02 14:06:36

運(yùn)維

云計算 本文整理自阿里云高級研發(fā)工程師彭南光(光南) 在 KubeCon China 2021 大會的演講實(shí)錄，分享了阿里巴巴是如何通過自研通用鏈路探測+定向巡檢工具 KubeProbe 應(yīng)對大規(guī)模集群的穩(wěn)定性挑戰(zhàn)的。

為鄂托克等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及鄂托克網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站制作、網(wǎng)站設(shè)計、鄂托克網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

快速發(fā)現(xiàn)和定位問題的能力是快速恢復(fù)系統(tǒng)的基石，只有先做到快速發(fā)現(xiàn)和定位問題，才能談如何解決問題，盡量減少用戶損失。那么如何在復(fù)雜的大規(guī)模場景中，做到真正的先于用戶發(fā)現(xiàn)和定位問題呢？我會將我們在管理大型  Kubernetes  集群過程中快速發(fā)現(xiàn)和定位問題的一些經(jīng)驗(yàn)和實(shí)踐帶給大家——我們是如何通過自研通用鏈路探測+定向巡檢工具 KubeProbe 應(yīng)對遇到的大規(guī)模集群的穩(wěn)定性挑戰(zhàn)的。

鏈路探測： 模擬廣義用戶行為，探測鏈路和系統(tǒng)是否異常

定向檢測： 檢查集群異常指標(biāo)，發(fā)現(xiàn)未來存在或可能存在的風(fēng)險點(diǎn)

系統(tǒng)增強(qiáng)： 發(fā)現(xiàn)問題提速增效，根因分析

發(fā)現(xiàn)問題之后： 后置檢查和自愈，Chat-Ops

01 業(yè)務(wù)背景和挑戰(zhàn)

Cloud Native

阿里云云原生應(yīng)用平臺的容器服務(wù)團(tuán)隊(duì)，擁有 ACK 、ASI 等產(chǎn)品，管理了大規(guī)模的 Kubernetes 集群，不僅向外部公有云用戶提供 Kubernetes 服務(wù)，還承擔(dān)了阿里巴巴集團(tuán)上云，阿里巴巴應(yīng)用全面容器化的工作。

目前，整個阿里巴巴的業(yè)務(wù)都跑在 Kubernetes 集群上并實(shí)現(xiàn)了云原生和容器化，例如：天貓/淘寶/高德/考拉/餓了么等等。容器服務(wù)作為阿里云的管控底座，各種云服務(wù)也運(yùn)行在這些集群之上，例如視頻云/dataworks /MSE 微服務(wù)引擎/MQ 消息隊(duì)列等等。我們需要對這些基礎(chǔ)設(shè)施的穩(wěn)定性負(fù)責(zé)。

現(xiàn)在，云原生的架構(gòu)越來越流行，越來越多的產(chǎn)品和應(yīng)用開始選擇云原生架構(gòu)，這里有一張圖，大致示意了現(xiàn)代的云原生應(yīng)用架構(gòu)，應(yīng)用生于云上，長于云上，各級提供分層的服務(wù)，這種分層的服務(wù)能夠讓業(yè)務(wù)和應(yīng)用專注于業(yè)務(wù)層，屏蔽平臺和基礎(chǔ)設(shè)施層的復(fù)雜概念。

從穩(wěn)定性的角度來講，這種應(yīng)用的架構(gòu)分層，上層應(yīng)用的穩(wěn)定性就會開始依賴底層基礎(chǔ)設(shè)施的支持；另外，大一統(tǒng)的基座既為大規(guī)模的資源調(diào)度優(yōu)化和在離線混部提供場景，也對基礎(chǔ)設(shè)施團(tuán)隊(duì)維護(hù)大規(guī)模集群的穩(wěn)定性問題提出極大的挑戰(zhàn)。

這里有兩張形象的圖示可以展現(xiàn)出云原生應(yīng)用架構(gòu)下的業(yè)務(wù)應(yīng)用和平臺層基礎(chǔ)設(shè)施的關(guān)系，Kubernetes 集群是非常復(fù)雜的，一個單集群的鏈路組件就有數(shù)十個甚至上百個之多，何況是大規(guī)模的多 集群管理呢？ 但運(yùn)行在上層 的業(yè)務(wù)同學(xué) 并不會感知到 復(fù)雜，因?yàn)槲覀円呀?jīng)把復(fù)雜包掉了，留給用戶的是一個簡單的統(tǒng)一接口 。 就像 淘寶這 樣的應(yīng)用其實(shí)是非常復(fù)雜的，但在 用戶看 來只 是一個簡單的提交訂單而已，按鍵背后蘊(yùn)含著 極其復(fù)雜的內(nèi)容。 為什么做到這樣？ 因?yàn)槲覀儼褟?fù)雜留給了自己，把簡單交給了用 戶。

很多時候，好的應(yīng)用開發(fā)者不一定是基礎(chǔ)設(shè)施專家，云原生讓業(yè)務(wù)專注業(yè)務(wù)，基礎(chǔ)設(shè)施專注基礎(chǔ)設(shè)施。同時，業(yè)務(wù)很多時候也只能關(guān)心業(yè)務(wù)自身的穩(wěn)定性，業(yè)務(wù)大多數(shù)時候沒有能力關(guān)心，或者是不希望投入大量的人力關(guān)心基礎(chǔ)設(shè)施和平臺層的穩(wěn)定性，所以，關(guān)于平臺層和基礎(chǔ)設(shè)施的穩(wěn)定性問題上，我們需要把復(fù)雜留給自己，把簡單留給用戶，為用戶提供穩(wěn)定的平臺層服務(wù)。同時，更加關(guān)心全局穩(wěn)定性和全局的可用性，而不是單點(diǎn)可用性。

容器服務(wù)是阿里巴巴集團(tuán)業(yè)務(wù)以及阿里云管控/云服務(wù)的底座，上面跑著各種各樣的業(yè)務(wù)，如電商業(yè)務(wù)/中間件/二方業(yè)務(wù)/搜索/阿里云云服務(wù)等等。此外還有數(shù)百個自研和開源的組件，每年數(shù)十萬次的組件變更/數(shù)千個集群/數(shù)十萬臺節(jié)點(diǎn)，甚至大的集群單集群節(jié)點(diǎn)規(guī)模已過萬。業(yè)務(wù)架構(gòu)更是紛繁復(fù)雜，有單租集群、多租集群、vc 集群、聯(lián)邦集群等等，同時還有各種在離線混布、統(tǒng)一調(diào)度、大促活動。在運(yùn)行時也存在多種形態(tài)，如 runC，runD 等等。

因此組件的繁雜、變更頻繁、用戶場景各異、集群規(guī)模龐大、業(yè)務(wù)架構(gòu)復(fù)雜……都給業(yè)務(wù)帶來了挑戰(zhàn)：

挑戰(zhàn)一：如何降低系統(tǒng)風(fēng)險。 場景復(fù)雜，業(yè)務(wù)形態(tài)各異，任何一個不起眼細(xì)節(jié)的遺漏或環(huán)節(jié)的處置不慎都有可能導(dǎo)致傷害的擴(kuò)大化；

挑戰(zhàn)二：如何對用戶集群的穩(wěn)定性負(fù)責(zé)。 如何先于用戶發(fā)現(xiàn)和定位問題成為容器服務(wù)生產(chǎn)穩(wěn)定性建設(shè)的重中之重，也是全局高可用體系的基石。

系統(tǒng)是如此的復(fù)雜，任何一個不起眼的細(xì)節(jié)遺漏或處理不慎都有可能導(dǎo)致非預(yù)期的傷害，我們要怎樣才能降低系統(tǒng)風(fēng)險呢？另外我們又是如何對形態(tài)各異的用戶集群運(yùn)行時全局穩(wěn)定性負(fù)責(zé)的呢？如何才能先于用戶發(fā)現(xiàn)和定位這些集群中已經(jīng)存在或即將發(fā)生的問題，是保障集群的穩(wěn)定性建設(shè)的重中之重，也是 Kubernetes 全局高可用體系的基石。

02 思考和方案

Cloud Native

基于這些挑戰(zhàn)，我們做了一些思考和預(yù)設(shè)。下圖是一個極度簡化的用戶發(fā)布擴(kuò)容鏈路，雖說極度簡化，但實(shí)際我們?nèi)钥梢钥闯?，鏈路還是比較復(fù)雜的。

為了保障這次用戶的擴(kuò)容/發(fā)布鏈路暢通，我們首先帶來幾個預(yù)設(shè)：

預(yù)設(shè) 1： 鏈路復(fù)雜組件眾多，各組件分別升級迭代，數(shù)據(jù)監(jiān)控?zé)o法無死角覆蓋全部場景；

預(yù)設(shè) 2： 即使鏈路中各組件/節(jié)點(diǎn)監(jiān)控數(shù)據(jù)正常，也不能保證集群整體鏈路 100% 可用，只有經(jīng)過實(shí)際業(yè)務(wù)全鏈路探測才能確定實(shí)際可用的結(jié)論；

預(yù)設(shè) 3： 反證法在證明集群不可用場景一定優(yōu)于舉證法，即使 100% 監(jiān)控數(shù)據(jù)正常，但只要發(fā)布失敗則證明鏈路不通。

另外，在單集群之外，我們還要關(guān)注多集群的管理，下面是一些多集群管控中的不穩(wěn)定性因素示例，可以看到，多集群場景下，穩(wěn)定性管控的復(fù)雜度會被放大，我們繼續(xù)帶來幾個預(yù)設(shè)：

預(yù)設(shè) 4： 在大規(guī)模集群場景下數(shù)據(jù)一致性的問題會愈加顯現(xiàn)，并且可能引發(fā)嚴(yán)重故障，成為一個顯著的不穩(wěn)定因素；

預(yù)設(shè) 5： 集群內(nèi)的監(jiān)控告警鏈路存在自依賴風(fēng)險，如果集群故障，則監(jiān)控告警也有可能同時故障。

接下來是我們基于以上預(yù)設(shè)的一些解決方案。

探索和解決方案

1.  鏈路探測

鏈路探測即模擬廣義上的用戶行為，探測鏈路是否暢通，流程是否無異常。

想要做到先于用戶發(fā)現(xiàn)系統(tǒng)問題，我們自己首先要成為系統(tǒng)用戶，并且是使用最多、了解最深、無時無刻不在使用和感知系統(tǒng)狀態(tài)的用戶。

所謂鏈路探測，就是模擬廣義上的用戶行為，去對集群組件鏈路中的各種等待探測的對象去做探測。此處要特別說明的是，這里的用戶并不僅僅指的是狹義上使用系統(tǒng)的同學(xué)，而是更廣義的用戶，或者可以理解和引申成為依賴下游。

另外，在實(shí)現(xiàn)全鏈路探測的同時，拆解電路，實(shí)現(xiàn)全電路中的短路探測也是非常必要的，也是對全鏈路探測的一個補(bǔ)充。

2.  定向巡檢

定向巡檢是指檢查和分析大規(guī)模集群的異常指標(biāo)，找到已有或?qū)砜赡艽嬖诘娘L(fēng)險點(diǎn)，就像檢修管道一樣。

例如有若干個集群，它分為很多集群組，不同集群組之間的 etcd 冷/熱備是否配置齊備，風(fēng)控限流配置是否正常，webhook 版本是否正常，混部參數(shù)是否一致，包括它的證書有效期是不是快要到期了等等。不同的集群組之間可能有所差別，但同類型集群之間是有一個轉(zhuǎn)衡的，因此我們可以定向做一些巡檢。

接下來是關(guān)于鏈路探測的一些常見場景：

就像一個游戲策劃，如果他連自己制作的游戲都不玩，他可能發(fā)現(xiàn)游戲機(jī)制的問題，把這個游戲越做越好嗎？我們要做到先于用戶發(fā)現(xiàn)系統(tǒng)問題，那我們自己首先就要先成為系統(tǒng)的用戶，并且一定是使用最多的，了解最深的，無時無刻不在使用和感知系統(tǒng)狀態(tài)的用戶。

另外，所謂鏈路探測，就是讓自己成為自己系統(tǒng)的用戶，模擬廣義上的“用戶”行為去對集群/組件/鏈路里的各種等待探測的對象去做探測。

一定要注意，這里的“用戶”并不僅僅指的是狹義上使用系統(tǒng)的同學(xué)，而是更廣義的用戶，或者可以理解引申為依賴下游。

例如業(yè)務(wù)同學(xué)要發(fā)布業(yè)務(wù)，就必然要經(jīng)過 git 系統(tǒng)，再到發(fā)布系統(tǒng)，再到我們底層的基礎(chǔ)設(shè)施平臺，也就是我們的 ASI，這就是一次全鏈路探測流程。在這里業(yè)務(wù)同學(xué)就是用戶，探測對象可以是全鏈路。

但如果我們把 etcd 看作一個系統(tǒng)服務(wù)，那么 APIServer 就是它廣義上的用戶，我們模擬 APIServer 請求 etcd 這條鏈路的探測也就有了意義。

另外像 MSE 操作 zookeeper，外部用戶通過阿里云控制臺創(chuàng)建 ACK 集群，PaaS 平臺操作聯(lián)邦集群，甚至視頻云業(yè)務(wù)方發(fā)起一次轉(zhuǎn)碼任務(wù)，都是一樣的道理。

還有一點(diǎn)要關(guān)注的就是，雖然全鏈路探測看起來很美，但很多時候，全鏈路探測同時還很長，可能等到失敗的時候問題已經(jīng)很大了。所以，在實(shí)現(xiàn)全鏈路探測的同時，拆解鏈路，實(shí)現(xiàn)全鏈路中的短鏈路探測也是非常必要的，也是對全鏈路探測的一個補(bǔ)充。

上圖是定向巡檢的場景，相比鏈路探測關(guān)注于鏈路可用性，定向巡檢的核心還是在大規(guī)模的集群場景下，數(shù)據(jù)一致性是非常困難的問題，數(shù)據(jù)不一致，將導(dǎo)致一些隱患，可能會在未來引發(fā)某些不確定性的故障。

所謂定向巡檢就是對整個集群或鏈路中的各項(xiàng)數(shù)據(jù)、指標(biāo)做已知原因的檢查，找出不一致或數(shù)據(jù)偏離的點(diǎn)，判斷是否可能引發(fā)風(fēng)險，從而做到防患于未然，治未病。

比如我們這個里邊有同一種類型的集群組，A 集群發(fā)現(xiàn)它的證書有效期不到三年，而其他集群的證書有效期都有三年；B 集群的 webhook 版本可能是 v2，而其他集群的 webhook 版本是 v3；C 集群的風(fēng)控限流配置并沒有配一個驅(qū)逐 Pod 的限流，但其他集群都配配置了驅(qū)逐 Pod 的限流，這肯定是不符合預(yù)期的；再比如 D 集群的 etcd 的冷/熱備沒有配置或者是運(yùn)行不正常，我們也可以先把它檢查出來。

03 系統(tǒng)實(shí)現(xiàn)

Cloud Native

基于上面許許多多的背景預(yù)設(shè)以及方案，我們設(shè)計并實(shí)現(xiàn)了一套巡檢/探測平臺，我們?nèi)∶麨?KubeProbe (并未開源，和現(xiàn)在社區(qū)上有類似命名的項(xiàng)目沒有任何聯(lián)系)。

我們早期也曾考慮使用社區(qū)項(xiàng)目 Kuberhealthy，并為 Kuberhealthy 做過一些代碼貢獻(xiàn)，修復(fù)過一些嚴(yán)重的代碼 Bug，最終因?yàn)楣δ苌喜惶m用于我們的場景，我們選擇了自研自建。

上圖是一套中心架構(gòu)，我們會有一套中心管控系統(tǒng)。用戶的用例會通過統(tǒng)一倉庫的鏡像的方式接入，使用我們通用的 sdk 庫，自定義巡檢和探測邏輯。我們會在中心管控系統(tǒng)上配置好集群和用例的關(guān)系配置，如某用例應(yīng)該執(zhí)行在哪些集群組上，并做好各種運(yùn)行時配置。我們支持了周期觸發(fā)/手動觸發(fā)/事件觸發(fā)(如發(fā)布)的用例觸發(fā)方式。用例觸發(fā)后會在集群內(nèi)創(chuàng)建一個執(zhí)行巡檢/探測邏輯的 Pod，這個 Pod 里會執(zhí)行各種用戶自定義的業(yè)務(wù)巡檢/探測邏輯，并在成功和失敗后通過直接回調(diào)/消息隊(duì)列的方式通知中心端。中心端會負(fù)責(zé)告警和用例資源清理的工作。

我舉一個例子，比如 Kubelet 在我們的組件運(yùn)維平臺上做分批發(fā)布，每批次都會觸發(fā)一次相關(guān)集群的鏈路探測用例作為后置檢查，一旦我們發(fā)現(xiàn)某次發(fā)布的后置檢查失敗，我們會阻斷掉用戶的當(dāng)前發(fā)布，防止傷害擴(kuò)大，同時第一時間告警以及通知相關(guān)同事進(jìn)入排查，是否組件新版本不符合預(yù)期。

同時，我們也支持第三方的事件回調(diào)，可以更快的集成進(jìn)三方系統(tǒng)中。

另外，我們對于某些需要 7*24 小時不間斷的高頻次短周期探測用例，我們還實(shí)現(xiàn)了另外一套常駐分布式架構(gòu)，這套架構(gòu)使用一個集群內(nèi)的 ProbeOperator 監(jiān)聽 Probe Config CRD 變化，在探測 pod 中周而復(fù)始的執(zhí)行探測邏輯。這套架構(gòu)，完美復(fù)用了 KubeProbe 中心端提供的告警/根因分析/發(fā)布阻斷等等附加功能，同時使用了標(biāo)準(zhǔn)  Operator 的云原生架構(gòu)設(shè)計，常駐體系帶來了極大的探測頻率提升(因?yàn)槿サ袅藙?chuàng)建巡檢 pod 和清理數(shù)據(jù)的開銷)基本可以做到對集群的 7*24 小時無縫覆蓋，同時便于對外集成。

另外還有一個必須要提的非常重要的點(diǎn)，即平臺只是提供了一個平臺層的能力支持，真正這個東西要起作用，還是要看在這個平臺上構(gòu)建的用例是否豐富，能不能方便的讓更多人進(jìn)來寫各種巡檢和探測用例。就像測試平臺很重要，但測試用例比測試平臺更重要這個道理一樣。一些通用的 workload 探測，組件探測，固然能發(fā)現(xiàn)很多管控鏈路上的問題，但是更多的問題，甚至業(yè)務(wù)層的問題暴露，實(shí)際上依賴于基礎(chǔ)設(shè)施和業(yè)務(wù)層同學(xué)的共同努力。

從我們的實(shí)踐上來說，測試同學(xué)和業(yè)務(wù)同學(xué)貢獻(xiàn)了很多相關(guān)的檢查用例，比如測試同學(xué)貢獻(xiàn)的 ACK & ASK 的創(chuàng)建刪除全鏈路探測巡檢，金絲雀業(yè)務(wù)全鏈路擴(kuò)容用例，比如本地生活同學(xué)的 PaaS 平臺應(yīng)用檢查等等，也得到了很多穩(wěn)定性上的結(jié)果和收益。目前我們維護(hù)的巡檢/探測用例有數(shù)十個，明年有機(jī)會破百，巡檢/探測次數(shù)近 3000 萬次，明年可能會過億。目前可以提前發(fā)現(xiàn) 99%以上的集群管控問題和隱患，效果是非常好的。

04 發(fā)現(xiàn)問題之后：根因分析和事件處理

Cloud Native

接下來我們聊聊發(fā)現(xiàn)問題之后的事情，這里有一個類似于問診對話的例子，患者發(fā)現(xiàn) “哎呀我不舒服了！ ” 這就是發(fā)現(xiàn)問題。醫(yī)生參考各種化驗(yàn)單，同時做了信息聚合分析推斷，告訴患者“你已經(jīng) 24 小時沒睡覺了，你睡不著是因?yàn)槟愫芙箲]，你焦慮的根因是因?yàn)楹筇炀鸵谀┛荚嚵?。”這便是定位問題根因，然后針對根因去解決這個問題，他告訴患者“不要擔(dān)心，我剛收到的消息，小學(xué)生已經(jīng)不需要期末考試了?！边@個過程一定要快！

來自探測鏈路的告警內(nèi)容往往是混沌的，和數(shù)據(jù)監(jiān)控告警是有所差異的。就像上文提到的，鏈路探測告警的告警很可能就是一句患者的我不舒服了，需要你作為醫(yī)生去判斷，為什么他不舒服了呢？根因是什么。而數(shù)據(jù)監(jiān)控很多時候本身就代表了原因，比如 Etcd OOM，用已有的 oncall 經(jīng)驗(yàn)可能得不到最好的效果。

另外快速定位問題和根因分析，是一個樹狀的搜索，經(jīng)驗(yàn)加工判斷的過程，也就是如何從一個混沌的表象推斷出根因，核心是邏輯。

這和健康體檢是不同的，健康體檢是列出檢查項(xiàng) 1，2，3，4，5......然后告訴你一堆數(shù)值。很多時候，即使存在體檢中心，我們?nèi)匀灰残枰t(yī)院的專業(yè)醫(yī)生來為您解讀和判斷病情，不是嗎？

同時，根因分析/問題自愈的關(guān)鍵在于專家經(jīng)驗(yàn)的下沉，也就是把專家經(jīng)驗(yàn)下沉到系統(tǒng)中去，專家經(jīng)驗(yàn)的下沉帶來的最大收益是可復(fù)用可輸出。你可以想一下，如果我們把一個最專業(yè)的醫(yī)生的能力放進(jìn)系統(tǒng)里，他是不是更方便的為每一個人分析病情呢？

這便是 KubeProbe 發(fā)現(xiàn)問題之后的全流程，我們首先會經(jīng)過一個我們自建的中心化根因分析系統(tǒng)，在這里我們會聚合分析所有和本次失敗相關(guān)的信息，包括事件/日志/變更/告警/組件升級等等，我們將這些信息進(jìn)行聚合分析，并對事件做關(guān)聯(lián)處理，最終通過一個樹狀的分析系統(tǒng)初步定位出某次探測失敗的原因，比如說 APIServer 超時或者 etcd 斷連等等。

此外我再補(bǔ)充一點(diǎn)，文本聯(lián)想也是一個很好的根因分析方式，我們可以通過機(jī)器學(xué)習(xí)訓(xùn)練文本識別的方式來聯(lián)想出和這種失敗 case 最關(guān)聯(lián)的根因，這種 AIOps 的工作我們只是略微涉及，還在持續(xù)的探索中，我們的數(shù)據(jù)量非常大，我認(rèn)為這一定是未來的方向之一。

KubeProbe 根因分析和后置處理全流程

上圖的左下方是某次我們失敗的告警，它經(jīng)過根因分析系統(tǒng)之后發(fā)現(xiàn)首先最核心，最關(guān)聯(lián)，最大的原因可能是 APIserver 的連接斷開并且當(dāng)前已經(jīng)恢復(fù)，所以可能只是偶發(fā)的網(wǎng)絡(luò)抖動，我們暫時不用特別關(guān)注，但此時可以看到置信度為 90%。

另外還有一些可能的原因都會關(guān)聯(lián)起來。比如某個組件，這次探測它是由某一個組件發(fā)布出發(fā)的，它的發(fā)布人是 XXX，我們可以觀察這個發(fā)布對 API server 會產(chǎn)生某些影響，是否多次 list watch 不符合預(yù)期，然后把 API server list watch 出問題了，置信度有 50%。

當(dāng)我們得到一個初步的原因之后，我們會進(jìn)入二次確認(rèn)系統(tǒng)做二次的原因確認(rèn)，比如我們判斷原因可能是 APIServer 超時/etcd 斷聯(lián)/節(jié)點(diǎn)超時等,我們就會自動重新拉取一下 APIServer 接口，看一下此時是否仍然超時，是否恢復(fù)，如果恢復(fù)了，我們就普通告警，并且告訴用戶，現(xiàn)在沒事了，但是你得關(guān)注。如果沒恢復(fù)，那這就很嚴(yán)重了，屬于最高優(yōu)先級，直接電話告警。

就是這個思路，如果有系統(tǒng)無法定位的問題，并且持續(xù)無法定位，我們也會觸發(fā)高級別告警，并且會增加相關(guān)的根因分析識別樹邏輯。

過多的告警等于沒有告警，我是最討厭告警海的。從經(jīng)驗(yàn)上講，當(dāng)我們構(gòu)建了一套這樣的根因分析+二次確認(rèn)+后置檢查系統(tǒng)之后，我們的 Oncall 成本下降了 90% 以上，并且還能夠持續(xù)下降，終態(tài)可以說是無人值守，大家也可以試試類似的工作，可以說是投入小，見效大。自從這些系統(tǒng)建設(shè)起來以后，我們可以自豪的說，我們用很小的精力 Oncall 了每一個告警條目（對，是每一條告警，是數(shù)千個集群，數(shù)千萬次探測巡檢的每一條告警）并且不會有任何遺漏了。

最后是一些給 Oncall 人員的小甜品，Chat-ops。

基于 NLP 語義識別的 Chat-ops 系統(tǒng)

我們利用釘釘提供的 NLP 機(jī)器人，構(gòu)建了一套比較完善的 Chat-ops 系統(tǒng)，這樣之后我們的 Oncall 人員就可以很方便的在告警群里通過聊天的方式操作 KubeProbe 相關(guān)功能了，比如：重跑失敗探測，查詢集群狀態(tài)，拉取診斷信息，查詢探測日志，集群告警靜默。

上圖是我們操作 Chat-ops 系統(tǒng)的過程。這個過程非常方便。

比如晚上我已經(jīng)再被窩里了，這時候它給我了一個告警，比如某個集群之前出現(xiàn)了某次失敗但當(dāng)前已經(jīng)恢復(fù)了，需要我關(guān)注一下。

既然我關(guān)注了，我便希望某一個常用例再跑一次（它可能周期比較長，例如一個鐘頭），由于短鏈路的用例可能隨時都在跑，此時我便告訴機(jī)器人再跑一次，機(jī)器人就會識別我的語義，將集群再跑一次。跑完之后，我再通過查詢狀態(tài)看一下這個集群當(dāng)前的狀態(tài)怎么樣了，這樣是非常方便的，有時候你晚上上班了，或者是在路上，或者是在被窩里，都也可以很舒服的去 on-call 一個系統(tǒng)了。

05 Demo 示例

Cloud Native

1、發(fā)布

2、探測列表

3、探測 Pod 開始運(yùn)行

4、探測結(jié)果

5、根因分析&告警

6、Chat-ops

網(wǎng)站名稱：在阿里巴巴，我們?nèi)绾蜗扔谟脩舭l(fā)現(xiàn)和定位 Kubernetes 集群問題？
本文來源：http://www.5511xx.com/article/djgiodd.html