監控工作負載效能的架構策略

適用於此 Azure Well-Architected 架構效能效率檢查清單建議：

沒有效能資料，潛在問題與優化機會被忽視，導致使用者體驗下降。

本文說明設計策略，用於實作多層效能衡量，捕捉延遲、吞吐量與資源行為，建立基線並識別工作負載中的效能下降。

本文的關鍵策略建立在可觀察性（observability）這一基礎操作實務之上，該實務詳述於 OE：07 監控系統設計架構策略中。 有關實施監測實務的指引，請參閱 監測設計指南。 我們建議先檢視這些資源。 本指南中的建議範圍僅限於性能表現。 關於可靠性的資訊，請參閱 RE：10 架構策略以設計可靠的監控與警示策略。

定義

使用百分位數指標

用百分位數（p50、p95、p99）來衡量效能指標，例如延遲、回應時間或載入時間，而不是平均值。 平均值有時會誤導人。 如果大多數請求速度快但少數非常慢，平均值會掩蓋不良體驗。

百分位數顯示尾部行為，這對理解使用者體驗非常重要。 P50 代表典型效能，P95 顯示大多數使用者在負載下的體驗，P99 則反映最差效能或異常值。

利用你的監控工具收集績效數據，並以在定義時間窗內的百分位數表示。 這些作為你監控、警示與績效分析的基準。

明確你的績效改進界限

明確定義績效界限，讓你清楚知道測量中包含了哪些內容。 將延遲拆解到整個系統，而不是把它當成單一數字來處理。 例如，把時間歸因到每個層，這些層包括邊緣服務、閘道器、運算和相依，這樣就能了解實際發生的延遲。

將你控制的與無法控制的區分：你的程式碼、服務、基礎設施和直接相依關係，與外部因素如客戶端條件、DNS 解析、ISP 延遲或裝置限制區分開來。 這種區分防止誤歸，並使優化聚焦於可調整的部分，同時反映完整的端到端使用者體驗。

評估效能問題何時何地影響使用者體驗。 透過設計補償這些退化，或透過改善系統中可控部分來緩解。

依環境與用途分段訊號

將效能資料分割，使每個訊號反映清楚的脈絡。 依照環境和目的來區分，避免混淆行為不同或服務不同決策的訊號。

將生產資料與非生產資料分開。 生產資料反映真實使用者影響，應推動監控與警示。 非生產數據對測試和調整很有用，但混入生產環境會扭曲結果，並掩蓋真正的問題。

將績效指標與業務指標分開。 績效指標追蹤系統行為與工作負載健康狀況，而業務指標則追蹤成果。 即使它們有重疊，也要保持在獨立的流中，讓每個流都能被獨立分析和使用。

建立有明確範圍且可執行的績效警示

警示的目標是及早偵測效能下降，避免使用者可見或影響業務。 在兩個層級建立警示：端對端使用者體驗，以及代表系統負載下關鍵路徑的核心內部交易。

在每個環境中，針對目標和警示都使用單一且一致的資料集。 如果警示基於與效能目標不同的資料，它們就會變得不可靠且難以信任。

建立可執行且明確與績效結果相關的警示。 每則警示應指出持續違規的門檻、潛在影響及相關組件，讓調查地點與受影響範圍清晰。 從標準且眾所周知的閾值開始，然後根據觀察到的系統行為與工作負載特性逐步調整。

考慮在健康模型中建立績效警示。 與其針對單一指標發出警示，不如使用健康模型來表示多重績效訊號，來呈現對效能至關重要的資源。 健康狀態轉換時的警示，讓複合性效能問題能以單一可行動的警示形式浮現，而非一連串的門檻違規。 Azure 監視器 健康模型支援此模式，提供實體層級警示與跨相依的階層傳播。

當無法直接警示外部依賴時，使用間接訊號如依賴呼叫持續時間、錯誤率或逾時行為，來估算其對系統效能的影響。

監測彈性

衡量系統對需求變化與規模事件的反應。

追蹤冷啟動與初始化延遲，了解啟動開銷如何影響反應速度，尤其是在擴展事件期間。 監控擴展與擴展行為，評估系統對負載變化的適應速度，以及擴展行動是否能跟上需求。

賽道表現隨時間變化

追蹤性能如何隨著設計變化及外部因素演變。

建立代表預期系統效能的基線，然後將當前行為與之比較，以偵測漂移，包括迴歸與改善。

使用健康模型來表示效能基線，並清楚量化對效能關鍵資源的健康、退化與不健康狀態。 Azure 監視器 健康模型支援靜態閾值與動態基線，隨時間自動調整，自動化漂移偵測。

將效能變更與營運事件（如部署、組態更新及擴展動作）連結。 用這些事件註記時間軸，讓行為變化有明確的脈絡，並能追溯到可能的原因。

利用這種持續的可見性作為工程決策的反饋迴路。 將績效洞察納入規劃與優先排序，並將其視為日常工作的輸入，而非僅僅是事件應變。

隨著系統演進，持續精煉績效目標。 根據觀察到的行為與使用模式調整 SLO、門檻與期望，確保目標保持現實且符合實際使用者體驗。

收集應用程式效能數據

你需要透過儀器化程式碼收集應用程式的效能指標，例如吞吐量、延遲和完成時間。

在效能最明顯的關鍵執行路徑上進行監測：包括關鍵請求流程、資源密集型操作，以及外部相依或重試發生的點。 確保交易端到端的可視性，以便衡量總執行時間及其貢獻步驟。

捕捉三種核心績效訊號類型：

• 整合效能行為的指標（延遲分布、吞吐量、錯誤率）
• 用以理解時間如何分布於請求路徑與系統元件中的痕跡
• 日誌提供特定步驟或事件的詳細執行上下文

在這些訊號間使用一致的元資料，讓效能資料能在系統層級及服務間相互關聯。

除非需要更細緻的說明以解釋特定工作負載的行為或瓶頸，否則避免重複平台已暴露的低階效能訊號。

收集資源效能數據

收集資源層級的效能資料，以了解基礎設施元件在負載下的表現及其對整體工作負載效能的貢獻。

每個服務都會揭露平台專屬的指標，反映其健康狀況與效能特性。 使用 診斷設定 來匯出這些資料，使其可以被存取，用於警示、儀表板及長期分析，超越平台的短期資料保存期限。

收集所有資源的指標和日誌。 追蹤運算與儲存利用率與預期範圍，以確認配置不足是否造成延遲及負載效能下降。 透過這些資料，可以檢視 P99 使用量並與資源的可用容量進行比較，以偵測過剩配置。

監控網路流量，作為資源效能的一部分。 分析子網與服務邊界的流量，以了解可能影響工作負載效能的延遲、擁塞及資料傳輸模式。

收集資料庫和記憶體數據

資料庫與儲存系統會產生專門的效能訊號，用以識別瓶頸、驗證容量及理解工作負載行為。 這些訊號通常來自內建的監控工具和系統產生的日誌。

聚焦關鍵績效面向：

對於資料庫，將監控擴展到工作負載特定的行為：

結合這些訊號來區分查詢緩慢、資源飽和與結構性低效率。 這使得在儲存系統與資料庫工作負載間進行針對性優化。

收集作業系統效能資料

針對基礎架構工作負載，收集作業系統層級的指標，以了解運算資源的使用情況及資源限制可能出現的區域。

定期抽樣作業系統效能計數器，以捕捉系統在負載下的時間行為。

利用這些訊號識別作業系統層級的資源飽和，並區分應用程式層級的低效率與基礎架構限制。

必要時產生合成資料

如果你的系統沒有持續使用，很難判斷流量回來時是否能表現良好。

為了解決這個問題，可以使用合成交易，它會透過系統自動發送請求。 這些模擬真實使用，卻不影響實際使用者或資料。 這有助於保持系統部分運作，產生穩定的效能指標，並揭露不規則使用可能隱藏的模式（如時間問題）。

Azure 支援服務

Azure 監視器 提供一個統一平台，用於收集、分析及回應整個工作負載的效能資料。 它將應用程式、基礎設施及外部來源的資料彙整至一個共同的資料平台。

資料收集與儲存：利用 Log Analytics 工作區 集中管理績效資料，並可設定保留 政策。 建立多個工作區，依環境或合規要求分割資料。

健康建模：Azure 監視器健康模型 幫助您定義、衡量並視覺化工作負載健康，透過將指標、日誌與追蹤關聯到Azure資源與元件中可行的健康狀態。

應用程式監控： Application Insights 收集應用層級遙測資料，包括請求率、回應時間及例外。 啟用 分散式追蹤 ，以關聯分散元件間的效能。

基礎設施監控：啟用所有 Azure 服務 的診斷設定 ，以收集平台日誌與指標。 使用 Azure 診斷 擴充功能 來取得詳細的 VM 效能資料。 探索針對你特定平台的遙測選項。 例如，Kubernetes 叢集透過 Prometheus 整合輸出豐富的效能遙測。

資料庫與儲存：Azure 監視器 內建監控 Azure SQL 資料庫、MySQL、PostgreSQL 及儲存服務。 Azure 儲存體分析 追蹤 Blob、Table 和 Queue Storage 的吞吐量與延遲等關鍵績效指標。

警示與分析：建立可自訂的警示規則，包含可自訂的門檻、時間窗和動作（電子郵件、webhooks、Azure 函式）。 使用 Azure 監視器 Logs 來交叉查詢並關聯效能資料。 如需定價詳細數據，請參閱 Azure 監視器定價。

Examples

• 基準高可用性區域備援應用程式服務 Web 應用程式
• 在 Azure Kubernetes Service 中監視微服務應用程式 （AKS）
• 監控 Azure 平台登陸區域組件

相關連結

• 平台計量
• 診斷設定
• 稽核記錄

效能效益檢查清單

請參閱一組完整的建議。