譯者 | 崔皓   

策劃 | 云昭

本文聚焦于信息系統的觀察性，特別是在大型信息系統中如何應用可觀測性，讓其在大型分布式組織中產生奇效。 

什么是可觀測性？

根據維基百科的說法：“通過系統的外部輸出來推斷和度量，系統的內部狀態。在控制理論中，線性系統的可觀測性和可控性是數學對偶的。”

簡單來說，可觀測性就是通過外部輸出來描述系統內部的狀態。 

可觀測性的三大支柱

1、指標 

數據傳感器通過時間序列的方式提供低延遲的快速反饋，從而反映系統的性能指標。

2、痕跡

通過跟蹤數據的流動找到錯誤發生的位置。

3、日志

通過文本數據的方式描述在低應用級別發生的事件。

從上面三點可以得出系統的可觀測性是都從數據收集開始的，無論系統復雜或是簡單，數據采集是分析和行動的基礎。

如何讓系統具備可觀測性

在分布式、云計算和微服務的世界中，讓系統具備可觀測是一個非常困難的事情。從用戶交互的角度分析系統時，實現可觀測會變得容易得多。用戶在面對系統的時候應該知道系統的運行狀態：好或者壞，工作或者不工作，運行成功或者失敗？

有很多來自現實世界的例子也驗證了這一點，例如每天都要經歷的事情：

• 你今天感覺如何？你能去上班嗎？
• 你的車怎么樣？準備好開車了嗎？

對于這些事情我們并沒有特別去考慮它們，因為這些事情都是順其自然地發生的。但是，如果要在系統中回答這些問題就需要指標做支撐。例如，要知道我們是否正常，需要測量溫度、壓力以及提供血液的分析結果。要說這輛車是否準備好了，需要查看控制面板是否正常。假設在系統中有很多組件，那么系統的整體狀態就是各個組件狀態的聚合（所有組件狀態的二進制乘法，就是這個聚合結果）。 

收集指標、日志和跟蹤數據

如果上面的假設成立，要想知道系統的整體狀態，就需要從每個組件收集指標。同時還需要知道歷史狀態、在時間區間里狀態是如何變化的。為了達到這個目的，就意味著需要不斷地從組件中收集狀態數據。一旦有了這些指標數據，就可以構建漂亮的儀表盤視圖了。

Nginx ingress controller 儀表盤

炫酷的儀表盤會讓領導覺得你的工作很有意義，那么需要哪些指標來說明系統的狀態呢？同時，如何從眾多的指標中，選中對用戶體驗和業務運營至關重要的 指標呢？

 主要指標 

縱觀一些可能成為主要指標的數據例如KPI 、測量數據等，我們發現接下來的三個指標顯得尤為重要，因為它們直接影響用戶體驗和業務運營。1、錯誤率 顯示事情未按預期進行的主要指標。當用戶的請求沒有得到成功響應時，通常會產生錯誤率。2、響應時間 表示從用戶請求到得到反饋的時間。3、資源利用 表示資源分配與空閑的情況，例如內存、CPU、磁盤等資源的利用情況，可以表明系統在沒有外部幫助的情況下工作的時長。

第四大支柱 ：事件

毋庸置疑儀表盤確實是很好的監控工具，但我們需要一直關注它嗎？雖然你可以這么做，但這并不是最有效的檢測系統的方式。我們完全可以輕松檢測系統的一舉一動，并讓指標工具在應用程序狀況不佳時對您進行通知通知：這就是“事件”。首先，需要從指標輸出中發現系統的不良狀態，并對其進行定義。此時可以關注系統在極端條件下（在高負載）的行為，可以通過JMeter 或 Gatling 等工具在測試環境中模擬高負載，從而達到觀測的效果。通過這種方式讓你更好地了解應用功能以及哪些指標對系統至關重要。接下來就可以針對這些指標進行自動警報的設置。警報是一個強大的工具，因為它的出現我們不必時刻監控儀表盤，只在需要儀表盤的時候打開它們。這讓我想到人體是如何處理問題的，我們從不會時刻關注我們身體的某個部位并確保它們正常工作。相反，如果一切正常的話，這些身體的部位就會正常運作，一旦出現問題，大腦將會收到疼痛信號通知。這個疼痛的信號就好像系統的報警通知一樣，提醒我們身體的某個部位出現了問題。

問題事件的訂閱與提醒

市面上的系統監控工具都相對成熟，并且支持電子郵件、Slack 、webhook 等方式發送警報信息。并可以通過配置將警報信息發送給管理員、用戶、操作員，以便做到責任到人。還有一種報警方式是通過 HTTP webhook 將警報事件發送給專門的可觀測性服務，讓該服務進行下一步操作，例如災難恢復、ML 訓練，或通知其他相關服務。注意：使用警報，將提升資源利用率、自動化對系統的整體控制。

警報結構

在說完了事件報警之后，再來聊聊報警消息的結構：在警報信息中到底包含哪些內容？這里我們又可以站在用戶的角度來尋找答案。通常來說出現報警之后都是運營商或開發人員來解決問題的，因此警報信息的內容就需要有助于了解問題的嚴重性、原因和影響范圍，從而協助上述人等解決問題。

（1）嚴重性 

表述資源所處的狀態，從而定義采取行動的重要性：

服務正面臨匱乏，這意味著如果不采取措施，它將無法工作。即便在用戶抱怨響應時間和錯誤之前，該指標也有助于避免問題。

（2）描述 

用來表明警告/錯誤消息所顯示問題的可能原因。包括 traceId 將有助于從現有監控工具中獲取更多信息。

（3）位置 

區域、集群、應用程序或組件名稱標識出現問題的位置以及爆炸半徑。

（4）爆炸半徑

爆炸半徑是一個軍事術語，但把它用在現實生活中卻毫無違和感。定義問題波及的范圍，并把警報事件發送給正確的團隊，同時爆炸半徑有助于識別受影響的應用程序、團隊和組件。這樣不會將報警信息發給范圍之外的團隊，避免分散其他團隊的注意力，讓團隊知道報警的范圍是經過嚴格定義，因此當接收報警的團隊會提升參與度更加專注地解決問題。

行動

關注如何解決報警事件所包含的問題。這里需要提供有價值的線索和文檔來幫助解決問題。例如：有些問題可能需要手動操作，無法通過應用程序代碼或配置更改來修復。還例如偶爾重復出現的問題可能已經在以前發生過多次，SRE 團隊就已經知道如何解決。這類知識就應該形成產品文檔（即生產事件日志）并進行歸檔，同時在成員之間共享。將與解決問題相關的文檔作為引用添加到警報消息中將有助于有效地解決問題。

追蹤    

跟蹤的目的是快速找到問題發生的位置。使用 Jaeger、Zipkin of Honeycomb 等工具可以快速識別組件、應用程序名稱，甚至是確切的方法調用。

日志    

日志記錄可能是程序員首創的可觀測性技術，這種方式通過查找程序錯誤和故障的詳細信息從而解決問題。在應用程序內部發生的所有事件都以文本或 JSON的形式保存在日志文件里，并可以通過日志工具對其進行查詢，例如 Splunk、ElasticSearch，其中全文搜索引擎有助于關鍵字的查詢。同時還包含問題的詳細信息，以及最后出現問題的可觀測點，工程師可以從中找到解決問題的答案。如果沒有日志的幫助，也可以使用遠程調試技術，不過這就是另外一個話題了，超出了本文討論的范疇。

總結    

雖然，可觀測性在系統中不作為一個功能存在，但它具有非常重要的作用，可觀測性的優劣會直接影響用戶體驗。良好的可觀測性提供有關系統運行狀態的快速反饋，甚至在用戶面臨問題之前就提前發現并通知潛在的問題。如果沒有良好的可觀測性作為基礎，當系統出現問題時，采取任何的補救措施都是徒勞的。因為用戶在面臨系統問題時，可能早就用腳投票轉而使用別家的服務和產品了。所以，要提升系統的可觀測性，以便能夠為用戶打造更好的產品和服務。

原文鏈接：

https://dzone.com/articles/systems-observability-1

譯者介紹

崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。曾任惠普技術專家。樂于分享，撰寫了很多熱門技術文章，閱讀量超過60萬。《分布式架構原理與實踐》作者。

51CTO技術精選月刊《CTO悟道》最新一期已經上線！更多精彩技術干貨、知識見解等你揭曉，下載鏈接：??http://m.ekrvqnd.cn/journalDetail/5.html?down=3??