Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Surveillance

Utilisation des tableaux de bord

La surveillance de l'utilisation de la flotte est une activité régulière qui peut être effectuée au moyen de CloudWatch métriques et de la création d'un tableau de bord. Vous pouvez également utiliser l'onglet Fleet Usage depuis la console AppStream 2.0. Surveillez régulièrement l'utilisation de votre flotte, car le comportement des utilisateurs n'est pas toujours prévisible et la demande peut même dépasser une planification initiale de premier ordre. Une liste complète des métriques et des dimensions AppStream 2.0 se CloudWatch trouve dans le guide d'administration AppStream 2.0 sous Monitoring Resources.

Anticiper la croissance

Chaque fois qu'il y a un saut importantPendingCapacity, un événement de mise à l'échelle automatique se produit. Il est important de le confirmer AvailableCapacity et d'établir PendingCapacity une relation inverse lorsque de nouvelles instances de flotte AppStream 2.0 seront disponibles pour héberger des sessions utilisateur. Créez une CloudWatch alarme InsufficientCapacityError pour chaque flotte AppStream 2.0 afin d'avertir les administrateurs afin de garantir que le dimensionnement automatique ne soit pas inférieur à la demande.

Si la demande dépasse la capacité et que les valeurs InsufficientCapacityError métriques sont courantes, envisagez d'augmenter la capacité minimale par le biais d'une politique de dimensionnement planifié pour le début de la journée de travail. En outre, adoptez une deuxième politique de dimensionnement planifié pour réduire la capacité minimale une fois la demande satisfaite. N'oubliez pas que la réduction de la valeur de la capacité minimale n'a aucune incidence sur les sessions existantes. La réduction de la capacité minimale avant la fin de la journée de travail permet efficacement à l'échelle de fonctionner comme prévu en abaissant la valeur deActualCapacity. Cela permet d'optimiser les coûts.

Si la demande est constamment imprévisible, utilisez la politique de dimensionnement de Target Tracking pour vous assurer que le parc AppStream 2.0 est suffisant AvailableCapacity pour répondre à la demande tout en déterminant les modèles d'utilisation. Continuez à surveiller car Target Tracking utilise un pourcentage de la consommation du parc. À mesure que le nombre total d'instances de flotte augmente, le nombre total d'instances de flotte inutilisées se multiplie. Cela peut devenir inutile à moins que la capacité maximale ne soit fixée à une valeur prudente. Utilisez plusieurs types de politiques de dimensionnement (par exemple, le suivi planifié et le suivi des cibles) pour trouver un équilibre entre fiabilité et optimisation des coûts.

Surveillance de l'utilisation par les utilisateurs

Surveillance des utilisateurs uniques, car cela entraîne un coût sous forme de frais d'utilisation. Ces frais d'utilisation sont dus aux licences d'accès aux abonnés (SAL) d'Image Assistant (RDS). L'évaluation des utilisateurs uniques peut être effectuée soit par le biais de rapports provenant de l'IdP où l'authentification est effectuée, soit par le biais de rapports d'utilisation.

Les rapports d'utilisation sont stockés sous forme de .csv fichiers séparés dans votre compartiment S3, que vous pouvez télécharger et analyser à l'aide d'outils de business intelligence (BI) tiers. Vous pouvez analyser vos données d'utilisation AWS sans télécharger vos rapports ou créer des rapports sur des plages de dates personnalisées sans concaténer plusieurs fichiers. .csv Par exemple, vous pouvez utiliser Amazon Athena et Amazon QuickSight pour créer des rapports et des visualisations personnalisés de vos données d'utilisation AppStream 2.0.

Journaux d'événements persistants des applications et Windows

Lorsqu'une session d'instance AppStream 2.0 est terminée, l'instance est terminée. Cela signifie que tous les journaux d'événements d'applications et de Windows utilisés pendant la session sont perdus. S'il est nécessaire de conserver ces journaux d'événements d'applications et de Windows, l'une des méthodes consiste à utiliser Amazon Data Firehose pour les transmettre en temps réel à S3 et à effectuer une recherche avec Amazon OpenSearch Service (OpenSearch Service). Si les requêtes ne devraient pas être fréquentes, pour optimiser les coûts, utilisez Amazon Athena pour effectuer des recherches plutôt que d'exécuter Amazon OpenSearch Service.

Réseau d'audit et activité administrative

Si ce n'est pas déjà fait, il est recommandé AWS CloudTrailde le configurer Compte AWS avec Amazon AppStream 2.0. Pour auditer spécifiquement les appels d'API AppStream 2.0, utilisez la source d'événements du filtre avec une valeur deappstream.amazonaws.com.

Activez les journaux de flux VPC pour auditer l'accès aux ressources gérées par le client. Les journaux de flux VPC peuvent être publiés dans CloudWatch Logs pour effectuer des requêtes lorsqu'un audit est requis.

La surveillance de l'allocation IP des sous-réseaux est importante à mesure que les flottes AppStream 2.0 se développent. Créez un rapport sur l'attribution des adresses IP en exécutant la CLI describe-subnets pour signaler les adresses IP disponibles dans chaque sous-réseau attribué aux flottes. Assurez-vous que votre entreprise dispose d'une capacité d'adresses IP suffisante pour répondre à la demande de toutes les flottes fonctionnant à pleine capacité.