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
La surveillance consiste à collecter différentes métriques, telles que le processeur et la mémoire, et à les stocker dans une base de données chronologique telle qu'Amazon Managed Service for Prometheus. Le système de surveillance peut être basé sur le push ou le pull. Dans les systèmes basés sur le push, la source envoie régulièrement des métriques à la base de données de séries chronologiques. Dans les systèmes basés sur le pull, le scraper extrait les métriques de diverses sources et les stocke dans la base de données de séries chronologiques. Les développeurs peuvent analyser les indicateurs, les filtrer et les tracer au fil du temps pour visualiser les performances. La mise en œuvre réussie de la surveillance peut être divisée en deux grands domaines : l'application et l'infrastructure.
Pour les développeurs d'applications, les indicateurs suivants sont essentiels :
-
Latence : temps nécessaire pour recevoir une réponse
-
Débit de demandes : nombre total de demandes traitées par seconde
-
Taux d'erreur des demandes : nombre total d'erreurs
Capturez l'utilisation des ressources, la saturation et le nombre d'erreurs pour chaque ressource (telle que le conteneur d'applications, la base de données) impliquée dans la transaction commerciale. Par exemple, lorsque vous surveillez l'utilisation du processeur, vous pouvez suivre l'utilisation moyenne du processeur, la charge moyenne et la charge maximale pendant l'exécution des tests de performances. Lorsqu'une ressource atteint la saturation lors d'un test de stress, mais qu'elle risque de ne pas atteindre la saturation pendant une période plus courte pendant une période plus courte.
Métriques
Les applications peuvent utiliser différents actionneurs, tels que des actionneurs à ressort, pour surveiller leurs applications. Ces bibliothèques de production exposent généralement un point de terminaison REST pour surveiller les informations relatives aux applications en cours d'exécution. Les bibliothèques peuvent surveiller l'infrastructure sous-jacente, les plateformes d'applications et les autres ressources. Si l'une des métriques par défaut ne répond pas aux exigences, le développeur doit implémenter des métriques personnalisées. Les métriques personnalisées peuvent aider à suivre les indicateurs clés de performance (KPI) commerciaux qui ne peuvent pas être suivis à l'aide des données issues des implémentations par défaut. Par exemple, vous souhaiterez peut-être suivre une opération commerciale telle que la latence d'intégration d'API tierces ou le nombre total de transactions effectuées.
Cardinalité
La cardinalité fait référence au nombre de séries chronologiques uniques d'une métrique. Les métriques sont étiquetées pour fournir des informations supplémentaires. Par exemple, une application basée sur REST qui suit le nombre de demandes pour une API particulière indique une cardinalité de 1. Si vous ajoutez une étiquette utilisateur pour identifier le nombre de demandes par utilisateur, la cardinalité augmente proportionnellement au nombre d'utilisateurs. En ajoutant des étiquettes qui créent une cardinalité, vous pouvez découper et découper les métriques en différents groupes. Il est important d'utiliser les bonnes étiquettes pour le bon cas d'utilisation, car la cardinalité augmente le nombre de séries de mesures dans la base de données de séries chronologiques de surveillance du backend.
Résolution
Dans une configuration de surveillance classique, l'application de surveillance est configurée pour extraire périodiquement les métriques de l'application. La périodicité du scraping définit la granularité des données de surveillance. Les mesures collectées à des intervalles plus courts ont tendance à fournir une vision plus précise des performances, car davantage de points de données sont disponibles. Toutefois, la charge sur la base de données de séries chronologiques augmente à mesure que de nouvelles entrées sont stockées. Généralement, une granularité de 60 secondes correspond à une résolution standard et de 1 seconde à une résolution élevée.
DevOps équipe
Les développeurs d'applications demandent souvent aux DevOps ingénieurs de mettre en place un environnement de surveillance pour visualiser les métriques de l'infrastructure et des applications. L' DevOps ingénieur doit mettre en place un environnement évolutif prenant en charge les outils de visualisation des données utilisés par le développeur de l'application. Cela implique de récupérer les données de surveillance provenant de différentes sources et de les envoyer à une base de données chronologique centrale telle qu'Amazon Managed Service for Prometheus.
Backend de surveillance
Un service principal de surveillance prend en charge la collecte, le stockage, l'interrogation et la visualisation des données métriques. Il s'agit généralement d'une base de données chronologique telle qu'Amazon Managed Service for InfluxData Prometheus ou InfluxDB. À l'aide d'un mécanisme de découverte des services, le collecteur de surveillance peut collecter des métriques provenant de différentes sources et les stocker. Lors des tests de performance, il est important de stocker les données des métriques afin de pouvoir les rechercher ultérieurement. Nous vous recommandons de sauvegarder au moins 15 jours de données pour les métriques. Cependant, le stockage des métriques sur une plus longue durée n'apporte pas d'avantages significatifs et entraîne des coûts de stockage inutiles. Étant donné que le test de performance peut générer un grand nombre de métriques, il est important que l'infrastructure de métriques soit évolutive tout en fournissant des performances de requête rapides. Le service principal de surveillance fournit un langage de requête qui peut être utilisé pour afficher les données des métriques.
Visualisation
Fournissez des outils de visualisation capables d'afficher les données de l'application afin de fournir des informations pertinentes. L' DevOps ingénieur et le développeur de l'application doivent apprendre le langage de requête pour le backend de surveillance et travailler en étroite collaboration pour générer un modèle de tableau de bord réutilisable. Dans les tableaux de bord, incluez la latence et les erreurs, tout en affichant l'utilisation et la saturation des ressources de l'infrastructure et des applications.
Automatisation de l'infrastructure de surveillance
À l'instar de la journalisation, il est important d'automatiser l'installation et le fonctionnement de l'infrastructure de surveillance afin de répondre aux différentes exigences des différentes applications. Utilisez les outils IaC pour approvisionner le backend de l'infrastructure de surveillance. Vous pouvez ensuite fournir l'infrastructure de surveillance sous la forme d'un service partagé ou d'un déploiement indépendant sur mesure pour une application particulière.
Utilisez des pipelines de CD pour automatiser les opérations suivantes :
-
Déployez l'infrastructure de surveillance à la demande et démolissez-la lorsqu'elle n'est pas nécessaire.
-
Mettez à jour la configuration de surveillance pour filtrer ou agréger les métriques.
-
Déployez des tableaux de bord d'applications.
Outils de surveillance
Amazon Managed Service for Prometheus est un service de surveillance compatible avec Prometheus
Amazon CloudWatch fournit une surveillance complète du stack sur. AWS CloudWatch prend en charge les solutions AWS natives et open source afin que vous puissiez comprendre à tout moment ce qui se passe dans votre infrastructure technologique.
Les AWS outils natifs sont les suivants :
Amazon CloudWatch propose des fonctionnalités spécialement conçues pour répondre à des cas d'utilisation spécifiques tels que la surveillance des conteneurs via CloudWatch Container Insights. Ces fonctionnalités sont intégrées CloudWatch afin que vous puissiez configurer les journaux, la collecte de métriques et la surveillance.
Pour vos applications conteneurisées et vos microservices, utilisez Container Insights pour collecter, agréger et résumer les métriques et les journaux. Container Insights est disponible pour les plateformes Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) et Kubernetes sur Amazon Elastic Compute Cloud (Amazon EC2). Container Insights collecte des données sous forme d'événements du journal des performances au format métrique intégré. Ces entrées d'événements du journal des performances utilisent un schéma JSON structuré qui prend en charge l'ingestion et le stockage de données à haute cardinalité à grande échelle.
Pour plus d'informations sur la mise en œuvre de Container Insights avec Amazon EKS, consultez le billet de blog Présentation d'Amazon CloudWatch Container Insights for Amazon EKS Fargate using Distro AWS
