傳統(tǒng)監(jiān)控的問題排查方法

構建儀表盤

從運維的角度來看，肯定少不了通過儀表盤來對系統(tǒng)進行監(jiān)控。傳統(tǒng)的監(jiān)控系統(tǒng)主要用于收集和匯總一定時間間隔內的性能指標，運維同學需要依靠這些指標的變化趨勢來分析系統(tǒng)的性能，基于過往的經驗判斷系統(tǒng)是否正常，哪里可能有問題；或者通過設定監(jiān)控指標的閾值進行告警。

將這些指標以圖表形式展現出來，各種各樣圖表的組合以及自定義的視圖便構成了一個個儀表盤。我們通常會為每一個系統(tǒng)服務設置一個靜態(tài)的儀表盤，通過它了解系統(tǒng)的運行狀態(tài)。然而，當我們在審視儀表盤的各項視圖，或是收到告警的時候，我們知道某項指標超出了閾值（比如生產環(huán)境的集群 CPU 平均使用率超過了 90%），但卻不能完全了解系統(tǒng)究竟發(fā)生了什么。

換句話說，不知道是什么導致了 CPU 的平均使用率過高。另一方面，當我們想使用儀表盤來進一步分析問題的時候，會受制于這些儀表盤的預設條件，只能查看預設的維度；如果想分析其他的維度，可能就進行不下去了。

因為這個維度的標簽很可能并沒有提前被添加進來，也就不能提供數據的聚合了。

使用儀表盤定位故障

這是一個工作日的早晨，你坐到辦公桌前，打開電腦，首先要做的事情就是看一下目前系統(tǒng)的整體情況。于是你開始瀏覽一組配置好的儀表盤，或者一個大屏，希望可以快速地看到系統(tǒng)的各個方面、各種組件以及它們的健康狀態(tài)。

你查看著儀表盤上的各個圖表和相關指標，突然發(fā)現儀表盤左下角某個區(qū)域的曲線超過了設定的基線，根據你的經驗，你會感覺這是數據庫的問題，因為之前也發(fā)生過類似的癥狀。于是你快速地查看了一下數據庫的狀態(tài)，想要確認你的懷疑。果不其然，你的懷疑被證實了，緊接著你馬上處理和解決了問題。類似地，你的腦海中可能還記錄了很多發(fā)現問題模式的組合。隨著時間的推移，你已經學會了通過觀測儀表盤中的各種特定指標來預測問題的來源。

你可以問問自己，在排查故障的全過程中，當你在系統(tǒng)的各個組件之間跳轉的時候，你在多大的程度上依賴這些模式的組合甚至說是你的直覺？通常，我們重視這種直覺，多年來也確實證實它可以給我們帶來很多便利和好處。

使用傳統(tǒng)監(jiān)控排查故障的局限性

然而現如今，隨著容器化的趨勢、容器編排平臺（例如 Kubernetes）的興起、系統(tǒng)架構向微服務的轉變、混合持久化（多種數據庫，消息隊列）的普遍使用，同時服務網格的引入、自動彈性伸縮實例的流行，甚至是無服務器（Serverless）的出現以及無數相關的 SaaS 服務的涌現，要將這些不同的工具串在一起形成一個現代系統(tǒng)體系結構，可能意味著一個請求在到達你控制的代碼時，已經執(zhí)行了多次跳轉。

在云原生系統(tǒng)中，進行調試最困難的不再是理解代碼的運行方式，而是找到有問題的代碼在系統(tǒng)中的位置。這時候，通過儀表盤來查看哪個節(jié)點或服務速度較慢是不太可能的，因為這些系統(tǒng)中的分布式請求經常在不同的節(jié)點中循環(huán)，要在這些系統(tǒng)中找到性能瓶頸非常具有挑戰(zhàn)性。當某個組件或者服務變慢了，一切都變慢了。更有挑戰(zhàn)性的是，因為云原生系統(tǒng)通常作為平臺運行，代碼可能存在于你甚至無法控制的系統(tǒng)中（比如云上的云原生服務或是 PaaS 資源）。

在現代世界中，每個請求都有可能跨越任意數量的服務和機器，這讓與這些請求相關的幾十個指標產生分裂，如果我們想推斷在這個過程中各種請求跳轉發(fā)生了什么，就必須將這些相關的指標都連接起來。而如果繼續(xù)通過傳統(tǒng)的設定閾值的方式進行故障定位，除非你能提前了解可能會在哪些節(jié)點出現問題，否則你將完全不知道故障是如何發(fā)生的，甚至都沒法設定相關的閾值。

傳統(tǒng)監(jiān)控只能解決 Known-Unknowns 的問題

這種傳統(tǒng)的監(jiān)控方法是完全被動的，但是許多團隊接受并且一直在使用這種最簡單的方法排除故障。所以你會發(fā)現，有時候自己總是在被動響應、不停地四處滅火。由于業(yè)務架構微服務化，加上日益普及的敏捷開發(fā)模式，業(yè)務的迭代速度變得非常快，這會導致儀表盤中配置的各種指標隨著時間快速失效。結果就是，以往的告警和經驗模式逐漸失去作用。每次出現故障，復盤的結果就是再增加一些指標或是一些告警，然而這些告警將來可能再也不會被觸發(fā)。

因為本質上來說，依賴傳統(tǒng)的監(jiān)控系統(tǒng)，解決的是 Known-Unknowns 的問題（即你能夠感知、但是不理解的問題）。比如說 CPU 使用率達到 90% 觸發(fā)了告警，但卻不清楚是什么原因導致了 CPU 的使用率如此之高。對于越來越多第一次發(fā)生的事情，你不可能知道這些本來你就不知道的情況，即 Unknown-Unknowns（即你既不理解、也沒有感知的問題）。

在過去很長一段時間里，我們都認為它是最正常的運維行為。然而，監(jiān)控畢竟是一種被動反應性方法，它最適合檢測已知的問題和過去遇到過的情況。但是，隨著系統(tǒng)復雜性的不斷增加，系統(tǒng)性能問題的背后，涉及越來越繁多的相關性和可能性，很多問題超出了任何個人或團隊能夠直觀理解的范疇，所以是時候引入突破這種被動和限制性的工具和方法了。

通過可觀測性進行問題排查

這時候可觀測性就該出場了。可觀測性的概念我們前面也講過，它的重點就是通過查看和分析高維度和高基數數據，發(fā)現埋藏在復雜系統(tǒng)架構中的隱藏問題，而且不需要事先預測問題可能發(fā)生在哪里，以及問題發(fā)生的模式，這是可觀測性和監(jiān)控的第一個區(qū)別。

針對應用軟件監(jiān)測，而不僅僅是基礎設施

可觀測性和監(jiān)控的第二個區(qū)別是，關注的維度不一樣。監(jiān)控更加關注基礎設施的資源情況，因為監(jiān)控工具實在太多了。中大型的企業(yè)可能要部署多套監(jiān)控軟件，針對不同基礎設施、不同的產品組件（例如中間件、數據庫等）來使用不同的產品或工具。這種就造成了資源浪費，還會出現學習曲線太長，認知成本、協同成本、系統(tǒng)更新成本太高等一系列問題。將一切整合起來的可觀測性就和原來的監(jiān)控不同了：可觀測平臺瞄準的恰恰是應用軟件本身。

可觀測性的目標是保障應用軟件的可靠性和穩(wěn)定性，解決的是應用軟件在運行時的調試問題。我相信除了運維需要通過可觀測性解決系統(tǒng)的問題之外，開發(fā)人員也都希望自己能夠隨時隨地調試自己的代碼，尤其是生產環(huán)境，從而確保系統(tǒng)的可靠性（有關團隊合作的一些最佳實踐，在后面的課程中我會進一步詳細說明）。對于應用程序代碼，最重要的指標是用戶的體驗。底層系統(tǒng)可能基本上是健康的，但用戶請求仍然可能因為多種原因而失敗。

如前幾講所述，分布式系統(tǒng)使這些類型的問題更難檢測和理解。所以，使用高基數字段（用戶 ID、購物車 ID 等）作為觀察特定客戶體驗的一種方式的能力變得至關重要。尤其是在持續(xù)交付的現代世界中，隨著新版本代碼的不斷部署，軟件關注點總是在變化和變化?？捎^測性提供了一種提出適當問題的方法，可以實時解決這些問題。

全面收集和關聯數據

可觀測性和監(jiān)控的第三個區(qū)別，體現在數據收集的全面性（不僅僅是指標數據）和關聯性上。不論你是運維工程師，還是開發(fā)工程師，都可以通過工具或者產品構建自己在線系統(tǒng)的可觀測性，我們的最終目標都是用實時的數據來調試自己的線上環(huán)境。構建自身系統(tǒng)完整的可觀測性需要的能力非常廣泛，一般情況下，對于大部分企業(yè)來說，這是一個包括數據收集、集成、展示在內的綜合性系統(tǒng)工程。

它可能涵蓋的技術從底層操作系統(tǒng)，到各種語言環(huán)境網絡協議，甚至還涉及前端用戶訪問數據，eBPF，Profiling 等等，這是一個非常龐大的知識結構。而且，僅僅收集數據也是不夠的，利用數據所提供的可視化、交互性來真正意義上讓可觀測性落地才是核心。所以從構建可觀測性的角度來說，它不僅包括數據收集，還包括數據的一致性和關聯關系，這樣才能更好地讓不同維度的數據通過可視化友好地進行交互。而傳統(tǒng)的監(jiān)控主要還是關注基礎設施層面的資源狀態(tài)和使用情況。

通過數據來進行故障排查有了數據，我們就要在這個基礎上進行故障排查了。如果只是站在運維監(jiān)控的角度，可觀測性似乎是一個數據量更大更全的、但反而讓運維不知道從哪開始的監(jiān)控系統(tǒng)。但我認為，可觀測性強調的是從應用和業(yè)務維度，用各種數據垂直且實時地描述這個應用的全貌，它采用的不是傳統(tǒng)的分層邏輯，不是用不同的獨立的監(jiān)控系統(tǒng)分開關注每一層的情況（例如基礎設施、中間件、數據庫、應用服務端代碼、客戶端等等）?？捎^測性和傳統(tǒng)監(jiān)控的差異，也解釋了為什么很多傳統(tǒng)運維的儀表盤在分布式架構中用處越來越小，因為對于復雜系統(tǒng)來說，很多之前沒有發(fā)生過的問題，單靠儀表盤并不能有效地發(fā)現根本原因。而可觀測性強調的是高維度和高基數的數據，通過這些數據的關聯，可觀測允許我們從任何一個角度分析問題，而不是依靠直覺和經驗。

通過數據來進行故障排查

有了數據，我們就要在這個基礎上進行故障排查了。如果只是站在運維監(jiān)控的角度，可觀測性似乎是一個數據量更大更全的、但反而讓運維不知道從哪開始的監(jiān)控系統(tǒng)。

但我認為，可觀測性強調的是從應用和業(yè)務維度，用各種數據垂直且實時地描述這個應用的全貌，它采用的不是傳統(tǒng)的分層邏輯，不是用不同的獨立的監(jiān)控系統(tǒng)分開關注每一層的情況（例如基礎設施、中間件、數據庫、應用服務端代碼、客戶端等等）。可觀測性和傳統(tǒng)監(jiān)控的差異，也解釋了為什么很多傳統(tǒng)運維的儀表盤在分布式架構中用處越來越小，因為對于復雜系統(tǒng)來說，很多之前沒有發(fā)生過的問題，單靠儀表盤并不能有效地發(fā)現根本原因。

而可觀測性強調的是高維度和高基數的數據，通過這些數據的關聯，可觀測允許我們從任何一個角度分析問題，而不是依靠直覺和經驗。

舉個例子，針對一個內存溢出（即我們常說的 OOM）的問題，臨時增加內存可能可以解決問題，但這種方式并沒有找到問題的根源，下一次這個問題很可能還會出現；根本的解決方法，還是通過可觀測性找到導致內存溢出的根本原因，知道是哪個進程有問題，甚至是哪段代碼導致的這個問題。

可觀測性提供了一種不同的診斷方法，它能夠幫助你研究任何系統(tǒng)，無論這個系統(tǒng)多么復雜，不需要依靠經驗或“直覺”。有了可觀測性工具，我們不再只能依賴團隊中最有經驗的工程師，而是可以全面收集和關聯數據，通過探索性的問題來詢問系統(tǒng)和應用，通過數據分析和發(fā)現來進一步開放式地查詢和下鉆，直到找到問題或故障的根本原因。

《 運維監(jiān)控系統(tǒng)實戰(zhàn)筆記》學習筆記 Day13