想象一下，在沒有財務預測的情況下經營企業，甚至不知道銀行剩下多少錢。您怎麼知道您是在巨大的現金緩衝中游泳還是由於資金不足而需要跳過客戶午餐？如果不注意自己的財務狀況，根本就不可能開展健康的業務。同樣，如果不觀察您的計算基礎架構，就不可能保持應用程序運行正常。
事實上，可觀測性非常重要，到2021年2月，雲原生計算基金會(CNCF)列出了102個可觀察性項目。可觀測性不僅重要，而且昂貴。Netflix被戲稱爲一個產生大量日誌的平臺，同時也是一個流視頻平臺。可觀測性之所以昂貴，有兩個原因:
-
可觀測性比被觀測系統至少可靠一個數量級。否則，你將繼續調試你的可觀察性堆棧，而不是使用它來保持你的應用程序運行。
-
因爲你永遠不知道要觀察什麼，直到事件發生後，觀察多於需要的東西是很常見的。一個好的汽車司機不僅要向前看，而且還要不斷掃視周圍以避免事故。
在這篇文章中，讓我們深入探討一下可觀測性:它是什麼，不同類型的可觀測性，以及實現可觀測性在技術上意味着什麼。在這篇文章的最後，你會明白爲什麼你應該抵制住誘惑，然後在可觀測性上節省資金。
什麼是可觀測性
可觀測性有許多名稱，如監測、審計、遙測、儀器。忽略這些細微差別，所有這些詞本質上的意思都是一樣的:度量您的基礎設施、平臺和應用程序，以瞭解它是如何運行的。正如彼得·德魯克(Peter Drucker)曾經說過的:
如果你無法量化它，你就無法管理它。
如果你熟悉精益思維——即構建-度量-學習——那麼可觀察性就會自然而然地出現在你身上。可觀測性通過測量階段閉合反饋迴路。它允許您的團隊對應用程序進行快速更改，快速適應其用戶基礎和環境，而不會產生不必要的意外。良好的可觀測性可以將凌晨2點被喚醒轉換爲日常檢查。
真正的可觀測性是什麼
當談到可觀測性時，我們通常嘗試回答三個問題:
-
我的用戶滿意嗎? -
我的應用是否令人滿意? -
我的服務令人高興嗎?
我們通過三種方式做到這一點:跟蹤、日誌和指標。前者產生更多的數據，但不一定更多的洞察力。如今，這些技術都有望接近實時。(你願意要一個告訴你昨天的心率的心率監測器嗎?)
讓我們來看看日誌記錄和度量標準，這兩個您絕對應該擁有的。
在編寫應用程序時，您的團隊通常會添加日誌代碼。當代碼執行經過一個主要事件時，這些顯式的指令將產生一個日誌行，即一堆有意義的文本。例如，用戶X已登錄或用戶Y身份驗證失敗，等等。這幾行是問你的客戶他們是否嘗試清理瀏覽器緩存並重新加載或實際監控他們之間的區別。
日誌記錄是非常明確的:您的團隊需要添加日誌記錄代碼，並且需要預見要記錄什麼。經驗法則是，所有主要的邊界事件都需要被記錄。有些應用程序錯誤只在生產環境中出現，所以您應該選擇日誌過多而不是日誌不足。否則，大量時間就會浪費在尋找所謂的海森堡bug(heisenbug)上:這種bug很難復現，但卻會引起用戶的不滿。
日誌記錄會產生大量的數據。爲了節省成本，最好考慮短期和長期日誌。短期日誌-例如，最近7天-應該是可搜索的，也就是說，你應該能夠在幾秒鐘內執行全文搜索。像Elasticsearch/Kibana和Loki這樣的項目最適合這個目的。
長期日誌可以以最便宜的形式存儲，通常是對象存儲。它們不能立即搜索，因此，需要通過它們進行搜索的可能性也很小。事實上，如果您希望在隱私方面犯錯，最好避免長期日誌。
有時，您並不關心確切的日誌行，而是關心特定事件發生的次數。這些信息可以從日誌中提取，但是有一種更有效的方法:指標。
指標
指標——也稱爲服務水平指標(SLI)或關鍵性能指標(KPI)——是數字值的時間序列。可以把它想象成每小時記錄所有大城市的室外溫度。指標使用最少的空間，提供最多的洞察力(爲它們使用的空間)。它們可以記錄每小時活動用戶的數量、應用程序收到的請求的數量、可用磁盤空間的數量等。關注指標可以確保您的用戶在使用應用程序時獲得良好的體驗，同時還可以降低基礎設施的成本。
度量標準是相當明確的。您的團隊需要添加用於收集和公開給定度量的代碼。然而，市面上最常用的工具，如Nginx、Kubernetes或MySQL，已經輸出了大量的指標，這些指標應該可以爲您提供良好的態勢感知。
像Prometheus這樣的項目可以幫助您以應用程序所需的最少支持來收集度量，而Grafana可以幫助可視化度量。事實上，我認爲佈滿Grafana儀表盤的屏幕可以很好地裝飾辦公室的牆壁。這樣你很清楚，上班的時候有什麼事情可以處理。
到目前爲止，我們討論了可視化，也就是一種更有意爲之的可觀測性。但是，如果這個系統現在需要關注呢?
告警
警報就像系統呼救，請求人類的注意。通常，如果給定的指標超過了閾值，隨叫隨到的人員就會收到Slack或微軟團隊中的電子郵件、短信或消息。可以實現自動升級，例如，如果第一個隨叫人在30分鐘內沒有響應警報，第二個隨叫人就會得到警報。
警報是棘手的。警報太多，系統就會變成狼來了，你的團隊將以警惕疲勞結束，並開始忽視甚至是重要的問題。提醒太少，你的客戶就會爲你做提醒……這通常不是首選的提醒渠道，至少你的會計會抱怨必須兌現太多的發票。
因此，何時發出警報的門檻應該很高。這是凌晨2點或求救事件嗎?也就是說，如果發生這種情況，應該叫醒某人嗎?或者這是一個泛泛的事件，可以在白天處理?
幸運的是，像Prometheus這樣的項目不僅能發出警報，還能進行預測。知道磁盤將在72小時內被填滿，可以防止客戶因停機而失望，也可以防止破壞團隊成員的良好睡眠。
總結
缺乏可觀測性就像閉着眼睛開車:你不知道離災難有多近。你開得越快，路越忙，你就越要小心。
可觀測性也是一樣:你越想讓你的團隊越快地添加功能，你就越應該在可觀測性上投資。而且，雖然在可觀測性上節省一些錢可能很誘人，但這些節省將在下一次緩慢修復事件中迅速消失。
另外，送福利了，最近我準備了關於各大廠的雲原生技術最佳實踐資料，請點擊關注如下公衆號，回覆【雲原生】獲取
本文分享自微信公衆號 - 雲原生技術愛好者社區（programmer_java）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。