摘要：雖然多數(shù)時(shí)候，我們的系統(tǒng)都做了容錯(cuò)保護(hù)，但我們還是需要能盡快的發(fā)現(xiàn)故障，才好進(jìn)行故障轉(zhuǎn)移。而這個(gè)故障其實(shí)是知道的，所以故障檢測(cè)的原理很簡(jiǎn)單，從發(fā)起請(qǐng)求的這一端來(lái)觀察，如果發(fā)現(xiàn)有問(wèn)題，那就是有故障了。于是作者開(kāi)發(fā)了這套系統(tǒng)，來(lái)對(duì)故障進(jìn)行檢測(cè)。

作者：唐劉

在對(duì) TiDB 進(jìn)行 Chaos 實(shí)踐的時(shí)候，我一直在思考如何更好的發(fā)現(xiàn) TiDB 整個(gè)系統(tǒng)的故障。最開(kāi)始，我們參考的就是 Chaos Engineering 里面的方式，觀察系統(tǒng)的穩(wěn)定狀態(tài)，注入一個(gè)錯(cuò)誤，然后看 metrics 上面有啥異常，這樣等實(shí)際環(huán)境中出現(xiàn)類似的 metrics，我們就知道發(fā)現(xiàn)了什么故障。

但這套機(jī)制其實(shí)依賴于如何去注入錯(cuò)誤，雖然現(xiàn)在我們已經(jīng)有了很多種錯(cuò)誤注入的方式，但總有一些實(shí)際的情況我們沒(méi)有料到。所以后來(lái)我們又考慮了另外的一種方式，也就是直接對(duì) metrics 歷史進(jìn)行學(xué)習(xí)，如果某一段時(shí)間 metrics 出現(xiàn)了不正常的波動(dòng)，那么我們就能報(bào)警。但這個(gè)對(duì)我們現(xiàn)階段來(lái)說(shuō)難度還是有點(diǎn)大，只使用了幾種策略，對(duì) QPS，Latency 這些進(jìn)行了學(xué)習(xí)，并不能很好的定位到具體出了什么樣的問(wèn)題。

所以我一直在思考如何更好的去發(fā)現(xiàn)系統(tǒng)的故障。最近，剛好看到了 OSDI 2018 一篇 Paper，Capturing and Enhancing In Situ System Observability for Failure Detection，眼睛一亮，覺(jué)得這種方式也是可以來(lái)實(shí)踐的。

大家都知道，在生產(chǎn)環(huán)境中，故障是無(wú)處不在，隨時(shí)可能發(fā)生的，譬如硬件問(wèn)題，軟件自身的 bug，或者運(yùn)維使用了一個(gè)錯(cuò)誤的配置這些。雖然多數(shù)時(shí)候，我們的系統(tǒng)都做了容錯(cuò)保護(hù)，但我們還是需要能盡快的發(fā)現(xiàn)故障，才好進(jìn)行故障轉(zhuǎn)移。

但現(xiàn)實(shí)世界并沒(méi)有那么美好，很多時(shí)候，故障并不是很明顯的，譬如整個(gè)進(jìn)程掛掉，機(jī)器壞掉這些，它們處于一種時(shí)好時(shí)壞的狀態(tài)，我們通常稱為「Gray Failure」，譬如磁盤(pán)變慢了，網(wǎng)絡(luò)時(shí)不時(shí)丟包。這些故障都非常隱蔽，很難被發(fā)現(xiàn)。如果單純的依賴外部的工具，其實(shí)很難檢測(cè)出來(lái)。

上面是作者舉的一個(gè) ZooKeeper 的例子，client 已經(jīng)完全不能跟 Leader 進(jìn)行交互了，但是 Leader 卻仍然能夠給 Follower 發(fā)送心跳，同時(shí)也能響應(yīng)外面 Monitor 發(fā)過(guò)來(lái)的探活命令。

如果從外面的 Monitor 看來(lái)，這個(gè) ZooKeeper 集群還是正常的，但其實(shí)它已經(jīng)有故障了。而這個(gè)故障其實(shí) client 是知道的，所以故障檢測(cè)的原理很簡(jiǎn)單，從發(fā)起請(qǐng)求的這一端來(lái)觀察，如果發(fā)現(xiàn)有問(wèn)題，那就是有故障了。而這也是這篇論文的中心思想。

在論文里面，作者認(rèn)為，任何嚴(yán)重的 Gray Failure 都是能夠被觀察到的，如果發(fā)起請(qǐng)求的這邊遇到了錯(cuò)誤，自然下一件事情就是將這個(gè)錯(cuò)誤給匯報(bào)出去，這樣我們就知道某個(gè)地方出現(xiàn)了故障。于是作者開(kāi)發(fā)了 Panorama 這套系統(tǒng)，來(lái)對(duì)故障進(jìn)行檢測(cè)。

先來(lái)說(shuō)說(shuō) Panorama 一些專業(yè)術(shù)語(yǔ)。

Panorama 整體結(jié)構(gòu)如下：

Panorama 通過(guò)一些方式，譬如靜態(tài)分析代碼進(jìn)行代碼注入等，將 Observer 跟要觀察的 Subject 進(jìn)行綁定，Observer 會(huì)將 Subject 的一些信息記錄并且匯報(bào)給本地的一個(gè) Local Observation Store（LOS）。本地一個(gè)決策引擎就會(huì)分析 LOS 里面的數(shù)據(jù)來(lái)判斷這個(gè)組件的狀態(tài)。如果多個(gè) LOS 里面都有對(duì)某個(gè) Subject 的 observation，那么 LOS 會(huì)相互交換，用來(lái)讓中央的 verdict 更好的去判斷這個(gè) component 的狀態(tài)。

而用來(lái)判斷一個(gè) component 是不是有故障也比較容易，采用的是一種大多數(shù) bounded-look-back 算法。對(duì)于一個(gè) subject，它可能會(huì)有很多 observations，首先我們會(huì)對(duì)這些 observations 按照 observer 進(jìn)行分組，對(duì)每組多帶帶進(jìn)行分析。在每個(gè)組里面，observations 會(huì)按照時(shí)間從后往前檢查，并且按照 context 進(jìn)行聚合。如果一個(gè)被觀察的 observation 的 status 跟記錄前面相同 context 的 observation status 狀態(tài)不一樣，就繼續(xù) loop-back，直到遇到一個(gè)新的 status。對(duì)于一個(gè) context，如果最后的狀態(tài)是 unhealthy 或者 healthy 的狀態(tài)沒(méi)有達(dá)到多數(shù)，就會(huì)被認(rèn)為是 unhealthy 的。

通過(guò)這種方式，我們?cè)诿拷M里面得到了每個(gè) context 的狀態(tài)，然后又會(huì)在多個(gè)組里面進(jìn)行決策，也就是最常用的大多數(shù)原則，哪個(gè)狀態(tài)最多，那么這個(gè) context 對(duì)應(yīng)的狀態(tài)就是哪一個(gè)。這里我們需要額外處理下 PENDING 這個(gè)狀態(tài)，如果當(dāng)前狀態(tài)是 HEALTHY 而之前老的狀態(tài)是 PENDING，那么 PENDING 就會(huì)變成 HEALTHY，而如果一直是 PENDING 狀態(tài)并超過(guò)了某個(gè)閾值，就會(huì)退化成 UNHEALTHY。

這里再來(lái)說(shuō)說(shuō) Observability 的模式。對(duì)于分布式系統(tǒng)來(lái)說(shuō)，不同 component 之間的交互并不是同步的，我們會(huì)面臨如下幾種情況：

如果兩個(gè)組件 C1 和 C2 是同步交互，那么當(dāng) C1 給 C2 發(fā)送請(qǐng)求，我們就完全能在 C1 這一端知道這次請(qǐng)求成功還是失敗了，但是對(duì)于非同步的情況，我們可能面臨一個(gè)問(wèn)題，就是 C1 給 C2 發(fā)了請(qǐng)求，但其實(shí)這個(gè)請(qǐng)求是放到了異步消息隊(duì)列里面，但 C1 覺(jué)得是成功了，可是后面的異步隊(duì)列卻失敗了。所以 Panorama 需要有機(jī)制能正確處理上面多種情況。

為了能更好的從 component 上面得到有用的 observations，Panorama 會(huì)用一個(gè)離線工具對(duì)代碼進(jìn)行靜態(tài)分析，發(fā)現(xiàn)一些關(guān)鍵的地方，注入鉤子，這樣就能去匯報(bào) observations 了。

通常運(yùn)行時(shí)錯(cuò)誤是非常有用的能證明有故障的證據(jù)，但是，并不是所有的錯(cuò)誤都需要匯報(bào)，Panorama 僅僅會(huì)關(guān)系跨 component 邊界產(chǎn)生的錯(cuò)誤，因?yàn)檫@也是通過(guò)發(fā)起請(qǐng)求端能觀察到的。Panorama 對(duì)于這種跨域的函數(shù)調(diào)用稱為 observation boundaries。對(duì)于 Panorama 來(lái)說(shuō)，第一件事情就是定位 observation boundaries。通常有兩種 boundaries，進(jìn)程間交互和線程間交互。進(jìn)程間交互通常就是 socket I/O，RPC，而線程間則是在一個(gè)進(jìn)程里面跨越線程的調(diào)用。這些 Panorama 都需要分析出來(lái)。

當(dāng)定位了 observation boundaries 之后，下一件事情就是確定 observer 和 subject 的標(biāo)識(shí)。譬如對(duì)于進(jìn)程間交互的 boundaries，observer 的標(biāo)識(shí)就可能是這個(gè)進(jìn)程在系統(tǒng)里面的唯一標(biāo)識(shí)，而對(duì)于 subject，我們可以用 method 名字，或者是函數(shù)的一個(gè)參數(shù)，類里面的一個(gè)字段來(lái)標(biāo)識(shí)。

然后我們需要去確定 observation points，也就是觀測(cè)點(diǎn)。通常這些點(diǎn)就是代碼處理異常的地方，另外可能就是一些正常處理返回結(jié)果但會(huì)對(duì)外報(bào)錯(cuò)的地方。

上面就是一個(gè)簡(jiǎn)單分析代碼得到 observation points 的例子，但這個(gè)仍然是同步的，對(duì)于 indirection 的，還需要額外處理。

對(duì)于異步請(qǐng)求，我們知道，通過(guò)發(fā)出去之后，會(huì)異步的處理結(jié)果，所以這里分為了兩步，叫做 ob-origin 和 ob-sink。如下：

對(duì)于 ob-origin，代碼分析的時(shí)候會(huì)先給這個(gè) observation 設(shè)置成 PENDING 狀態(tài)，只有對(duì)應(yīng)的 ob-sink 調(diào)用并且返回了正確的結(jié)果，才會(huì)設(shè)置成 HEALTHY。因?yàn)?ob-origin 和 ob-sink 是異步的，所以代碼分析的時(shí)候會(huì)加上一個(gè)特殊的字段，包含 subject 的標(biāo)識(shí)和 context，這樣就能讓 ob-origin 和 ob-sink 對(duì)應(yīng)起來(lái)。

上面大概介紹了 Panorama 的架構(gòu)以及一些關(guān)鍵的知識(shí)點(diǎn)是如何實(shí)現(xiàn)的，簡(jiǎn)單來(lái)說(shuō)，就是在一些關(guān)鍵代碼路徑上面注入 hook，然后通過(guò) hook 對(duì)外將相關(guān)的狀態(tài)給匯報(bào)出去，在外面會(huì)有其他的分析程序?qū)δ玫降臄?shù)據(jù)進(jìn)行分析從而判定系統(tǒng)是否在正常工作。它其實(shí)跟加 metrics 很像，但 metrics 只能看出哪里出現(xiàn)了問(wèn)題，對(duì)于想更細(xì)致定位具體的某一個(gè)問(wèn)題以及它的上下文環(huán)境，倒不是特別的方便。這點(diǎn)來(lái)說(shuō) Panorama 的價(jià)值還是挺大的。

Panorama 的代碼已經(jīng)開(kāi)源，總的來(lái)說(shuō)還是挺簡(jiǎn)單的，但我沒(méi)找到核心的代碼分析，注入 hook 這些，有點(diǎn)遺憾。但理解了大概原理，其實(shí)先強(qiáng)制在代碼寫(xiě)死也未嘗不可。另一個(gè)比較可行的辦法就是進(jìn)行在代碼里面把日志添加詳細(xì)，這樣就不用代碼注入了，而是在外面寫(xiě)一個(gè)程序來(lái)分析日志，其實(shí) Panorama 代碼里面提供了日志分析的功能，為 ZooKeeper 來(lái)設(shè)計(jì)的，但作者自己也說(shuō)到，分析日志的效果比不上直接在代碼里面進(jìn)行注入。

那對(duì)我們來(lái)說(shuō)，有啥可以參考的呢？首先當(dāng)然是這一套故障檢查的理念，既然 Panorama 已經(jīng)做出來(lái)并且能發(fā)現(xiàn)故障量，自然我們也可以在 TiDB 里面實(shí)施。因?yàn)槲覀円呀?jīng)有在 Go 和 Rust 代碼里面使用 fail 來(lái)進(jìn)行錯(cuò)誤注入的經(jīng)驗(yàn)，所以早期手寫(xiě)監(jiān)控代碼也未嘗不可，但也可以直接完善日志，提供一個(gè)程序來(lái)分析日志就成。如果你對(duì)這塊感興趣，想把 Panorama 相關(guān)的東西應(yīng)用到 TiDB 中來(lái)，歡迎聯(lián)系我 tl@pingcap.com。