介紹

系統(tǒng)和基礎(chǔ)設(shè)施監(jiān)控是各種規(guī)模的運(yùn)營(yíng)團(tuán)隊(duì)的核心職責(zé)想虎。行業(yè)里已經(jīng)開(kāi)發(fā)了許多策略和工具房匆，以幫助監(jiān)控服務(wù)器耸成，收集重要數(shù)據(jù)，并響應(yīng)不同環(huán)境中的事件和不斷變化的條件浴鸿。但是隨著軟件方法和基礎(chǔ)設(shè)施設(shè)計(jì)的發(fā)展井氢，監(jiān)控必須適應(yīng)新的挑戰(zhàn)并在相對(duì)不熟悉的領(lǐng)域提供洞察力。

到目前為止赚楚，在本系列中毙沾，我們已經(jīng)討論了什么是指標(biāo)，監(jiān)控和警報(bào)以及良好的監(jiān)控系統(tǒng)所具備的特征宠页。我們討論了從基礎(chǔ)架構(gòu)和應(yīng)用程序收集指標(biāo)以及在整個(gè)基礎(chǔ)架構(gòu)中監(jiān)控重要的信號(hào)左胞。在我們的上一篇指南中寇仓，我們介紹了如何通過(guò)了解各個(gè)組件和良好警報(bào)設(shè)計(jì)的標(biāo)準(zhǔn)，將指標(biāo)和警報(bào)付諸實(shí)踐烤宙。

在本文中遍烦，我們將了解高度分布式架構(gòu)和微服務(wù)的監(jiān)控和指標(biāo)收集如何變化。云計(jì)算躺枕、大數(shù)據(jù)集群和容器編排層的日益普及迫使運(yùn)營(yíng)專業(yè)人員重新思考如何大規(guī)模設(shè)計(jì)監(jiān)控服猪，并通過(guò)更好的儀器解決獨(dú)特的問(wèn)題。我們將討論新的部署模型有什么不同以及可以使用哪些策略來(lái)滿足這些新需求拐云。

高度分布式架構(gòu)會(huì)帶來(lái)哪些挑戰(zhàn)罢猪？

為了模擬和鏡像它所監(jiān)視的系統(tǒng)，監(jiān)控基礎(chǔ)設(shè)施一直在某種程度上分布叉瘩。然而膳帕，許多現(xiàn)代開(kāi)發(fā)實(shí)踐（包括圍繞微服務(wù)，容器和可互換的短暫計(jì)算實(shí)例的設(shè)計(jì)）已經(jīng)大大改變了監(jiān)控環(huán)境薇缅。在許多情況下危彩，這些變化的核心特征是使監(jiān)測(cè)變得更困難的因素。讓我們花一點(diǎn)時(shí)間來(lái)看一下這些與傳統(tǒng)環(huán)境不同的方式以及它們?nèi)绾斡绊懕O(jiān)控泳桦。

工作與基礎(chǔ)資源分離

許多系統(tǒng)行為方式的一些最根本的變化是由于新的抽象層的爆炸式增長(zhǎng)汤徽，軟件可以圍繞它設(shè)計(jì)。容器技術(shù)改變了已部署軟件與底層操作系統(tǒng)之間的關(guān)系灸撰。部署在容器中的應(yīng)用程序與外部世界谒府、其他程序和主機(jī)操作系統(tǒng)的關(guān)系不同于通過(guò)傳統(tǒng)方式部署的應(yīng)用程序。內(nèi)核和網(wǎng)絡(luò)抽象可能導(dǎo)致對(duì)操作環(huán)境的不同理解浮毯，具體取決于您檢查的層狱掂。

通過(guò)創(chuàng)建一致的部署策略，這種抽象級(jí)別在很多方面都非常有用亲轨，可以更輕松地在主機(jī)之間遷移工作，并允許開(kāi)發(fā)人員對(duì)其應(yīng)用程序的運(yùn)行時(shí)環(huán)境進(jìn)行嚴(yán)密控制鸟顺。然而惦蚊，這些新功能的代價(jià)是增加了復(fù)雜性，并且與為每個(gè)進(jìn)程提供動(dòng)力的資源建立了更為松散的關(guān)系讯嫂。

增加基于網(wǎng)絡(luò)的通信

新架構(gòu)中的一個(gè)共同點(diǎn)是越來(lái)越依賴內(nèi)部網(wǎng)絡(luò)通信來(lái)協(xié)調(diào)和完成任務(wù)蹦锋。以前，單個(gè)應(yīng)用程序的域可能會(huì)分散在需要協(xié)調(diào)和共享信息的許多組件中欧芽。這在通信基礎(chǔ)設(shè)施和監(jiān)控方面會(huì)產(chǎn)生一些影響莉掂。

首先，因?yàn)檫@些模型建立在小型離散服務(wù)之間的通信之上千扔，所以網(wǎng)絡(luò)健康變得比以往更加重要憎妙。在傳統(tǒng)的库正，更加單一的體系結(jié)構(gòu)中，協(xié)調(diào)任務(wù)厘唾、共享信息和組織結(jié)果主要是在具有常規(guī)編程邏輯的應(yīng)用程序中或通過(guò)相對(duì)少量的外部通信來(lái)完成的褥符。相反，高度分布式應(yīng)用程序的邏輯流程使用網(wǎng)絡(luò)進(jìn)行同步抚垃，檢查對(duì)等體的健康狀況并傳遞信息喷楣。網(wǎng)絡(luò)健康和性能直接影響比以前更多的功能，這意味著需要更密集的監(jiān)控來(lái)保證正確的操作鹤树。

雖然網(wǎng)絡(luò)變得比以往任何時(shí)候都更加重要铣焊，但由于參與者數(shù)量和個(gè)人通信線路的增加，有效監(jiān)控網(wǎng)絡(luò)的能力越來(lái)越具有挑戰(zhàn)性罕伯。不是跟蹤幾個(gè)應(yīng)用程序之間的交互曲伊，而是需要在數(shù)十個(gè)，數(shù)百個(gè)或數(shù)千個(gè)不同點(diǎn)之間進(jìn)行正確的通信捣炬，以確保相同的功能熊昌。除了考慮復(fù)雜性之外，增加的流量還會(huì)給可用的網(wǎng)絡(luò)資源帶來(lái)額外的壓力湿酸，進(jìn)一步加劇了可靠監(jiān)控的必要性婿屹。

功能和責(zé)任分配到更大程度

上面，我們提到了現(xiàn)代架構(gòu)在許多較小的分立組件之間劃分工作和功能的趨勢(shì)推溃。這些設(shè)計(jì)可以對(duì)監(jiān)控環(huán)境產(chǎn)生直接影響昂利，因?yàn)樗鼈兪骨逦群涂衫斫庑蕴貏e有價(jià)值，但卻越來(lái)越難以捉摸铁坎。

需要更強(qiáng)大的工具和儀器以確保良好的工作秩序蜂奸。但是，由于完成任何給定任務(wù)的責(zé)任是分散的硬萍，并且在不同的工作單元（可能在許多不同的物理主機(jī)上）之間分配扩所，因此理解責(zé)任在于性能問(wèn)題或錯(cuò)誤的位置可能很困難。觸及許多組件的請(qǐng)求和工作單元（其中許多組件是從可能的候選者池中選擇的）朴乖，使用傳統(tǒng)機(jī)制使請(qǐng)求路徑可視化或根本原因分析變得不切實(shí)際祖屏。

短期和短暫的單位

適應(yīng)傳統(tǒng)監(jiān)測(cè)的進(jìn)一步斗爭(zhēng)是合理地追蹤短期或短暫的單位。無(wú)論關(guān)注的單元是云計(jì)算實(shí)例买羞，容器實(shí)例還是其他抽象袁勺，這些組件通常都違反了傳統(tǒng)監(jiān)控軟件所做的一些假設(shè)。

例如畜普，為了區(qū)分有問(wèn)題的故障節(jié)點(diǎn)和故意銷(xiāo)毀的實(shí)例以縮小規(guī)模期丰，監(jiān)控系統(tǒng)必須對(duì)您的配置和管理層有一個(gè)比以前更必要的了解。對(duì)于許多現(xiàn)代系統(tǒng)而言，這些事件發(fā)生的頻率更高钝荡，因此每次手動(dòng)調(diào)整監(jiān)控域都是不切實(shí)際的街立。隨著這些設(shè)計(jì)，部署環(huán)境變化更快化撕，因此監(jiān)控層必須采用新策略來(lái)保持價(jià)值几晤。

許多系統(tǒng)必須面對(duì)的一個(gè)問(wèn)題是如何處理來(lái)自被破壞實(shí)例的數(shù)據(jù)。雖然可以快速配置和取消配置工作單元以適應(yīng)不斷變化的需求植阴，但必須決定如何處理與舊實(shí)例相關(guān)的數(shù)據(jù)蟹瘾。數(shù)據(jù)不一定會(huì)立即失去其價(jià)值，因?yàn)榛A(chǔ)工作者不再可用掠手。當(dāng)每天有數(shù)百或數(shù)千個(gè)節(jié)點(diǎn)來(lái)來(lái)往往時(shí)憾朴，可能很難知道如何從短期實(shí)例的碎片化數(shù)據(jù)中最好地構(gòu)建關(guān)于系統(tǒng)整體運(yùn)行狀況的敘述。

擴(kuò)展監(jiān)控需要哪些更改喷鸽？

現(xiàn)在我們已經(jīng)確定了分布式架構(gòu)和微服務(wù)的一些獨(dú)特挑戰(zhàn)众雷，我們可以討論監(jiān)控系統(tǒng)在這些現(xiàn)實(shí)中的工作方式。一些解決方案涉及重新評(píng)估和隔離對(duì)不同類型的指標(biāo)最有價(jià)值的內(nèi)容做祝，而其他解決方案涉及新工具或理解其所處環(huán)境的新方法砾省。

粒度和抽樣

服務(wù)數(shù)量增加導(dǎo)致的總流量增加是最直接的問(wèn)題之一。除了由新架構(gòu)引起的傳輸數(shù)量膨脹之外混槐，監(jiān)控活動(dòng)本身可能開(kāi)始陷入網(wǎng)絡(luò)并竊取主機(jī)資源编兄。為了最好地處理增加的數(shù)量，您可以擴(kuò)展監(jiān)控基礎(chǔ)架構(gòu)或降低使用數(shù)據(jù)的分辨率声登。這兩種方法都值得關(guān)注狠鸳，但我們將重點(diǎn)關(guān)注第二種方法，因?yàn)樗砹艘环N更具可擴(kuò)展性和廣泛有用的解決方案悯嗓。

更改數(shù)據(jù)采樣率可以最大限度地減少系統(tǒng)從主機(jī)收集的數(shù)據(jù)量件舵。抽樣是指標(biāo)集合的正常部分，表示您為指標(biāo)請(qǐng)求新值的頻率脯厨。增加采樣間隔將減少您必須處理的數(shù)據(jù)量铅祸，但也會(huì)降低數(shù)據(jù)的分辨率 - 細(xì)節(jié)級(jí)別。雖然您必須小心并了解最低有用分辨率合武，但調(diào)整數(shù)據(jù)收集率會(huì)對(duì)系統(tǒng)可以充分服務(wù)的監(jiān)控客戶端數(shù)量產(chǎn)生深遠(yuǎn)影響个少。

為了減少由較低分辨率導(dǎo)致的信息丟失，一種選擇是繼續(xù)以相同的頻率在主機(jī)上收集數(shù)據(jù)眯杏，但將其編譯成更易消化的數(shù)字以便通過(guò)網(wǎng)絡(luò)傳輸。各個(gè)計(jì)算機(jī)可以聚合和平均度量值壳澳，并將摘要發(fā)送到監(jiān)控系統(tǒng)岂贩。這有助于在保持準(zhǔn)確性的同時(shí)減少網(wǎng)絡(luò)流量，因?yàn)槿匀豢紤]了大量數(shù)據(jù)點(diǎn)。請(qǐng)注意萎津，這有助于減少數(shù)據(jù)收集對(duì)網(wǎng)絡(luò)的影響卸伞，但本身并不能幫助解決在主機(jī)中收集這些數(shù)字所帶來(lái)的壓力。

根據(jù)多個(gè)單元聚合的數(shù)據(jù)做出決策

如上所述锉屈，傳統(tǒng)系統(tǒng)和現(xiàn)代架構(gòu)之間的主要區(qū)別之一是分解哪些組件參與處理請(qǐng)求荤傲。在分布式系統(tǒng)和微服務(wù)中，通過(guò)某種類型的調(diào)度或仲裁層颈渊，更有可能將工作單元提供給工作池遂黍。這對(duì)您可能?chē)@監(jiān)控構(gòu)建的許多自動(dòng)化流程都有影響。

在使用可互換工作池的環(huán)境中俊嗽，運(yùn)行狀況檢查和警報(bào)策略可能會(huì)增長(zhǎng)雾家，與其監(jiān)視的基礎(chǔ)結(jié)構(gòu)之間存在復(fù)雜的關(guān)系。對(duì)個(gè)別單位進(jìn)行健康檢查對(duì)于自動(dòng)退役和回收有缺陷的單位非常有用绍豁。但是芯咧，如果您具有大規(guī)模自動(dòng)化，則單個(gè)Web服務(wù)器在大型池中出現(xiàn)故障并不重要竹揍。系統(tǒng)將自我糾正敬飒，以確保只有健康單位在活動(dòng)池中接收請(qǐng)求。

雖然主機(jī)運(yùn)行狀況檢查可以捕獲有缺陷的單元芬位，但檢查池本身的運(yùn)行狀況更適合于警報(bào)无拗。池滿足當(dāng)前工作負(fù)載的能力對(duì)用戶體驗(yàn)的影響大于任何單個(gè)工作者的能力【е裕基于健康成員數(shù)量蓝纲，池聚合延遲或池錯(cuò)誤率的警報(bào)可以通知操作員更難以自動(dòng)緩解并且更可能影響用戶的問(wèn)題。

與供應(yīng)層集成

通常晌纫，分布式系統(tǒng)中的監(jiān)視層需要更全面地了解部署環(huán)境和配置機(jī)制税迷。由于這些體系結(jié)構(gòu)中涉及的單個(gè)單元的數(shù)量，自動(dòng)化生命周期管理變得非常有價(jià)值锹漱。無(wú)論這些單元是原始容器箭养，業(yè)務(wù)流程框架內(nèi)的容器還是云環(huán)境中的計(jì)算節(jié)點(diǎn)，都存在一個(gè)管理層哥牍，它公開(kāi)健康信息并接受命令來(lái)擴(kuò)展和響應(yīng)事件毕泌。

游戲中的棋子數(shù)增加了統(tǒng)計(jì)失敗的可能性。在所有其他因素相同的情況下嗅辣，這需要更多的人為干預(yù)來(lái)回應(yīng)和緩解這些問(wèn)題撼泛。由于監(jiān)控系統(tǒng)負(fù)責(zé)識(shí)別故障和服務(wù)降級(jí)，如果它可以掛鉤到平臺(tái)的控制接口澡谭，它可以緩解大量這些問(wèn)題愿题。監(jiān)控軟件觸發(fā)的即時(shí)自動(dòng)響應(yīng)有助于維護(hù)系統(tǒng)的運(yùn)行狀況。

監(jiān)控系統(tǒng)和部署平臺(tái)之間的這種緊密關(guān)系在其他架構(gòu)中不一定是必需的或共同的。但是潘酗，自動(dòng)化分布式系統(tǒng)旨在實(shí)現(xiàn)自我調(diào)節(jié)杆兵，能夠根據(jù)預(yù)先配置的規(guī)則和觀察到的狀態(tài)進(jìn)行擴(kuò)展和調(diào)整。在這種情況下仔夺，監(jiān)控系統(tǒng)在控制環(huán)境和決定何時(shí)采取行動(dòng)方面發(fā)揮著核心作用琐脏。

監(jiān)控系統(tǒng)必須了解供應(yīng)層的另一個(gè)原因是處理短暫實(shí)例的副作用。在工作實(shí)例中頻繁更換的環(huán)境中缸兔，監(jiān)控系統(tǒng)依賴來(lái)自旁道的信息來(lái)了解何時(shí)有意或無(wú)意地采取行動(dòng)日裙。例如，當(dāng)服務(wù)器故意被操作員銷(xiāo)毀時(shí)灶体，與服務(wù)器突然變得沒(méi)有響應(yīng)而沒(méi)有相關(guān)事件時(shí)阅签，可以從供應(yīng)者讀取API事件的系統(tǒng)做出不同的反應(yīng)。能夠區(qū)分這些事件可以幫助您的監(jiān)控保持有用蝎抽、準(zhǔn)確和可信政钟，即使底層基礎(chǔ)架構(gòu)可能經(jīng)常更改。

分布式跟蹤

高度分散的工作負(fù)載中最具挑戰(zhàn)性的方面之一是了解不同組件之間的相互作用樟结，并在嘗試根本原因分析時(shí)分離責(zé)任养交。由于單個(gè)請(qǐng)求可能會(huì)觸及許多小程序來(lái)生成響應(yīng)，因此很難解釋瓶頸或性能變化的來(lái)源瓢宦。為了提供有關(guān)每個(gè)組件如何導(dǎo)致延遲和處理開(kāi)銷(xiāo)的更好信息碎连，出現(xiàn)了一種稱為分布式跟蹤的技術(shù)。

分布式跟蹤是一種檢測(cè)系統(tǒng)的方法驮履，通過(guò)向每個(gè)組件添加代碼來(lái)闡明處理服務(wù)時(shí)的請(qǐng)求處理鱼辙。每個(gè)請(qǐng)求都在您的基礎(chǔ)架構(gòu)邊緣給出一個(gè)唯一標(biāo)識(shí)符，該標(biāo)識(shí)符在任務(wù)遍歷您的基礎(chǔ)結(jié)構(gòu)時(shí)傳遞。然后，每個(gè)服務(wù)都使用此ID來(lái)報(bào)告錯(cuò)誤拉庶，或記錄接收請(qǐng)求時(shí)間以及何時(shí)將其移交給下一階段的時(shí)間戳。通過(guò)使用這個(gè)ID聚合來(lái)自組件的報(bào)告杜跷，可以通過(guò)您的基礎(chǔ)架構(gòu)跟蹤具有準(zhǔn)確時(shí)序數(shù)據(jù)的詳細(xì)路徑。

此方法可用于了解在流程的每個(gè)部分上花費(fèi)了多少時(shí)間矫夷，并清楚地識(shí)別出任何嚴(yán)重的延遲增加葛闷。這種額外的工具是一種使度量收集，適應(yīng)大量處理組件的方法双藕。當(dāng)在x軸上以時(shí)間可視地映射時(shí)淑趾，生成的內(nèi)容顯示不同階段之間的關(guān)系，每個(gè)進(jìn)程運(yùn)行的時(shí)間以及必須并行運(yùn)行的事件之間的依賴關(guān)系忧陪。這對(duì)于了解如何改進(jìn)系統(tǒng)以及如何花費(fèi)時(shí)間非常有用扣泊。

提高分布式系統(tǒng)的運(yùn)營(yíng)響應(yīng)能力

我們已經(jīng)討論了分布式體系結(jié)構(gòu)如何使錯(cuò)誤原因分析和操作清晰度變得難以實(shí)現(xiàn)驳概。在許多情況下，改變?nèi)祟悓?duì)問(wèn)題的回應(yīng)和調(diào)查方式是這些含糊不清的答案的一部分旷赖。設(shè)置工具以便以有條理的方式分析情況的方式公開(kāi)信息，可以幫助分類可用的多個(gè)數(shù)據(jù)層更卒。在本節(jié)中等孵，我們將討論在解決大型分布式環(huán)境中的問(wèn)題時(shí)為成功做好準(zhǔn)備的方法。

為每一層設(shè)置四個(gè)黃金信號(hào)的警報(bào)

確保您可以響應(yīng)系統(tǒng)中的問(wèn)題的第一步是了解它們何時(shí)發(fā)生蹂空。在我們的基礎(chǔ)架構(gòu)和應(yīng)用程序收集指標(biāo)的指南中俯萌，我們介紹了Google SRE團(tuán)隊(duì)確定的四個(gè)黃金信號(hào)監(jiān)控指標(biāo)，這些指標(biāo)是最重要的跟蹤指標(biāo)上枕。這四個(gè)信號(hào)是：

• 延遲
• 流量
• 錯(cuò)誤率
• 飽和度

在檢測(cè)系統(tǒng)時(shí)咐熙，這些仍然是最佳起點(diǎn)，但高分布式系統(tǒng)通常會(huì)增加必須監(jiān)視的層數(shù)辨萍。底層基礎(chǔ)架構(gòu)棋恼，業(yè)務(wù)流程層和工作層都需要強(qiáng)大的監(jiān)控功能，并設(shè)置周到的警報(bào)以識(shí)別重要的變化锈玉。警報(bào)條件可能在復(fù)雜性上增加爪飘，以考慮平臺(tái)內(nèi)固有的短暫元素。

獲得完整的圖像

一旦您的系統(tǒng)發(fā)現(xiàn)異常情況并通知您的員工拉背，您的團(tuán)隊(duì)就需要開(kāi)始收集數(shù)據(jù)师崎。在繼續(xù)執(zhí)行此步驟之前，他們應(yīng)該了解受影響的組件椅棺，事件發(fā)生的時(shí)間以及觸發(fā)的特定警報(bào)條件犁罩。

開(kāi)始理解事件范圍的最有用方法是從高層開(kāi)始。通過(guò)檢查收集和概括整個(gè)系統(tǒng)信息的儀表板和可視化來(lái)開(kāi)始調(diào)查两疚。這可以幫助您快速識(shí)別相關(guān)因素并了解面臨的面向用戶的影響床估。在此過(guò)程中，您應(yīng)該能夠覆蓋來(lái)自不同組件和主機(jī)的信息鬼雀。

此階段的目標(biāo)是開(kāi)始創(chuàng)建項(xiàng)目的精神或物理清單顷窒，以更詳細(xì)地檢查并開(kāi)始優(yōu)先調(diào)查。如果您可以識(shí)別遍歷不同層的一系列相關(guān)問(wèn)題源哩，則最低層應(yīng)該優(yōu)先：基礎(chǔ)層的修復(fù)通承可以解決更高級(jí)別的癥狀。受影響的系統(tǒng)列表可以作為一個(gè)非正式的檢查清單励烦，用于在部署緩解措施時(shí)驗(yàn)證修復(fù)程序谓着。

深入研究具體問(wèn)題

一旦您認(rèn)為自己擁有合理的事件高級(jí)視圖，請(qǐng)按優(yōu)先級(jí)順序深入了解列表中的組件和系統(tǒng)坛掠。有關(guān)各個(gè)單元的詳細(xì)指標(biāo)將幫助您將故障路由跟蹤到最低負(fù)責(zé)的資源赊锚。在查看更細(xì)粒度的儀表板和日志條目時(shí)治筒，請(qǐng)參考受影響組件的列表，以嘗試進(jìn)一步了解如何通過(guò)系統(tǒng)傳播作用舷蒲。使用微服務(wù)耸袜，相互依賴的組件的數(shù)量意味著問(wèn)題會(huì)更頻繁地蔓延到其他服務(wù)。

此階段的重點(diǎn)是隔離負(fù)責(zé)初始事件的服務(wù)牲平，組件或系統(tǒng)堤框，并確定正在發(fā)生的具體問(wèn)題。這可能是新部署的代碼纵柿，錯(cuò)誤的物理基礎(chǔ)架構(gòu)蜈抓，業(yè)務(wù)流程層中的錯(cuò)誤，或者系統(tǒng)無(wú)法正常處理的工作負(fù)載變化昂儒。診斷正在發(fā)生的事情以及為什么允許您發(fā)現(xiàn)如何緩解問(wèn)題并重新獲得運(yùn)營(yíng)狀況沟使。了解解決此問(wèn)題可能解決其他系統(tǒng)上報(bào)告的問(wèn)題的程度可以幫助您繼續(xù)確定緩解任務(wù)的優(yōu)先級(jí)。

減輕解決問(wèn)題的能力

一旦確定了具體細(xì)節(jié)渊跋，您就可以解決或減輕問(wèn)題腊嗡。在許多情況下，通過(guò)提供更多資源刹枉，回滾或?qū)⒘髁恐匦侣酚傻絺溆脤?shí)現(xiàn)叽唱，可能會(huì)是一種明顯、快速的方法來(lái)恢復(fù)服務(wù)微宝。在這些情況下棺亭，解決方案將分為三個(gè)階段：

• 執(zhí)行操作以解決問(wèn)題并恢復(fù)即時(shí)服務(wù)
• 解決潛在問(wèn)題以重新獲得全部功能和運(yùn)營(yíng)狀況
• 全面評(píng)估失敗的原因并實(shí)施長(zhǎng)期修復(fù)以防止再次發(fā)生

在許多分布式系統(tǒng)中，冗余和高可用性組件將確斌恚快速恢復(fù)服務(wù)镶摘，但在后臺(tái)可能需要更多工作來(lái)恢復(fù)冗余或使系統(tǒng)退出降級(jí)狀態(tài)。您應(yīng)該使用先前編譯的受影響組件列表作為衡量標(biāo)準(zhǔn)來(lái)確定您的初始緩解是否可以解決級(jí)聯(lián)服務(wù)問(wèn)題岳守。隨著監(jiān)控系統(tǒng)的復(fù)雜性的發(fā)展凄敢，它還可以通過(guò)向配置層發(fā)送命令來(lái)啟動(dòng)故障單元的新實(shí)例或循環(huán)出行為不當(dāng)?shù)膯卧瑥亩惯@些更全面的恢復(fù)過(guò)程自動(dòng)化湿痢。

鑒于前兩個(gè)階段可能實(shí)現(xiàn)自動(dòng)化涝缝，運(yùn)營(yíng)團(tuán)隊(duì)最重要的工作通常是了解事件的根本原因。從此過(guò)程中收集的知識(shí)可用于開(kāi)發(fā)新的觸發(fā)器和策略譬重，以幫助預(yù)測(cè)未來(lái)會(huì)發(fā)生的情況拒逮，并進(jìn)一步自動(dòng)化系統(tǒng)的反應(yīng)。監(jiān)控軟件通常會(huì)獲得響應(yīng)每個(gè)事件的新功能臀规，以防止新發(fā)現(xiàn)的故障情況滩援。對(duì)于分布式系統(tǒng)，分布式跟蹤塔嬉，日志條目玩徊，時(shí)間序列可視化以及最近部署等事件可幫助您重建事件序列并確定可以改進(jìn)軟件和人員流程的位置租悄。

由于大型分布式系統(tǒng)固有的特殊復(fù)雜性，將任何重要事件的解決過(guò)程視為學(xué)習(xí)和微調(diào)系統(tǒng)的機(jī)會(huì)非常重要恩袱。所涉及的單獨(dú)組件和通信路徑的數(shù)量迫使人們嚴(yán)重依賴自動(dòng)化和工具來(lái)幫助管理復(fù)雜性泣棋。將新方法編入這些組件的響應(yīng)機(jī)制和規(guī)則集（以及您的團(tuán)隊(duì)遵守的操作策略）是監(jiān)控系統(tǒng)保持團(tuán)隊(duì)管理足跡的最佳方式。

結(jié)論

在本文中畔塔，我們討論了分布式體系結(jié)構(gòu)和微服務(wù)設(shè)計(jì)為監(jiān)視軟件引入的一些特定挑戰(zhàn)外傅。構(gòu)建系統(tǒng)的現(xiàn)代方法打破了傳統(tǒng)方法的一些假設(shè)，需要不同的方法來(lái)處理新的配置環(huán)境俩檬。我們探討了當(dāng)您從單體系統(tǒng)轉(zhuǎn)向越來(lái)越依賴于云或基于容器的環(huán)境以及高容量網(wǎng)絡(luò)協(xié)調(diào)時(shí)需要考慮的調(diào)整。之后碾盟，我們討論了您的系統(tǒng)架構(gòu)可能會(huì)影響您對(duì)事件和解決方案的響應(yīng)方式的一些方法棚辽。