[[271767]]

引言

服務(wù)端問題排查(服務(wù)穩(wěn)定性/基礎(chǔ)設(shè)施異常/業(yè)務(wù)數(shù)據(jù)不符合預(yù)期等)對于開發(fā)而言是家常便飯，問題并不可怕，但是每天都要花大量時(shí)間去處理問題會(huì)很可怕；另一方面故障的快速解決至關(guān)重要。那么目前問題排查最大的障礙是什么呢?我們認(rèn)為有幾個(gè)原因?qū)е拢?/p>

• 大量的告警信息。
• 鏈路的復(fù)雜性。
• 排查過程繁復(fù)。
• 依賴經(jīng)驗(yàn)。
• 然而實(shí)際工作中的排查過程并非無跡可尋，其排查思路和手段是可以沉淀出一套經(jīng)驗(yàn)?zāi)Ｐ汀?/li>

沉淀路徑

下面是我的訂單列表的簡單抽象，其執(zhí)行過程是先拿到我買到的訂單列表。訂單列表中又用到了賣家，商品以及店鋪信息服務(wù)，每個(gè)服務(wù)又關(guān)聯(lián)著單次請求中提供服務(wù)對應(yīng)的主機(jī)信息。

以線上常見的服務(wù)超時(shí)為例，上圖中因?yàn)?27.123.12.12這臺(tái)機(jī)器出現(xiàn)異常導(dǎo)致商品服務(wù)超時(shí)，進(jìn)而導(dǎo)致我的訂單列表服務(wù)超時(shí)。根據(jù)日常中排查思路可以總結(jié)出以下分析范式：

上面這種分析范式看起來很簡單清晰，但是它首先面臨著以下問題：

• 如何準(zhǔn)確界定超時(shí)/異常。
• 上下游調(diào)用鏈路如何生成。
• 自己和下游，如何確定誰的問題(超時(shí)&異常)。
• 下游異常時(shí)，如何區(qū)分超時(shí)/線程池滿/未知異常。
• 以上問題本質(zhì)上是底層數(shù)據(jù)埋點(diǎn)問題，幸運(yùn)的是阿里集團(tuán)完備的數(shù)據(jù)建設(shè)使得這些問題基本都能找到很好的解決方案。有了底層數(shù)據(jù)支撐再配合上層抽象出來的這樣一套分析模型，設(shè)計(jì)并實(shí)現(xiàn)一套完全自動(dòng)化問題定位系統(tǒng)是完全有可能的。

系統(tǒng)架構(gòu)

我們認(rèn)為這樣一套問題自動(dòng)定位的系統(tǒng)一定要滿足4個(gè)目標(biāo)，這同時(shí)也是整個(gè)系統(tǒng)的難點(diǎn)所在。

• 準(zhǔn)(定位準(zhǔn)確率不亞于開發(fā)人員)
• 定位結(jié)果與真實(shí)原因哪怕有一點(diǎn)出入，影響的都是開發(fā)對系統(tǒng)本身的信心，所以準(zhǔn)是一大前提。
• 快(定位結(jié)果早于監(jiān)控發(fā)現(xiàn))
• 監(jiān)控作為發(fā)現(xiàn)問題最重要的手段，只有監(jiān)控發(fā)現(xiàn)問題時(shí)能立馬定位出結(jié)果，才真正具有實(shí)用價(jià)值。
• 簡單(從問題發(fā)現(xiàn)到定位結(jié)果之間的最短鏈路)
• 線上問題/故障定位爭分奪秒，操作路徑越簡單越有價(jià)值。
• 自動(dòng)化
• 全程不需開發(fā)人員參與。

圍繞著這4大目標(biāo)，我們實(shí)現(xiàn)了上面這樣一套完整的定位系統(tǒng)，實(shí)現(xiàn)了從告警->定位->快速處理這樣一套完整閉環(huán)。自下而上劃分為4個(gè)模塊，下面講一下每個(gè)模塊解決的問題以及其難點(diǎn)。

數(shù)據(jù)采集

數(shù)據(jù)采集模塊主要負(fù)責(zé)埋點(diǎn)數(shù)據(jù)的采集與上報(bào)，需要解決兩個(gè)問題：

• 海量數(shù)據(jù)。線上的埋點(diǎn)數(shù)據(jù)每時(shí)每刻都在產(chǎn)生，其數(shù)據(jù)量可達(dá)到80G/分鐘。
• 采集時(shí)延。快作為整個(gè)系統(tǒng)追求的一大目標(biāo)，數(shù)據(jù)采集需要滿足低時(shí)延。
• 可擴(kuò)展指標(biāo)。隨著模型的不斷演進(jìn)完善，需要實(shí)現(xiàn)靈活的增加采集指標(biāo)(cpu/gc/gc耗時(shí)/線程數(shù)等)。
• 采用SLS+自定義插件庫來實(shí)現(xiàn)線上流量埋點(diǎn)數(shù)據(jù)的采集與上報(bào)。SLS是阿里云研發(fā)針對日志類數(shù)據(jù)的一站式服務(wù)，其生命周期管理(TTL)以及極低的存儲(chǔ)成本可以很好的解決海量數(shù)據(jù)帶來的成本問題。

實(shí)時(shí)計(jì)算

實(shí)時(shí)計(jì)算以數(shù)據(jù)采集的輸出作為輸入，負(fù)責(zé)對數(shù)據(jù)進(jìn)行一輪預(yù)處理，包括鏈路數(shù)據(jù)的關(guān)聯(lián)(請求都有唯一標(biāo)識(shí)，按照標(biāo)識(shí)group by)，數(shù)據(jù)清洗(只選取需要的數(shù)據(jù))以及事件通知。

• 計(jì)算延時(shí)。從拿到數(shù)據(jù)到最后過濾輸出，要盡可能壓縮計(jì)算延時(shí)來提升整個(gè)系統(tǒng)的時(shí)效性。
• 多數(shù)據(jù)源協(xié)同。數(shù)據(jù)來源于底層不同的數(shù)據(jù)源，他們之前對應(yīng)著不同的到達(dá)時(shí)間，需要解決數(shù)據(jù)等待問題。
• 數(shù)據(jù)清洗。需要有一定的策略來進(jìn)行一輪數(shù)據(jù)清洗，過濾出真正有效的數(shù)據(jù)，來減少計(jì)算量以及后續(xù)的存儲(chǔ)成本。
• 存儲(chǔ)成本。雖然經(jīng)過了一輪數(shù)據(jù)清洗，但是隨著累積數(shù)據(jù)量還是會(huì)線性增長。

實(shí)時(shí)分析

當(dāng)收到事件通知后根據(jù)實(shí)時(shí)計(jì)算產(chǎn)出的有效數(shù)據(jù)進(jìn)行自動(dòng)化的分析，輸出問題的發(fā)生路徑圖。需要解決：

• 實(shí)時(shí)拓?fù)?vs. 離線拓?fù)洹?shí)時(shí)拓?fù)鋵β顸c(diǎn)數(shù)據(jù)有要求，需要能夠?qū)崟r(shí)還原調(diào)用鏈路，但依賴采集數(shù)據(jù)的完整度。離線拓?fù)潆x線生成，不依賴采集數(shù)據(jù)的完整度，但不能準(zhǔn)確反應(yīng)當(dāng)前拓?fù)洹Ｗ詈筮x擇了實(shí)時(shí)還原拓?fù)浞绞奖ＷC準(zhǔn)確率。
• 數(shù)據(jù)丟失。雖然實(shí)時(shí)計(jì)算中有解決數(shù)據(jù)協(xié)同等待的問題，但無法徹底解決數(shù)據(jù)的丟失問題(數(shù)據(jù)延時(shí)過大/埋點(diǎn)數(shù)據(jù)丟失)，延時(shí)以及丟失數(shù)據(jù)需要采取不同的處理策略。
• 分析準(zhǔn)確率。影響準(zhǔn)確率的因素很多，主要包括數(shù)據(jù)完整度以及分析模型的完備度。

聚合&展示

按照時(shí)間窗口對問題發(fā)生路徑進(jìn)行實(shí)時(shí)聚合，還原問題發(fā)生時(shí)的現(xiàn)場。將監(jiān)控，告警和診斷鏈路進(jìn)行了互通，最大化的縮短從問題發(fā)現(xiàn)到結(jié)果展現(xiàn)的操作路徑。

• 實(shí)時(shí)聚合 vs. 查詢時(shí)聚合。查詢時(shí)聚合性能差但是很靈活(可以根據(jù)不同的條件聚合數(shù)據(jù)),反之實(shí)時(shí)聚合犧牲了靈活性來保證查詢性能。這里我們選擇保證查詢性能。
• 并發(fā)問題。采用實(shí)時(shí)聚合首先要解決的是并發(fā)寫(線上集群對同一個(gè)接口的聚合結(jié)果進(jìn)行修改)。最后采取將圖拆解成原子key，利用redies的線程安全特性保證線上集群的寫并發(fā)問題。
• 存儲(chǔ)成本 vs. 聚合性能。為了解決并發(fā)問題，我們利用redis的線程安全特性來解決，但帶來的一個(gè)問題就是成本問題。分析下來會(huì)發(fā)現(xiàn)聚合操作一般只會(huì)跨越2～5個(gè)窗口，超過之后聚合結(jié)果就會(huì)穩(wěn)定下來。所以可以考慮將聚合結(jié)果持久化。

效果

系統(tǒng)上線以來經(jīng)受住了實(shí)踐的檢驗(yàn)，故障以及日常問題的定位效率得到顯著提升，并獲得了穩(wěn)定性的結(jié)果。將日常問題/故障定位時(shí)間從10分鐘縮短到5s以內(nèi)，以下是隨機(jī)選取的兩個(gè)真實(shí)case。

案例1：閑魚發(fā)布受影響

監(jiān)控系統(tǒng)發(fā)現(xiàn)商品發(fā)布接口成功率下跌發(fā)出來告警信息，點(diǎn)擊告警診斷直接跳轉(zhuǎn)到問題現(xiàn)場，發(fā)現(xiàn)是因?yàn)榘踩硞€(gè)服務(wù)錯(cuò)誤率飆升導(dǎo)致，整個(gè)過程不到5s。

案例2: 首頁因?yàn)閱螜C(jī)問題受到影響

閑魚首頁因?yàn)閱螜C(jī)gc問題抖動(dòng)觸發(fā)大量告警信息，秒級給出問題發(fā)生路徑。根據(jù)診斷路徑顯示搜索單機(jī)出現(xiàn)大量異常。

總結(jié)

目前整個(gè)系統(tǒng)主要聚焦服務(wù)穩(wěn)定性相關(guān)的問題定位，仍然有許多場景有待覆蓋，信息有待補(bǔ)全，措施有待執(zhí)行，定位只是其中的一環(huán)。最終目的一定是建設(shè)問題定位，隔離，降級，與快速恢復(fù)這樣一個(gè)完整閉環(huán)。要想實(shí)現(xiàn)這樣一個(gè)完整閉環(huán)，離不開底層各個(gè)子系統(tǒng)的數(shù)據(jù)建設(shè)，核心在于兩點(diǎn)一面的建設(shè)：

• 底層數(shù)據(jù)建設(shè)。完備的數(shù)據(jù)支持一定是整個(gè)系統(tǒng)能夠發(fā)揮價(jià)值的前提，雖然現(xiàn)階段很多系統(tǒng)在產(chǎn)出這方面的數(shù)據(jù)，但仍然遠(yuǎn)遠(yuǎn)不夠。
• 完備的事件抽象。數(shù)據(jù)不僅僅局限于請求產(chǎn)生的埋點(diǎn)數(shù)據(jù)，其范圍應(yīng)該更為廣泛(應(yīng)用發(fā)布，線上變更，流量波動(dòng)等)，任意可能對線上造成影響的操作都應(yīng)該可以抽象成一個(gè)事件。
• 知識(shí)圖譜的建立。僅僅有完備的事件并沒有多大的價(jià)值，真正的價(jià)值在于把這些事件關(guān)聯(lián)起來，在問題/故障發(fā)生時(shí)第一時(shí)間還原現(xiàn)場，快速定位問題。