檢測應用程式的建議

適用於此 Azure 架構完善的架構營運卓越檢查清單建議：

相關指南： 設計及建立監視系統的建議

本指南說明使用檢測啟用應用程式可觀察性的建議。 產生有意義的遙測，以內嵌並整合到您的監視系統中。 藉由使用檢測，您可以收集資訊而不登入遠端生產伺服器，以手動執行追蹤或偵錯。 檢測數據報含計量和記錄，可用來評估效能、診斷問題，以及做出工作負載決策。

關鍵設計策略

若要將工作負載的遙測優化，請檢測您的應用程式以產生下列數據：

• 記錄 是離散事件的時間戳記錄。 記錄有三種形式：純文本、結構化和二進位。

• 分散式追蹤記錄 可讓您在要求通過不同的服務和元件時查看要求的路徑。

• 計量是數值，可描述特定時間點的系統層面。

使用結構化記錄和追蹤

使用結構化記錄，輕鬆地將記錄整合到監視和分析平臺。 檢測您的應用程式，以便變更詳細資訊層級。 常數詳細信息記錄可能會浪費記憶體資源，因此應該視需要開啟和關閉以進行疑難解答。

如果應用程式使用 Windows 事件追蹤（ETW），追蹤記錄包含從追蹤事件建立的文字數據或二進位數據。 系統記錄會從基礎結構中的事件產生追蹤記錄內容，例如網頁伺服器。 文字記錄內容是設計成人類可讀取，但您應該確保其以自動化系統也可以剖析的格式撰寫。

將記錄分類，並使用個別的記錄來記錄系統每個作業層面的追蹤輸出。 如果您將記錄分類，您可以快速篩選記錄訊息，而不是處理單一冗長的檔案。 永遠不要將具有不同安全性需求的資訊，例如稽核資訊和偵錯數據寫入相同的記錄檔。

擷取應用程式計量

計量或 範例是特定時間系統中某些層面或資源的計數，其中包含一或多個相關聯的標籤或維度。 計量的單一實例在隔離時並無用處，應該隨著時間擷取計量。 請考慮您應該記錄哪些計量，以及記錄的頻率。 太常產生的數據可能會對系統造成繁重負載，但不常的數據擷取可能會導致您錯過導致重大事件的情況。 擷取數據的適當頻率可能會因計量而異。 例如，伺服器上的CPU使用量可能會從秒到秒有顯著差異，但高使用量只會在幾分鐘內保持一致時變成問題。

促進元件之間的相互關聯

您可以輕鬆地監視個別和系統層級的性能計數器、擷取資源的計量，以及從各種記錄檔取得應用程式追蹤資訊。 某些監視需要在監視管線中的分析和診斷階段期間進行數據相互關聯。 此數據可以採用數種形式，而且分析程式必須提供足夠的檢測數據來對應這些不同的表單。 例如，在應用程式架構層級，線程標識碼可能會識別工作。 在應用程式內，相同的工作可能會與完成該工作的使用者的使用者標識符相關聯。

線程與使用者要求之間不太可能是 1：1 對應，因為異步操作可能會針對多個使用者重複使用相同的線程。 為了進一步使問題複雜化，單一要求可以與一個以上的線程相互關聯，因為它會流經系統。 可能的話，請將每個要求與透過系統傳播為要求內容一部分的唯一活動標識符產生關聯。 在追蹤資訊中產生和包含活動標識碼的技術取決於用來擷取追蹤數據的技術。

所有監視數據都應該以相同的方式進行時間戳。 為了保持一致性，請使用國際標準時間記錄所有日期和時間。

擷取相關數據

當您決定需要收集的檢測數據時，請考慮下列幾點。

人類可讀取的數據

確定追蹤事件所擷取的信息同時是機器和人類可讀取的。 針對此資訊採用定義完善的架構，協助實作跨系統自動處理記錄數據，併為讀取記錄的作業和工程人員提供一致性。

在您的資料中包含下列環境資訊：

• 部署環境
• 處理電腦
• 程序的詳細數據
• 呼叫堆疊

投資可追蹤性和相互關聯

提供足夠的內容，例如與特定要求實例相關聯的活動標識碼，讓開發人員或系統管理員可以判斷每個要求的來源。

數據內容也可能包含用來將活動與執行之計算工作和所用資源相互關聯的資訊。 這項工作可能會跨越進程和機器界限。

針對計量，內容應該直接或間接包含造成要求的客戶參考。 此內容提供有關擷取監視數據時應用程式狀態的寶貴資訊。

擷取所有相關數據

記錄所有要求及其建立位置或區域。 您可以使用這項資訊來協助識別特定位置的熱點。 這項資訊也有助於判斷是否要重新分割應用程式或其使用的資料。

仔細記錄並擷取例外狀況的詳細數據。 嚴重偵錯資訊通常會因為例外狀況處理不佳而遺失。 盡可能擷取應用程式擲回的所有例外狀況詳細數據，包括任何內部例外狀況或其他內容資訊，例如呼叫堆棧。

爭取數據一致性

一致的數據可協助您分析事件，並將其與使用者要求相互關聯。 請考慮使用完整且可設定的記錄套件來收集資訊。 記錄套件可協助您避免依賴開發人員在實作系統的不同部分時採用您的方法。

從關鍵性能計數器收集數據，例如輸入/輸出磁碟區、要求數目，以及記憶體、網路和CPU使用量。 某些基礎結構服務會提供自己的性能計數器，例如：

• 資料庫的連線數目。
• 交易速率。
• 成功或失敗的交易數目。

應用程式也可能定義自己的性能計數器。

考慮外部相依性

記錄所有外部服務呼叫。 可能會對外部呼叫進行下列動作：

• 資料庫系統。
• Web 服務。
• 屬於基礎結構的其他系統層級服務。

記錄每個通話持續時間和通話成功或失敗的相關信息。 可能的話，擷取所有發生暫時性錯誤之重試嘗試和失敗的相關信息。

確定遙測系統相容性

在許多情況下，檢測資訊會以一系列事件的形式產生，並傳遞至個別的遙測系統進行處理和分析。 遙測系統通常與任何特定應用程式或技術無關。

遙測系統會使用定義的架構來剖析資訊。 架構會指定合約，定義遙測系統可以擷取的數據欄位和類型。 將架構一般化，以允許從各種平臺和裝置抵達的數據。 常見的架構應包含與所有檢測事件相關的欄位，例如：

• 事件名稱。
• 事件時間。
• 寄件者的IP位址。
• 事件相互關聯所需的詳細數據，包括：
  • 使用者識別碼
  • 裝置識別碼
  • 應用程式識別碼

請記住，許多裝置可以針對相同的應用程式引發事件，因此架構不應該相依於裝置類型。 應用程式應該支援漫遊或跨裝置散發。 架構也可以包含特定案例的相關領域字段，這些案例在應用程式之間很常見，例如：

• 例外狀況的相關信息。
• 應用程式啟動和結束事件。
• Web 服務 API 呼叫的成功或失敗。

建立產生相同事件集的網域字段，以跨應用程式建置一組常見的報告和分析。 您可能需要設定架構，以包含自定義欄位，以擷取應用程式特定事件的詳細數據。

OpenTelemetry 是 API、SDK 和其他工具的廠商中性集合。 您可以使用 OpenTelemetry 來檢測應用程式，並以一致的方式跨語言產生有意義的遙測。 OpenTelemetry 與工具無關，因此它與許多可觀察性平臺相容，包括開放原始碼和商業供應專案。 Microsoft採用 OpenTelemetry 作為檢測的標準工具。

優化檢測程序代碼

下列清單摘要說明檢測在雲端中執行的分散式應用程式的最佳作法：

• 讓記錄易於讀取且易於剖析。 盡可能使用結構化記錄。

• 在記錄訊息中簡潔且描述性。

• 識別記錄檔的來源。

• 在寫入每個記錄檔記錄時新增時間戳資訊。

• 針對所有時間戳使用相同的時區和格式。

• 將記錄分類，並在適當的位置寫入訊息。

• 請勿顯示系統的相關敏感性資訊或用戶的個人資訊。 在記錄此資訊之前清除此資訊，但保留任何相關詳細數據。

• 記錄所有重大例外狀況，但可讓系統管理員視需要開啟和關閉記錄，以減少例外狀況和警告。

• 擷取並記錄所有重試邏輯資訊。 這項數據有助於監視系統的暫時性健康情況。

• 追蹤行程呼叫，例如對外部 Web 服務或資料庫的要求。

• 請勿將記錄訊息與相同記錄檔中不同的安全性需求混合在一起。

• 請確定所有記錄呼叫都是 不會封鎖商務作業進度的引發和忘記 作業。 排除此規則中的稽核事件，因為它們對企業至關重要。

• 請確定記錄是可延伸的，而且在具體目標上沒有任何直接相依性。

• 請確定所有記錄都安全無虞，而且不會觸發串聯錯誤。

• 將檢測視為持續反覆的程式，並定期檢閱記錄。

使用應用程式分析

• 只有在需要時才實作程式代碼剖析，因為它可能會對系統造成重大額外負荷。 藉由使用檢測，程式代碼剖析會在每次發生時記錄事件，例如方法呼叫。 不過，取樣只會記錄選取的事件。

• 分析選項可以是以時間為基礎的，例如每 n 秒一次，或以頻率為基礎，例如每 n 個要求一次。 如果事件經常發生，程式代碼剖析可能會對系統造成太多負擔，並影響整體效能。 在此情況下，最好使用取樣方法。 不過，如果事件的頻率很低，取樣可能會遺漏它們。 在此情況下，分析可能是更好的方法。

Azure 便利化

自動結構適用於使用Application Insights監視的許多 Azure 和內部部署應用程式類型。 自動結構函式會自動設定您的應用程式，以提供豐富的遙測給 Application Insights，並提供輕鬆存取體驗，例如 應用程式儀錶板 和 應用程式對應。 如需支援的裝載平臺和開發語言，請參閱 支援的環境、語言和資源提供者。

相關連結

• Application Insights 概觀
• 什麼是 Application Insights 的自動結構？
• Azure 監視器記錄概觀
• Azure 監視器計量概觀
• 收集 ETW 事件以分析 Azure 監視器記錄
• 設計及建立可檢視性架構的建議
• 什麼是分散式追蹤和遙測相互關聯？(部分機器翻譯)

社群連結

• OpenTelemetry

卓越營運檢查清單

請參閱一組完整的建議。