可觀測性-不是你想的那樣

“  一個網際網路技術玩家，一個愛聊技術的傢伙。在工作和學習中不斷思考，把這些思考總結出來，並分享，和大家一起交流進步。 ”

| 3000字 | 閱讀大約需要6分鐘 | 

譯者： helight。

原文地址： 可觀測性-不是你想的那樣：

http://www.splunk.c om/en_us/blog/devops/observability-it-s-not-what-you-think.html

前言

可觀測性很多人估計會有一種疑惑：啥是可觀測性，和我們之前的監控系統有啥區別，怎麼老搞一些新名詞出來，學不動了呀。。。。

所以這篇文章從理論的角度出發，為可觀測性進行“強行”正名，更重要的是我也想看看整這些名詞的外國人是怎麼想的。

可觀測性是什麼？

可觀測性是一種思維方式，通過收集和分析你整個業務的資料讓你可以知道你業務的任何問題。如果你問其他人，可觀測性就是“通過檢視系統的輸出來監視系統的內部狀態”的乾巴巴的控制理論定義，或者是“度量指標、跟蹤和日誌”的非常專業名詞。雖然這些說法也是對的，但是可觀測性不僅僅是一個你要實現的東西，然後可以自豪的說“現在這個系統有了可觀測性了”。將可觀測性構建到你的業務中，可以讓你看清楚有關業務的問題。

有什麼樣的問題？

當然，“當錯誤數上升時我們的應用中發生了什麼”這樣的基礎問題就可以用可觀測性工具來回答，但這僅僅觸及了可觀測性的表面。

可觀測性思想能讓你能夠做的是找出為什麼錯誤數會飆升。如果你非常熟悉你的應用程式及其所有依賴項，那麼你可能會從監控系統中就看出問題所在了，但隨著現代應用程式變得越來越複雜，你自己可以根據監控系統中的資訊就可以分析出來問題所在會變的越來越困難。

業務需求、特性發布、A/B 測試、重構成為微服務。。。。。。諸如此類的事情結合在一起創造了不斷增加的熵，因此在沒有幫助的情況下了解系統的一切變得越來越困難。

可觀測性還允許你探究錯誤是如何(或者是否!)影響使用者體驗的。你可以檢視 RUM 資料、購買量、一般業務指標、營銷活動、客戶支援票據、社交媒體情緒，等等——這些資料將可觀測性系統從只有少數人使用的東西，變成了整個公司都能從中探究業務的東西。這些資料不僅能讓你回答“是什麼”，還能讓你回答“為什麼”和“如何”。一個真正的可觀測性套件可以讓你回答所有這些問題：

“是什麼導致了這一突破?” “這個廣告有多有效?” “這個新的前端設計推動了購買嗎?” “這次服務中斷讓我們的使用者生氣了嗎?”

你為什麼應該關心可觀測性？

將這種型別的資料整合到你的系統中，你就可以發現你給最好的客戶傳送的營銷活動中，有一個錯誤的動作 URL，該 URL 指向了一個 404 頁面。如果沒有將資料完全整合到你的可觀測性解決方案中，你當然可以看到 4xx 的速率增加了。但是，你不知道為什麼 4xx 的比率上升了，只知道 4xx 的比率上升了。

想象一下，如果除了“前端服務 4xx 高於閾值”之外，你還看到了同時發生的“營銷活動失效開始”的事件，那麼你可以多快地解決一個問題。你不僅會知道哪裡出了問題，還會很好地猜測出問題的原因，你還會有一個很好的跳板來調查這個錯誤給你帶來的收入影響，或負面影響。

為什麼說這不是監控？

正如我所說的，監控會告訴你某些地方出了問題，但它不會告訴你為什麼會出問題。監控設定也只能監控你認為可能有問題的東西（你的”已知“）。如果你沒有想到預先對相關元件進行檢測，則無法對其進行監控。更糟糕的是，如果出現問題並決定給它新增監視，你是仍然沒有關於元件執行的歷史資料。

此外，在你知道可能發生什麼問題之前，監控需要特別的關注點——你必須專門檢測指定的東西，並針對它們設定特定的告警。這需要時間來做並且容易出錯。

而且，無論你的監控解決方案有多好，它仍然不足以探測你的業務。傳統的監控系統不可能檢視“未知的事情”，因為資料根本不存在，無法進行評估。

在傳統的監控中，通常不支援新增業務指標，或者支援得很差。實時使用者資料幾乎從未包含在監控系統中，這是荒謬的，因為我們在 web 應用程式中所做的一切都是為了傳遞使用者體驗!

可觀測性“三大支柱”如何協同工作？

度量指標、跟蹤和日誌是可觀測性的“三大支柱”，它們是必要的，但不足以真正理解什麼是可觀測性，並深入瞭解你的應用程式和業務。

度量指標可以用來告訴你哪裡出了問題。

跟蹤可以告訴你是怎麼錯的——例如，哪些特定的呼叫不起作用。

日誌告訴你為什麼它是錯誤的，讓你深入到一個特定的度量指標/跟蹤，以找出它為什麼以你看到的方式執行。

收集這些資料是形成可觀測性思維的開始，但這僅僅是個開始。

為什麼你需要每一塊資料？

從簡單的角度來看，可觀測性的一個大問題是需要收集和保留太多的資料。“實際上，你不可能將現代服務產生的輸出量儲存在一個地方。

”大多數供應商提出的解決方案叫所謂的抽樣，但我更喜歡稱之為“丟棄資料”。被丟棄的資料可能是你最關鍵的客戶的交易。這可能是一個特殊的用例，它會導致一些奇怪的錯誤，並使你的資料庫服務崩潰。

更糟糕的是，許多供應商會宣傳這是一種“為你省錢”的功能。我將在另一篇博文中更詳細地介紹抽樣的隱性成本。

在一個經典的控制理論世界中，你有一堆儀表來監控關鍵的基礎設施，你會因為“30% 就足夠了”而拋棄 70% 的觀察結果嗎？當然，你不會這麼做，但這正是許多供應商建議你必須對可觀測性做的事情，因為問題資料的性質。事實並非如此。成熟的平臺可以處理與你的業務有關的所有資料，不會丟棄任何資料。

可觀測性不是一種實際操作，而是一種觀念

雖然本文討論了一些關於可觀測性的實現細節，但可觀測性真正的含義並不是“收集和儲存度量指標、跟蹤和日誌”。

這是一種“我們應該收集什麼樣的資料，才能有助於解決我們想要了解的業務問題”的思維。

可觀測性不僅僅是應用程式效能監控或基礎設施監控(儘管這些是它的一部分)。

它是關於理解攝取一切資訊的需要。真實使用者體驗指標。營銷活動。流量的季節性變化。你倉庫的人請病假了。

可觀測性是一種思維模式，它要求所有人(開發者、運營人員、產品、執行長等)使用的關於你的業務和應用程式的資料都必須有一個真實的單一來源。

數以百萬計的資料點組成了你的業務，而可觀測性是在一個系統中捕獲所有的資料，然後使用這些資料來回答問題，而不僅僅是你的業務執行的技術應用程式。

要充分利用可觀測性，你需要一個專門構建的流架構，它可以任意伸縮，並讓你持續收到你的更改如何影響使用者和業務的相關反饋。你需要一個將許多工具整合為一個共同的真理來源的系統，並從這些工具中提供見解。

後記

整個文章說的還是比較玄乎的，反正我在真實的業務場景中是無法做到收集那麼多資訊。雖然本文一再說可觀測性是一種思維，整個我不否認，確實感覺應該是一個全面的分析認識。但是到底如何實施，收集哪些必要的資訊，如何全面的收集到一起都是有很大挑戰難度的。

在我看來還是那種思維：大資料小做。無論再大的山也是要一點點幹到的。除非儲存和算力有非常大的提升，但是我在想提升算力的同時，需要觀測的資料也會更多，因為我們要解決的問題也會越來越大呀。

翻譯完了之後，感覺還是有點收穫的，不是一點都沒有。

看完本文有收穫？請分享