監控

使用儀表板

監控叢集使用率是一種常規活動，可透過 CloudWatch 指標執行並建立儀表板。或者，從 AppStream 2.0 主控台，使用 [叢集使用量] 索引標籤。定期監控您的車隊使用情況，因為使用者行為並不總是可預測，而且需求甚至可能超過一流的前期規劃。 CloudWatch 您可以在監控資源下的 AppStream 2.0 管理指南中找到 AppStream 2.0 個指標和維度的完整清單。

預期增長

每當有一個大的跳躍PendingCapacity，就會發生 auto 縮放事件。請務必確認AvailableCapacity並PendingCapacity具有反向關係，同時新的 AppStream 2.0 叢集執行個體可供託管使用者工作階段使用。為每個 AppStream 2.0 叢集建立 CloudWatch 警示，以通知管理員，以確保自動調整規模不會落後InsufficientCapacityError於需求。

如果需求超過容量且InsufficientCapacityError測量結果值很常見，請考慮透過「排程擴展」政策在工作日開始時提高最小容量。此外，使用第二個「排程擴展」政策，以便在滿足需求後降低最小容量。請記住，降低最小容量的值不會影響現有的工作階段。在工作日結束之前降低最小容量，可以透過降低的值來有效地擴展功能ActualCapacity。這樣可以最佳化成本。

如果需求始終無法預測，請使用 Target Tracking 擴展政策來確保 AppStream 2.0 叢集AvailableCapacity中有足夠的滿足需求，同時確定使用模式。繼續監控，因為目標追蹤使用的叢集耗用量百分比。隨著叢集執行個體總數的增加，未使用的叢集執行個體總數會相乘。除非將最大容量設置為保守值，否則這可能會變得浪費。使用多種類型的擴展政策 (例如「排程」和「目標追蹤」)，在可靠性與成本最佳化之間取得平衡。

監控使用者使用

監控獨特的用戶，因為有相關的成本，在用戶費的形式。此使用者費用是由影像助理 (RDS) 使用者存取授權 (SAL) 所產生的。評估唯一使用者可透過執行驗證的 IdP 報告，或透過使用情況報告來執行。

使用情況報告會以個別.csv檔案形式存放在 S3 儲存貯體中，您可以使用第三方商業智慧 (BI) 工具下載和分析這些檔案。您可以在中分析使用情況資料， AWS 而無需下載報告，也可以在自訂日期範圍內建立報告，而無需串連多個.csv檔案。例如，您可以使用 Amazon Athena 和 Amazon QuickSight 為 AppStream 2.0 使用量資料建立自訂報告和視覺效果。

保存應用程式和 Windows 事件記錄檔

當 AppStream 2.0 執行個體工作階段完成時，執行個體就會結束。這表示工作階段中使用的所有應用程式和 Windows 事件記錄檔都會遺失。如果需要保留這些應用程式和 Windows 事件日誌，其中一種方法是使用 Amazon 資料 Firehose 將它們即時交付到 S3，並使用 Amazon OpenSearch 服務 (服OpenSearch 務) 進行搜尋。如果預計不會頻繁查詢，為了優化成本，請使用 Amazon Athena 進行搜索，而不是運行 Amazon OpenSearch 服務。

稽核網路與行政活動

如果尚未設定，最佳做法是 AWS 帳戶 使用 Amazon AppStream 2.0 AWS CloudTrail進行配置。若要特別稽核 AppStream 2.0 API 呼叫，請使用值為的篩選器事件來源appstream.amazonaws.com。

啟用 VPC 流程記錄，以稽核對客戶管理資源的存取。VPC 流程記錄可以發佈至 CloudWatch 記錄檔，以便在需要稽核時執行查詢。

隨著 AppStream 2.0 個叢集的成長，監控子網路 IP 配置非常重要。透過執行描述子網路 CLI 來報告指派給叢集的每個子網路中可用的 IP 位址，以報告 IP 指派。確保您的組織擁有足夠的 IP 位址容量，以滿足以最大容量執行的所有叢集的需求。