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

譯者：helight。

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

https://www.splunk.com/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% 的觀察結果嗎？當然，你不會這麼做，但這正是許多供應商建議你必須對可觀測性做的事情，因爲問題數據的性質。事實並非如此。成熟的平臺可以處理與你的業務有關的所有數據，不會丟棄任何數據。

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

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

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

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

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

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

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

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

後記

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

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

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

辰霏軟件技術 關注開源，linux 軟件開發技術丨內核，ebpf 技術丨大數據、微服務技術 ｜ DevOps | 系統架構，歡迎多交流

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0L28CCrEoGoYhYtcd4zQ_A