# PERF 7  您如何監控資源來確保達成預期效能？
<a name="w2aac19c11b9b5"></a>

 系統效能可能會隨時間降低。監控系統效能以識別效能降低情況，並修復內部或外部因素，如作業系統或應用程式負載。 

**Topics**
+ [PERF07-BP01 記錄效能相關指標](perf_monitor_instances_post_launch_record_metrics.md)
+ [PERF07-BP02 分析事件或事故發生時的指標](perf_monitor_instances_post_launch_review_metrics.md)
+ [PERF07-BP03 建立用於測量工作負載效能的關鍵績效指標 (KPI)](perf_monitor_instances_post_launch_establish_kpi.md)
+ [PERF07-BP04 使用監控來產生警示型通知](perf_monitor_instances_post_launch_generate_alarms.md)
+ [PERF07-BP05 定期審查指標](perf_monitor_instances_post_launch_review_metrics_collected.md)
+ [PERF07-BP06 主動監控和警示](perf_monitor_instances_post_launch_proactive.md)

# PERF07-BP01 記錄效能相關指標
<a name="perf_monitor_instances_post_launch_record_metrics"></a>

 使用監控和可觀察性服務來記錄效能相關指標。指標範例包括記錄資料庫交易、慢速查詢、I/O 延遲、HTTP 請求輸送量、服務延遲或其他關鍵資料。 

 確定對您的工作負載重要的效能指標並進行記錄。此資料是能夠識別哪些元件會影響整體效能或工作負載效率的重要部分。 

 從客戶體驗出發，確定重要指標。對於每個指標，確定目標、測量方法和優先級。使用它們來建置警示和通知，以主動解決與效能相關的問題。 

 **常用的反模式：** 
+  您只需監控作業系統層級指標，以深入了解工作負載。 
+  您會架構運算需求，以滿足尖峰工作負載要求。 

 **建立此最佳實務的優勢：** 若要最佳化效能和資源利用率，您需要取得關鍵績效指標的整合操作檢視。您可以建立儀表板，並對資料進行指標計算，以獲得操作和使用率的洞見。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>

 確定與您的工作負載相關的效能指標並進行記錄。此資料有助於識別哪些元件會影響整體效能或工作負載效率。 

 識別效能指標：使用客戶體驗來識別最重要的指標。對於每個指標，確定目標、測量方法和優先級。使用這些資料點來建置警示和通知，以主動解決與效能相關的問題。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [CloudWatch 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray 文件](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 

 **相關影片：** 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0) 
+  [AWS 上的應用程式效能管理](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 
+  [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 **相關範例：** 
+  [Level 100：使用 CloudWatch 儀表板進行監控](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [Level 100：使用 CloudWatch 儀表板監控 Windows EC2 執行個體](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/) 
+  [Level 100：使用 CloudWatch 儀表板監控 Amazon Linux EC2 執行個體](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/) 

# PERF07-BP02 分析事件或事故發生時的指標
<a name="perf_monitor_instances_post_launch_review_metrics"></a>

 為回應事件或事故 (或在事件或事故期間)，使用監控儀表板或報告來了解和診斷影響。這些檢視可讓您深入了解工作負載的哪些部分未如預期執行。 

 在為架構編寫關鍵使用者案例時，應包括效能需求，例如指定每個關鍵案例應執行的速度。對於這些關鍵案例，實作額外執行指令碼的使用者旅程，以確保您了解這些案例會如何根據您的要求予以執行。 

 **常用的反模式：** 
+  您假設效能事件是一次性問題，而且只與異常有關。 
+  只有在回應效能事件時，才會評估現有效能指標。 

 **建立此最佳實務的優勢：** 在判斷工作負載是否如預期效能運作時，您必須收集其他指標資料來分析，以回應效能事件。此資料用於了解效能事件的影響，並建議提升工作負載效能的變更。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>

 優先考慮關鍵使用者案例的體驗問題：在為架構編寫關鍵使用者案例時，應包括效能需求，例如指定每個關鍵案例應執行的速度。對於這些關鍵案例，實作額外執行指令碼的使用者之旅，以確保您了解這些使用者案例會如何根據您的要求予以執行。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [CloudWatch 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray 文件](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **相關影片：** 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0) 
+  [透過 Amazon CloudWatch RUM 優化應用程式](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Amazon CloudWatch Synthetics 的示範](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **相關範例：** 
+  [使用 Amazon CloudWatch Synthetics 測量頁面載入時間](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web 用戶端](https://github.com/aws-observability/aws-rum-web) 

# PERF07-BP03 建立用於測量工作負載效能的關鍵績效指標 (KPI)
<a name="perf_monitor_instances_post_launch_establish_kpi"></a>

 識別定量和定性衡量工作負載效能的 KPI。KPI 有助於測量工作負載的運作狀態，因為其與業務目標相關。KPI 允許業務和工程團隊在衡量目標和策略時，以及如何將其結合以產生業務成果方面保持一致。當業務目標、策略或最終使用者要求變更時，應該重新檢視 KPI。   

 例如，網站工作負載可能使用頁面載入時間，做為整體效能的指示。此指標將是衡量最終使用者體驗的多個資料點之一。除了識別頁面載入時間閾值外，您還應該記錄未符合效能時預期的成果或業務風險。頁面載入時間若很長，將會直接影響您的最終使用者、降低其使用者體驗評分，並可能導致客戶流失。當您定義 KPI 閾值時，請同時結合業界基準和最終使用者期望。例如，如果目前業界基準是網頁在兩秒內載入，但您的最終使用者期望網頁在一秒內載入，則您在建立 KPI 時應將這兩個資料點列入考慮。另一個 KPI 範例可能專注於符合內部效能需求。可能根據在產生了生產資料後的一個工作日內產生銷售報告來建立 KPI 閾值。這些報告可能直接影響每日決策和業務成果。  

 **預期成果：** 建立 KPI 涉及不同的部門和利害關係人。您的團隊必須使用即時精密資料和歷史資料來評估您的工作負載 KPI，以供參考，並建立儀表板，針對您的 KPI 資料執行指標數學，以衍生營運和使用率見解。KPI 應該加以記錄，說明已同意支援業務目標和策略的 KPI 和閾值，以及對應到受監控的指標。KPI 會識別效能要求，刻意進行審查，以及經常與所有團隊分享並使其理解。清楚地識別風險和取捨，並了解未符合 KPI 閾值時業務會受到何種影響。 

 **常用的反模式：** 
+  您只監控系統層級指標，以洞悉工作負載，但不了解對這些指標的業務影響。 
+  您假設 KPI 已發佈，並做為標準指標資料分享。 
+  定義 KPI 但未與所有團隊分享它們。 
+  未定義一個量化的可衡量 KPI。 
+  未使 KPI 與業務目標或策略保持一致。 

 

 **建立此最佳實務的優勢：** 識別代表工作負載運作狀態的特定指標有助於使團隊在其優先事項上保持一致，並定義成功的業務成果。與所有部門分享這些指標可對閾值、期望和業務影響提供可見性和一致性。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>

 受工作負載運成狀態影響的所有部門和業務團隊都應為定義 KPI 做出貢獻。單一人員應該推動協同合作、時間軸、文件，以及與組織 KPI 相關的資訊。這個單一執行緒擁有者通常會分享業務目標和策略，並指派利害關係人任務，在其各自部門中建立 KPI。一旦定義了 KPI，營運團隊通常就會協助定義將支援和告知不同 KPI 成功的指標。僅當支援工作負載的所有團隊成員都意識到 KPI 時，KPI 才有效。 

 **實作步驟** 

1.  識別並記錄利害關係人。 

1.  識別公司目標和策略。 

1.  審查符合貴公司目標和策略的常見業界 KPI。 

1.  審查工作負載的最終使用者期望。 

1.  定義並記錄支援公司目標和策略的 KPI。 

1.  識別並記錄核准的取捨策略以符合 KPI。 

1.  識別並記錄將告知 KPI 的指標。 

1.  識別並記錄嚴重性或警示等級的 KPI 閾值。 

1.  識別並記錄未符合 KPI 時的風險和影響。 

1.  識別每個 KPI 的審查頻率。 

1.  與支援工作負載的所有團隊交流 KPI 文件。 

** 實作指引的工作量：** 定義和交流 KPI 是 *低* 工作量。這通常可以透過在幾週內與業務利害關係人會面、審查目標、策略和工作負載指標來完成。

## 資源
<a name="resources"></a>

 **相關文件：** 
+ [CloudWatch 文件 ](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+ [X-Ray 文件 ](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html?ref=wellarchitected) 
+  [Quick KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) 

 **相關影片：** 
+  [AWS re:Invent 2019：擴充至首個 1,000 萬名使用者 (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected) 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected) 
+  [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 

 **相關範例：** 
+  [使用 Quick 建立儀表板](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 

# PERF07-BP04 使用監控來產生警示型通知
<a name="perf_monitor_instances_post_launch_generate_alarms"></a>

 使用監控系統和您定義的效能相關關鍵績效指標 (KPI)，當這些測量結果超出預期範圍時自動產生警示。 

 Amazon CloudWatch 可以收集架構中各種資源的指標。您還可以收集和發佈自訂指標以顯示業務或衍生指標。使用 CloudWatch 或第三方監控服務來設定警示，以在超過閾值時進行指示 — 指標超出預期邊界時發出警示。 

 **常用的反模式：** 
+  您需要靠員工監控指標，並在他們發現問題時做出反應。 
+  當可以觸發無伺服器工作流程來完成相同的任務時，您僅倚賴操作執行手冊作業。 

 **建立此最佳實務的優勢：** 您可以根據預先定義的閾值或機器學習演算法，來設定提醒並自動化動作，確定指標中的異常行為。這些警示也可以觸發無伺服器的工作流程，藉以修改工作負載的效能特性 (例如，增加運算容量、修改資料庫組態)。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>

 監控指標：Amazon CloudWatch 可以收集架構中各種資源的指標。您可以收集和發佈自訂指標以顯示業務或衍生指標。使用 CloudWatch 或第三方監控服務設定警示，藉以指出何時超出閾值。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [CloudWatch 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray 文件](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [使用 CloudWatch 中的警示和警示動作](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html) 

 **相關影片：** 
+  [AWS re:Invent 2019：擴充至首個 1,000 萬名使用者 (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected) 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected) 
+  [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 
+  [搭配 Amazon CloudWatch Events 使用 AWS Lambda](https://www.youtube.com/watch?v=WDBD3JmpLqs) 

 **相關範例：** 
+  [Cloudwatch Logs 自訂警示](https://github.com/awslabs/cloudwatch-logs-customize-alarms) 

# PERF07-BP05 定期審查指標
<a name="perf_monitor_instances_post_launch_review_metrics_collected"></a>

 作為日常維護或對事件或事故的回應，審查收集了哪些指標。透過這些審查來確定哪些指標是解決問題的關鍵，以及哪些其他指標 (如果被追蹤) 將有助於識別、解決或預防問題。 

 作為對事故或事件的回應的一部分，評估哪些指標有助於解決問題，哪些指標可以幫助解決問題但未被追蹤。使用此方法提高所收集指標的品質，從而可以防止事故發生或更快地解決將來的事故。 

 **常用的反模式：** 
+  您讓指標長時間持續處於警示狀態。 
+  您建立自動化系統無法採取行動的警示。 

 **建立此最佳實務的優勢：** 持續審查正在收集的指標，以確保指標正確識別、處理或防止問題發生。如果讓指標長時間持續處於警示狀態，指標也會變得過時。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>

 不斷改進指標收集和監控：作為對事故或事件的回應的一部分，評估哪些指標有助於解決問題，哪些指標可以幫助解決問題但未被追蹤。使用此方法提高所收集指標的品質，從而可以防止事故發生或更快地解決將來的事故。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [CloudWatch 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray 文件](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **相關影片：** 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0) 
+  [AWS 上的應用程式效能管理](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 
+  [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 **相關範例：** 
+  [使用 Quick 建立儀表板](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 
+  [Level 100：使用 CloudWatch 儀表板進行監控](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 

# PERF07-BP06 主動監控和警示
<a name="perf_monitor_instances_post_launch_proactive"></a>

 使用關鍵績效指標 (KPI) 搭配監控和提醒系統，主動處理效能相關的問題。使用警示觸發自動化動作，盡可能修復問題。如果無法自動回應，則將警示上報給能夠回應的人員。例如，您可能有一個可以預測關鍵績效指標 (KPI) 預期值並在超過特定閾值時發出警示的系統，或者在 KPI 超出預期值時可以自動停止或回復部署的工具。 

 實作可在工作負載執行時提供效能可見度的程序。建置監控儀表板並建立效能預期的基準規範，以確定工作負載是否以最佳狀態執行。 

 **常用的反模式：** 
+  您只讓操作人員有能力對工作負載進行操作變更。 
+  您讓所有警示篩選到操作團隊，無須主動修復。 

 **建立此最佳實務的優勢：** 主動修復警示動作能夠讓支援人員專注在無法自動採取行動的項目上。如此可確保操作人員不會負荷所有警報，而僅專注於關鍵警報。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>

 在營運過程中監控效能：實作可在工作負載執行時提供效能可見度的程序。建立監控儀表板，並建立效能期望的基準。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [CloudWatch 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [監控、記錄和效能 APN 合作夥伴](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray 文件](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [使用 CloudWatch 中的警示和警示動作](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html) 

 **相關影片：** 
+  [突破混沌的難題：掌握運作相關的情況和洞見 (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0) 
+  [AWS 上的應用程式效能管理](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 
+  [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 
+  [搭配 Amazon CloudWatch Events 使用 AWS Lambda](https://www.youtube.com/watch?v=WDBD3JmpLqs) 

 **相關範例：** 
+  [Cloudwatch Logs 自訂警示](https://github.com/awslabs/cloudwatch-logs-customize-alarms)