譯者 | 崔皓   

策劃 | 云昭

本文聚焦于信息系統(tǒng)的觀察性，特別是在大型信息系統(tǒng)中如何應(yīng)用可觀測性，讓其在大型分布式組織中產(chǎn)生奇效。 

什么是可觀測性？

根據(jù)維基百科的說法：“通過系統(tǒng)的外部輸出來推斷和度量，系統(tǒng)的內(nèi)部狀態(tài)。在控制理論中，線性系統(tǒng)的可觀測性和可控性是數(shù)學(xué)對偶的?！?/span>

簡單來說，可觀測性就是通過外部輸出來描述系統(tǒng)內(nèi)部的狀態(tài)。 

可觀測性的三大支柱

1、指標(biāo) 

數(shù)據(jù)傳感器通過時間序列的方式提供低延遲的快速反饋，從而反映系統(tǒng)的性能指標(biāo)。

2、痕跡

通過跟蹤數(shù)據(jù)的流動找到錯誤發(fā)生的位置。

3、日志

通過文本數(shù)據(jù)的方式描述在低應(yīng)用級別發(fā)生的事件。

從上面三點(diǎn)可以得出系統(tǒng)的可觀測性是都從數(shù)據(jù)收集開始的，無論系統(tǒng)復(fù)雜或是簡單，數(shù)據(jù)采集是分析和行動的基礎(chǔ)。

如何讓系統(tǒng)具備可觀測性

在分布式、云計(jì)算和微服務(wù)的世界中，讓系統(tǒng)具備可觀測是一個非常困難的事情。從用戶交互的角度分析系統(tǒng)時，實(shí)現(xiàn)可觀測會變得容易得多。用戶在面對系統(tǒng)的時候應(yīng)該知道系統(tǒng)的運(yùn)行狀態(tài)：好或者壞，工作或者不工作，運(yùn)行成功或者失??？

有很多來自現(xiàn)實(shí)世界的例子也驗(yàn)證了這一點(diǎn)，例如每天都要經(jīng)歷的事情：

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

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

收集指標(biāo)、日志和跟蹤數(shù)據(jù)

如果上面的假設(shè)成立，要想知道系統(tǒng)的整體狀態(tài)，就需要從每個組件收集指標(biāo)。同時還需要知道歷史狀態(tài)、在時間區(qū)間里狀態(tài)是如何變化的。為了達(dá)到這個目的，就意味著需要不斷地從組件中收集狀態(tài)數(shù)據(jù)。一旦有了這些指標(biāo)數(shù)據(jù)，就可以構(gòu)建漂亮的儀表盤視圖了。

Nginx ingress controller 儀表盤

炫酷的儀表盤會讓領(lǐng)導(dǎo)覺得你的工作很有意義，那么需要哪些指標(biāo)來說明系統(tǒng)的狀態(tài)呢？同時，如何從眾多的指標(biāo)中，選中對用戶體驗(yàn)和業(yè)務(wù)運(yùn)營至關(guān)重要的 指標(biāo)呢？

 主要指標(biāo) 

縱觀一些可能成為主要指標(biāo)的數(shù)據(jù)例如KPI 、測量數(shù)據(jù)等，我們發(fā)現(xiàn)接下來的三個指標(biāo)顯得尤為重要，因?yàn)樗鼈冎苯佑绊懹脩趔w驗(yàn)和業(yè)務(wù)運(yùn)營。1、錯誤率 顯示事情未按預(yù)期進(jìn)行的主要指標(biāo)。當(dāng)用戶的請求沒有得到成功響應(yīng)時，通常會產(chǎn)生錯誤率。2、響應(yīng)時間 表示從用戶請求到得到反饋的時間。3、資源利用 表示資源分配與空閑的情況，例如內(nèi)存、CPU、磁盤等資源的利用情況，可以表明系統(tǒng)在沒有外部幫助的情況下工作的時長。

第四大支柱 ：事件

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

問題事件的訂閱與提醒

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

警報結(jié)構(gòu)

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

（1）嚴(yán)重性 

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

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

（2）描述 

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

（3）位置 

區(qū)域、集群、應(yīng)用程序或組件名稱標(biāo)識出現(xiàn)問題的位置以及爆炸半徑。

（4）爆炸半徑

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

行動

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

追蹤    

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

日志    

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

總結(jié)    

雖然，可觀測性在系統(tǒng)中不作為一個功能存在，但它具有非常重要的作用，可觀測性的優(yōu)劣會直接影響用戶體驗(yàn)。良好的可觀測性提供有關(guān)系統(tǒng)運(yùn)行狀態(tài)的快速反饋，甚至在用戶面臨問題之前就提前發(fā)現(xiàn)并通知潛在的問題。如果沒有良好的可觀測性作為基礎(chǔ)，當(dāng)系統(tǒng)出現(xiàn)問題時，采取任何的補(bǔ)救措施都是徒勞的。因?yàn)橛脩粼诿媾R系統(tǒng)問題時，可能早就用腳投票轉(zhuǎn)而使用別家的服務(wù)和產(chǎn)品了。所以，要提升系統(tǒng)的可觀測性，以便能夠?yàn)橛脩舸蛟旄玫漠a(chǎn)品和服務(wù)。

原文鏈接：

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

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過60萬?！斗植际郊軜?gòu)原理與實(shí)踐》作者。

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