可檢視性模式

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

就像為了協助應用程式中的程式碼配置而開發的模式一樣，也有模式可讓您以可靠的方式操作應用程式。 目前已有三種可用來維護應用程式的模式：記錄、監視和警示。

使用記錄的時機

無論我們多麼謹慎，應用程式仍幾乎都會以非預期的方式在生產環境中運作。 當使用者回報應用程式的問題時，若能查看應用程式在問題發生時經歷了哪些狀況，會很有幫助。 要擷取應用程式在執行時所執行之作業的相關資訊，最常用且有效的方式之一，就是讓應用程式記下自身執行的工作。 此程序稱為記錄。 每當生產環境中發生失敗或問題時，首要工作應是在非生產環境中重現發生失敗的狀況。 妥善執行記錄，可讓開發人員有藍圖可據以在可測試及實驗的環境中複製問題。

雲端原生應用程式的記錄面臨的挑戰

在傳統應用程式中，記錄檔通常會儲存在本機電腦上。 事實上，在類似 Unix 的作業系統上，會定義一個資料夾結構用來保存任何記錄，通常位於 /var/log 底下。

圖 7-1. 在整合型應用程式中記錄到檔案。

在雲端環境中，記錄到單一機器上的一般檔案的效用會大打折扣。 產生記錄的應用程式可能無法存取本機磁碟，或者，由於容器會隨著實體機器隨機切換，本機磁碟可能極為暫時性。 即使是在多個節點間簡單擴大整合型應用程式，也可能導致難以找出適當的檔案型記錄檔。

圖 7-2. 在已調整的整合型應用程式中記錄到檔案。

使用微服務架構開發的雲端原生應用程式，也會對檔案型記錄器帶來一些挑戰。 使用者要求此時可能會跨多個在不同機器上執行的服務，且可能包含完全無法存取本機檔案系統的無伺服器函式。 要將使用者或工作階段在這麼多不同服務和機器間的記錄相互關聯，是非常困難的。

圖 7-3. 在微服務應用程式中記錄到本機檔案。

最後，某些雲端原生應用程式的使用者數目很可觀。 假設每個使用者在登入應用程式時都會產生一百行的記錄訊息。 單獨來看，這是可管理的，但若有超過 100,000 名使用者，其記錄數量在相乘下將十分龐大，而需倚賴特殊工具才能夠支援記錄的有效使用。

雲端原生應用程式中的記錄

每個程式設計語言都有允許寫入記錄的工具，且寫入這些記錄的額外負荷通常很低。 許多記錄程式庫都提供記錄不同類型嚴重性的功能，並且可在執行階段進行調整。 例如，Serilog 程式庫是適用於 .NET 的常用結構化記錄程式庫，提供下列記錄層級：

• 詳細資訊
• 偵錯
• 資訊
• 警告
• 錯誤
• 嚴重

這些不同的記錄層級可提供記錄的細微性。 當應用程式在生產環境中正常運作時，可以設定為僅記錄重要訊息。 當應用程式的運作異常時，則可提高記錄層級，以收集更詳細的記錄。 這樣可在高效能與輕鬆偵錯之間取得平衡。

記錄工具的高效能和詳細程度的可調整性，應該會促使開發人員經常進行記錄。 將每個方法從頭到尾記錄下來，是許多人慣用的模式。 這種做法聽起來可能有點過頭了，然而，少有開發人員會想減少記錄。 事實上，執行部署就只是為了替有問題的方法新增記錄，可謂屢見不鮮。 記錄不應太多，但總比太少好。 某些工具可用來自動提供這類記錄。

由於在雲端原生應用程式中使用檔案型記錄帶來了相關挑戰，建議應使用集中式記錄。 記錄會由應用程式收集，並送到中央記錄應用程式加以編製索引和儲存記錄。 這類系統每天可擷取數十 GB 的記錄。

在建置跨眾多服務的記錄時遵循某些標準做法，也會有所幫助。 例如，在較長的互動開始時產生相互關聯識別碼，然後將其記錄在與該互動相關的每個訊息中，就可更輕鬆地搜尋所有相關訊息。 只要找到單一訊息，再擷取相互關聯識別碼，就可以找到所有相關訊息。 另一個範例是確保每個服務的記錄格式都相同，無論其使用的語言或記錄程式庫為何。 這種標準化可讓讀取記錄更為容易許多。 圖 7-4 示範微服務架構如何使集中式記錄成為其工作流程的一部分。

圖 7-4： 來自各種來源的記錄都會擷取到集中式記錄存放區。

偵測及因應潛在的應用程式健康情況問題時面臨的挑戰

有些應用程式並非任務關鍵性應用程式。 這類應用程式或許只在內部使用，且在發生問題時，使用者可連絡負責的小組予以重新啟動。 然而，客戶對於自己使用的應用程式常會有較高的期望。 當應用程式發生問題時，您應在使用者發現或通知您之前掌握情況。 不要等到憤怒的社交媒體貼文爭相嘲諷您的應用程式甚或組織時，您才知道有問題發生。

您可能需要考量的案例包括：

• 應用程式中的某項服務持續失敗並重新啟動，導致間歇性的回應遲緩。
• 在一天之中的某些時間，應用程式的回應速度遲緩。
• 在最近的部署之後，資料庫的負載已達三倍。

正確實作時，監視可讓您得知有哪些狀況會導致問題，而在這些狀況對使用者造成任何重大影響之前及早加以處理。

監視雲端原生應用程式

某些集中式記錄系統還有其他作用，除了純粹的記錄外還會收集遙測資料。 這類系統可收集計量，例如執行資料庫查詢的時間、Web 伺服器的平均回應時間，甚至是作業系統報告的 CPU 負載平均值和記憶體壓力。 這些系統可與記錄搭配運作，提供系統中的節點與應用程式整體健康情況的綜合性檢視。

監視工具的計量收集功能也可以從應用程式內部手動饋送。 具特定相關性的商務流程 (例如新使用者註冊或下單等) 可接受檢測，以便在中央監視系統中增加計數器。 如此將可發揮監視工具的能力，不僅可監視應用程式的健康情況，還能監視企業營運情形。

您可以在記錄彙總工具中建構查詢，以尋找特定統計資料或模式，繼而在自訂儀表板上以圖形顯示。 小組常會投資購置大型壁掛顯示器，用以輪播應用程式的相關統計資料。 如此，在問題發生時就很容易能看出。

雲端原生監視工具提供對應用程式的即時遙測和深入解析，無論那是單一程序整合型應用程式，還是分散式微服務架構。 其中包括可讓您從應用程式收集資料的工具，以及查詢和顯示應用程式健康情況相關資訊的工具。

回應雲端原生應用程式的重大問題時面臨的挑戰

若您必須因應應用程式的問題，則須設法對適當人員發出警示。 這是第三個雲端原生應用程式可檢視性模式，需依賴記錄和監視。 您的應用程式必須備妥記錄，才能診斷問題，以及在某些情況下饋送至監視工具。 必須透過監視，將應用程式計量和健康情況資料彙總到單一位置。 建立此機制後即可建立規則，以在特定計量超出可接受的範圍時觸發警示。

一般而言，警示的層級會高於監視，以便讓某些條件觸發適當的警示，對小組成員發出緊急問題的通知。 可能需要警示的案例包括：

• 應用程式的其中一個服務在停止運作 1 分鐘後沒有回應。
• 應用程式對超過 1% 的要求傳回不成功的 HTTP 回應。
• 應用程式的主要端點平均回應時間超過 2000 毫秒。

雲端原生應用程式中的警示

您可以針對監視工具建立查詢，以尋找已知的失敗狀況。 例如，查詢可在傳入記錄中搜尋是否有 HTTP 狀態碼 500 (表示 Web 伺服器有問題)。 一旦偵測這類狀態碼，就可以將電子郵件或 SMS 傳送給原始服務的擁有者，讓他們展開調查。

不過，單憑 500 錯誤碼通常還不足以確認有問題發生。 這可能表示使用者輸入密碼時打錯字，或輸入了格式不正確的資料。 警示查詢必須設計成只有在偵測到超過 500 錯誤的平均數目時才會引發。

警示中最具破壞性的模式之一，是引發太多警示讓人調查。 若先前調查的錯誤都是良性的，服務擁有者很快就會變得對錯誤無感。 隨後，當真正的錯誤發生時，將會錯失在數百個誤判為真的雜訊中。 我們常對小孩講狼來了的故事，讓他們對這樣的風險有所警惕。 請務必確保引發的警示確實指涉真正的問題。

上一個下一個