Skip to main content
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

了解 Workload Factory for EDA 中的延遲監控

貢獻者 netapp-sineadd

Workload Factory for EDA 中的延遲監控功能可協助您尋找並修正 FSx for ONTAP 磁碟區中的效能下降問題。它使用 CloudWatch 指標追蹤讀取和寫入延遲,並自動分析資料,以協助識別效能問題的根本原因。

延遲監控的運作方式

延遲分析會收集連接到您的 AWS 帳戶的所有 FSx for ONTAP 磁碟區的讀寫活動 CloudWatch 指標。它會持續根據定義的限制檢查這些指標,以便及早偵測效能問題。

如果延遲上升,Workload Factory 會自動檢查 ONTAP QoS 延遲指標,以識別導致速度下降的主要原因。對於涉及資料或叢集元件的更複雜問題,您可以執行選用的 AI 分析,該分析會提供可能的根本原因、識別受影響的用戶端,並建議解決問題的步驟。

警示產生

只有在整個選取時間範圍內同時符合以下條件時,才會觸發警示:延遲持續高於其閾值,且 IOPS 持續高於其閾值。同時要求兩個條件均成立,可確保高延遲發生於系統處理實際工作負載期間,從而減少誤報。

您可以為以下各項設定個別的臨界值:

  • 讀取作業

  • 寫入操作

  • 警告嚴重性

  • 嚴重嚴重性

所有偵測到的事件都會顯示在延遲事件表中。如果已設定通知,您也會收到一封電子郵件或 Amazon SNS 訊息,其中包含受影響磁碟區的詳細資訊。您可以控制接收通知的頻率——可以是每個檔案系統每天一次,也可以是每 20 分鐘一次。

了解警示

了解警示的觸發方式有助於您設定適當的臨界值並解讀結果。

收集的指標

系統會針對每個磁碟區收集以下 CloudWatch 指標:

  • 讀取延遲閾值:計算公式為 1000 * m2/(m1+0.000001),其中 m1 = DataReadOperations 且 m2 = DataReadOperationTime

  • 寫入延遲閾值:計算公式為 1000 * m2/(m1+0.000001),其中 m1 = DataWriteOperations 且 m2 = DataWriteOperationTime

警示觸發條件

當滿足以下所有條件時,就會觸發警示:

  • 操作類型 (讀取或寫入) 的延遲閾值已超過。

  • 該操作類型的 IOPS 閾值已超過。

  • 在設定的時間範圍內,所有資料點都符合這兩個條件。

例如,使用預設警告閾值,只有當 10 分鐘內所有資料點的讀取延遲超過 6 毫秒且讀取 IOPS 超過 100 ops/sec 時,才會觸發讀取警報。

事件嚴重性

  • 警告事件:表示延遲升高,可能需要注意

  • 關鍵事件:表示存在嚴重的延遲,需要立即調查

延遲分析

Workload Factory 提供兩層分析,協助您疑難排解延遲問題。

基本分析

當發生延遲事件時,Workload Factory 會自動執行基本分析來找出原因。它使用 ONTAP QoS 延遲中心指標來確定哪個元件導致速度下降,例如 FlexCache、容量集區、QoS 限制、磁碟、資料、叢集或其他子系統。這樣可以快速識別延遲來源,無需人工調查。

註 只有當連結與 FSx for ONTAP 檔案系統關聯時,才能查看元件細分。如果沒有連結,仍然可以查看延遲、IOPS 和處理量的圖表。
註 由於 ONTAP QoS 分析與 CloudWatch 採用不同的資料收集方式,因此其延遲值可能略有差異。基本分析使用 ONTAP 資料來識別根本原因。

AI 分析

雖然基礎分析可以識別延遲的根源,但涉及資料或叢集組件的更複雜情況通常需要更深入的調查。AI 分析能夠提供這種更深入的疑難排解,找出諸如磁碟區過載、配置不當或需要增加容量等問題——這些問題是基礎分析可能遺漏的。

執行 AI 分析時,系統會提供:

  • 潛在根本原因:詳細說明導致延遲問題的原因

  • 受影響的用戶端:受延遲影響的 EC2 執行個體名稱清單

  • 潛在的補救步驟:解決問題的兩個或多個特定動作

AI 分析需要在 Workload Factory 設定中設定 Amazon Bedrock 模型 ARN。如果未設定 Bedrock,您仍然可以使用延遲監控和基本自動化分析功能。