监控

使用控制面板

监控车队利用率是一项常规活动，可以通过 CloudWatch 指标和创建仪表板来执行。或者，在 AppStream 2.0 控制台中，使用 “队列使用情况” 选项卡。请定期监控实例集使用情况，因为用户行为并不总是可以预测的，而且即使提前规划准备得再充分，需求也可能会超出预期。 AppStream 2.0 指标和维度的完整列表 CloudWatch 可在 AppStream 2.0 管理指南的 “监控资源” 下找到。

预期增长

每当 PendingCapacity 出现大幅激增时，就会发生自动扩缩事件。当新的 AppStream 2.0 队列实例可供托管用户会话使用时，确认这一点AvailableCapacity并PendingCapacity保持反向关系非常重要。InsufficientCapacityError为每个 AppStream 2.0 队列创建 CloudWatch 警报，通知管理员确保自动扩展不会落后于需求。

如果需求超过容量并且 InsufficientCapacityError 指标值很常见，请考虑在工作日开始时通过计划扩缩策略提高最小容量。此外，还要制定第二个计划扩缩策略，以便在需求得到满足后降低最小容量。请记住，降低最小容量的值不会影响现有会话。在工作日结束之前降低最小容量可以通过降低 ActualCapacity 值来按预期进行有效扩缩。这样可以优化成本。

如果需求始终不可预测，请使用 Target Tracking 扩展策略来确保 AppStream 2.0 队列AvailableCapacity中有足够的容量来满足需求，同时确定使用模式。继续监控，因为目标跟踪跟踪的是实例集消耗的百分比。随着实例集实例总数的增长，未使用的实例集实例总数会成倍增加。除非将最大容量设置为保守值，否则这可能会造成浪费。使用多种类型的扩缩策略（例如，计划和目标跟踪）以实现可靠性与成本优化之间的平衡。

监控用户使用情况

监控唯一用户，因为用户需要根据使用情况付费。这笔用户费用是 Image Assistant (RDS) 订阅者访问许可证 (SAL) 的费用。可以通过执行身份验证的 IdP 的报告或使用情况报告来评估唯一用户。

使用情况报告作为单独 .csv 的文件存储在 S3 存储桶中，您可以下载并使用第三方商业智能 (BI) 工具分析这些报告。您 AWS 无需下载报告即可在中分析使用数据，也可以在自定义日期范围内创建报告，而无需连接多个文件。.csv例如，您可以使用 Amazon Athena 和 Amaz QuickSight on 来创建 2.0 使用情况数据的自定义报告和可视 AppStream 化效果。

保留应用程序和 Windows 事件日志

AppStream 2.0 实例会话完成后，实例即告结束。这意味着会话中使用的所有应用程序和 Windows 事件日志都将丢失。如果需要保留这些应用程序和 Windows 事件日志，一种方法是使用 Amazon Data Firehose 将它们实时传输到 S3，然后使用亚马逊 OpenSearch 服务（OpenSearch 服务）进行搜索。如果预计查询不会很频繁，为了优化成本，请使用 Amazon Athena 进行搜索，而不是运行亚马逊服务。 OpenSearch

审计网络和管理活动

如果尚未设置，则最好使用 Amazon AppStream 2.0 AWS CloudTrail进行配置。 AWS 账户 要专门审计 AppStream 2.0 API 调用，请使用值为的过滤器事件源appstream.amazonaws.com。

启用 VPC 流日志可审计对客户管理的资源的访问权限。VPC 流日志可以发布到 CloudWatch 日志，以便在需要审计时执行查询。

随着 AppStream 2.0 队列的增长，监控子网 IP 分配非常重要。通过运行 describe-subnets CLI 报告分配给实例集的每个子网中的可用 IP 地址，来报告 IP 分配。确保您的组织有足够的 IP 地址容量，来满足所有以最大容量运行的实例集的需求。