檢測應用程式的建議

適用于此 Azure Well-Architected Framework 營運卓越檢查清單建議：

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

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

主要設計策略

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

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

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

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

記錄和分散式追蹤記錄

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

如果應用程式使用 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

營運卓越檢查清單

請參閱一組完整的建議。