Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à cette recommandation de liste de contrôle d’efficacité des performances d’Azure Well-Architected Framework :
| PE :04 | Établissez une mesure cohérente des performances afin que le comportement puisse être analysé au fil du temps, comparé aux lignes de base et utilisé pour détecter la dégradation, l’inefficacité et les lacunes de mise à l’échelle. |
|---|
Sans données de performances, les problèmes sous-jacents et les opportunités d’optimisation passent inaperçues, ce qui entraîne une dégradation de l’expérience utilisateur.
Cet article décrit les stratégies de conception permettant d’implémenter des mesures de performances multicouches qui capturent la latence, le débit et le comportement des ressources pour établir des lignes de base et identifier la dégradation des performances dans la charge de travail.
Les stratégies clés de cet article reposent sur la pratique opérationnelle fondamentale de l’observabilité, décrites dans les stratégies d’architecture OE :07 pour la conception d’un système de surveillance. Des conseils sur l’implémentation de la pratique de surveillance sont disponibles dans le Guide de conception de surveillance. Nous vous recommandons d’examiner ces ressources en premier. Les recommandations de ce guide sont limitées aux performances. Pour plus d’informations sur la fiabilité, consultez les stratégies d’architecture RE :10 pour concevoir une stratégie de supervision et d’alerte fiable.
Définitions
| Terme | Définition |
|---|---|
| Journaux d’activité | Journaux qui enregistrent les opérations de gestion des ressources, telles que la suppression d'une ressource. |
| Logs d'application | Journaux qui suivent les informations sur les événements, les erreurs et autres activités de l’application, telles que les connexions et les échecs de connexion à la base de données. |
| Outil D’analyse des performances des applications (APM) | Outil qui surveille et signale les performances d’une application. |
| Baselines | Métriques de performances système attendues utilisées comme point de référence pour détecter les dérives, régressions et améliorations au fil du temps. |
| Instrumentation du code | Capture directe ou indirecte des métriques de performances du point de vue du code de l’application. Les métriques capturées incluent les métriques de flux, l’utilisation des ressources et les métriques spécifiques au langage ou au runtime. |
| Traçage distribué | Collecte et corrélation des métriques entre les composants de charge de travail distribués pour comprendre les flux de transactions de bout en bout. |
| Latency | Délai entre le lancement d’une demande et la réception d’une réponse, en mesurant la réactivité du système. |
| Metrics | Mesures numériques qui enregistrent le comportement des performances de la charge de travail au fil du temps, généralement agrégées pour l’analyse. |
| Percentiles (p50, p95, p99) | Mesures statistiques montrant la distribution des performances ; p50 représente les performances classiques, p95 montre la plupart de l’expérience utilisateur sous charge, p99 capture les performances les plus mauvaises. |
| Métriques de plateforme | Valeurs numériques qui enregistrent les performances de la charge de travail à un moment donné. |
Utiliser des métriques basées sur centile
Mesurez les métriques de performances, telles que la latence, le temps de réponse ou les temps de chargement, avec des centiles (p50, p95, p99), et non des moyennes. Les moyennes peuvent être trompeuses. Si la plupart des demandes sont rapides, mais que quelques-unes sont extrêmement lentes, la moyenne masque la mauvaise expérience.
Les percentiles montrent le comportement de l'extrémité, ce qui est important pour comprendre l’expérience des utilisateurs. p50 représente les performances classiques, p95 montre ce que la plupart des utilisateurs connaissent sous charge et p99 capture les performances les plus mauvaises ou les valeurs hors norme.
Collectez les données de performances à l’aide de vos outils de surveillance et représentez-les sous forme de centiles sur des fenêtres de temps définies. Utilisez-les comme base de référence pour l’analyse, les alertes et l’analyse des performances.
Définir vos limites d’amélioration des performances
Définissez des limites de performances claires afin de savoir exactement ce qui est inclus dans vos mesures. Décomposez la latence sur le système au lieu de la traiter comme un seul nombre. Par exemple, attribuez du temps à chaque couche, que ce soit les services périphériques, les passerelles, le calcul informatique et les dépendances, pour voir où les délais se produisent réellement.
Séparez ce que vous contrôlez de ce que vous n’avez pas : votre code, vos services, votre infrastructure et vos dépendances directes par rapport aux facteurs externes tels que les conditions côté client, la résolution DNS, la latence ISP ou les contraintes d’appareil. Cette distinction empêche la mauvaise attribution et maintient l’optimisation axée sur les domaines où vous pouvez apporter des modifications, tout en reflétant toujours l’expérience complète de l’utilisateur de bout en bout.
Évaluez quand et où les problèmes de performances affectent l’expérience utilisateur. Compenser cette dégradation par la conception ou atténuer les améliorations apportées aux parties contrôlables du système.
Segmenter les signaux par environnement et objectif
Segmenter les données de performances afin que chaque signal reflète un contexte clair. Séparez l’environnement et l’objectif pour éviter de mélanger les signaux qui se comportent différemment ou servent différentes décisions.
Séparez les données de production et de non-production. Les données de production reflètent l’impact réel de l’utilisateur et doivent stimuler la surveillance et les alertes. Les données de non-production sont utiles pour les tests et le réglage, mais les mélanger avec les données de production fausse les résultats, et masque les problèmes réels.
Séparez les métriques de performances des métriques métier. Les métriques de performances suivent le comportement du système et l’intégrité de la charge de travail, tandis que les métriques métier suivent les résultats. Même lorsqu’ils se chevauchent, conservez-les dans des flux distincts afin que chacun puisse être analysé et utilisé indépendamment.
Créer des alertes de performances étendues et actionnables
L’objectif de l’alerte est la détection précoce de la dégradation des performances avant qu’elle ne devienne visible par l’utilisateur ou impact sur l’entreprise. Créer des alertes à deux niveaux : expérience utilisateur intégrale et transactions internes fondamentales qui représentent des chemins système critiques lorsqu'elles sont sous charge.
Utilisez un jeu de données unique et cohérent dans chaque environnement pour les cibles et les alertes. Si les alertes sont basées sur des données différentes de vos cibles de performances, elles deviennent peu fiables et difficiles à approuver.
Créez des alertes exploitables et clairement liées aux résultats des performances. Chaque alerte doit indiquer quel seuil a eu une violation soutenue, l’impact potentiel et les composants impliqués afin qu’il soit clair où examiner et ce qui est affecté. Commencez par des seuils standard et connus, puis affinez-les au fil du temps en fonction du comportement du système et des caractéristiques de charge de travail observés.
Lorsque les alertes directes sur une dépendance externe ne sont pas possibles, utilisez des signaux indirects tels que la durée de l’appel de dépendance, les taux d’erreur ou le comportement de délai d’attente pour estimer son impact sur les performances du système.
Surveiller l’élasticité
Mesurez la façon dont votre système répond aux changements dans les événements de demande et de mise à l’échelle.
Suivez la latence de démarrage à froid et d’initialisation pour comprendre comment la surcharge de démarrage affecte la réactivité, en particulier pendant les événements de scale-out. Surveillez le comportement de scale-out et de scale-in pour évaluer la rapidité avec laquelle le système s’adapte aux changements de charge et si les actions de mise à l’échelle suivent le rythme de la demande.
Suivre les performances au fil du temps
Suivez l’évolution des performances avec les modifications apportées à vos facteurs de conception et externes.
Établissez des lignes de base qui représentent les performances système attendues, puis comparez le comportement actuel à ceux-ci pour détecter la dérive, y compris les régressions et les améliorations.
Connectez les modifications de performances aux événements opérationnels tels que les déploiements, les mises à jour de configuration et les actions de mise à l’échelle. Annotez les chronologies avec ces événements afin que les changements de comportement aient un contexte clair et puissent être suivis à des causes probables.
Utilisez cette visibilité continue en tant que boucle de commentaires pour les décisions d’ingénierie. Intégrez les analyses de performances dans la planification et la hiérarchisation, et traitez-les comme des éléments d'entrée dans le travail quotidien plutôt que seulement pour une réponse aux incidents.
Affinez continuellement les objectifs de performances à mesure que le système évolue. Ajustez les SLA, les seuils et les attentes en fonction du comportement et des modèles d’utilisation observés afin que les cibles restent réalistes et alignées sur l’expérience utilisateur réelle.
Collecter les données de performances des applications
Vous devez disposer des métriques de performances de l’application, telles que le débit, la latence et les temps d’achèvement, principalement collectées par le biais du code d’instrumentation.
Instrumentez les chemins d’exécution critiques où les performances sont les plus visibles : flux de requêtes clés, opérations gourmandes en ressources et points où des dépendances externes ou des nouvelles tentatives se produisent. Assurez-vous que la visibilité des transactions de bout en bout permet de mesurer le temps d’exécution total et ses étapes de contribution.
Capturez trois types principaux de signaux de performances :
- Métriques pour le comportement des performances agrégées (distributions de latence, débit, taux d’erreur)
- Traces pour comprendre comment le temps est distribué entre les chemins de requête et les composants système
- Journaux d’activité pour un contexte d’exécution détaillé à des étapes ou événements spécifiques
Utilisez des métadonnées cohérentes sur ces signaux afin que les données de performances puissent être corrélées entre les couches du système et entre les services.
Évitez de dupliquer les signaux de performances de bas niveau déjà exposés par la plateforme, sauf si une granularité supplémentaire est nécessaire pour expliquer le comportement ou les goulots d’étranglement spécifiques à la charge de travail.
Collecter les données de performances des ressources
Collectez les données de performances au niveau des ressources pour comprendre comment les composants d’infrastructure se comportent sous la charge et comment ils contribuent aux performances globales de la charge de travail.
Chaque service expose des métriques spécifiques à la plateforme qui reflètent ses caractéristiques d’intégrité et de performances. Utilisez le paramètre de diagnostic pour exporter ces données afin qu’elles soient accessibles pour l’alerte, les tableaux de bord et l’analyse à long terme au-delà de la rétention de la plateforme de courte durée.
Collectez les métriques et les journaux de bord pour toutes les ressources. Effectuez le suivi de l’utilisation du calcul et du stockage par rapport aux plages attendues pour confirmer que le sous-approvisionnement n’introduit pas de latence et de dégradation des performances sous charge. Le surprovisionnement est également détectable avec ces données en examinant l’utilisation de P99 et en comparant les marges de travail restantes sur vos ressources.
Surveillez le trafic réseau dans le cadre des performances des ressources. Analysez le flux de trafic entre les sous-réseaux et les limites de service pour comprendre la latence, la congestion et les modèles de transfert de données susceptibles d’avoir un impact sur les performances de la charge de travail.
Collecter des données de base de données et de stockage
Les systèmes de base de données et de stockage produisent des signaux de performances spécialisés pour identifier les goulots d’étranglement, valider la capacité et comprendre le comportement de la charge de travail. Ces signaux proviennent généralement d’outils de surveillance intégrés et de journaux générés par le système.
Concentrez-vous sur les dimensions clés des performances :
| Domaine | Ce qu'il faut mesurer | Ce qu’il vous dit |
|---|---|---|
| Throughput | Volume en lecture/écriture au fil du temps | Capacité de transfert de données |
| Latency | Durée par opération de stockage | Réactivité du stockage |
| IOPS | Opérations de lecture/écriture par seconde | Fonctionnalité de gestion des transactions |
| Utilisation de la capacité | Stockage utilisé contre stockage disponible | Besoins de planification de la mise à l’échelle et de la capacité |
Pour les bases de données, étendez la surveillance au comportement spécifique à la charge de travail :
| Domaine | Ce qu'il faut mesurer | Ce qu’il vous dit |
|---|---|---|
| Performances des requêtes | Temps d’exécution, fréquence, utilisation des ressources | Efficacité des modèles d’accès aux données |
| Performances des transactions | Durée, concurrence, contention des verrous | Contention et efficacité transactionnelle |
| Performances de l’index | Fragmentation, utilisation, impact sur l’optimisation | Efficacité des structures d’accélération des requêtes |
| Utilisation des ressources | PROCESSEUR, mémoire, disque, réseau | Contraintes au niveau du système |
| Métriques de connexion | Connexions actives, ayant échoué et abandonnées | Stabilité et pression de connexion |
| Taux de transaction | Transactions par seconde | Intensité et modifications de la charge de travail au fil du temps |
| Taux d’erreur | Erreurs et échecs de base de données | Signaux de fiabilité et de dégradation des performances |
Utilisez ces signaux ensemble pour distinguer les requêtes lentes, la saturation des ressources et les inefficacités structurelles. Cela permet l’optimisation ciblée sur les systèmes de stockage et les charges de travail de base de données.
Collecter les données de performances du système d’exploitation
Pour les charges de travail basées sur l’infrastructure, collectez des métriques au niveau du système d’exploitation pour comprendre comment les ressources de calcul sont utilisées et où les contraintes de ressources peuvent se produire.
Exemples de compteurs de performances de système d’exploitation à intervalles réguliers pour capturer le comportement basé sur le temps du système sous charge.
| Domaine | Ce qu'il faut mesurer | Ce qu’il indique |
|---|---|---|
| CPU (Unité centrale de traitement) | Utilisation du processeur (utilisateur/privilégié), longueur de la file d’attente du processeur | Saturation du calcul et pression de planification |
| Processes | Nombre de threads, nombre de handles | Chargement du processus au niveau de l’application et du système d’exploitation |
| Mémoire | Mémoire engagée, mémoire disponible, taux de pagination, utilisation de l’échange | Pression sur la mémoire et activité de pagination |
| Disque | Taux de lecture/écriture, débit, utilisation du disque | Performances et goulots d’étranglement des E/S de stockage |
| Network | Débit de l’interface, erreurs RX/TX | Problèmes de capacité et de transmission du réseau |
Utilisez ces signaux pour identifier la saturation des ressources au niveau du système d’exploitation et pour distinguer les inefficacités au niveau de l’application et les contraintes d’infrastructure.
Générer des données synthétiques, le cas échéant
Si votre système n’est pas utilisé de manière cohérente, il est difficile de savoir s’il fonctionnera correctement lorsque le trafic est retourné.
Pour résoudre ce problème, utilisez des transactions synthétiques, qui envoient des requêtes automatisées via votre système. Ceux-ci simulent l’utilisation réelle sans affecter les utilisateurs ou les données réels. Cela permet de maintenir les parties de votre système actives, de générer des métriques de performances cohérentes et de révéler des modèles (comme les problèmes de temps de jour) que l’utilisation irrégulière peut masquer.
Facilitation par Azure
Azure Monitor fournit une plateforme unifiée pour collecter, analyser et répondre aux données de performances dans l’ensemble de votre charge de travail. Il agrège les données des applications, de l’infrastructure et des sources externes dans une plateforme de données commune.
Collecte et stockage des données : utilisez des espaces de travail Log Analytics pour centraliser vos données de performances avec des stratégies de rétention configurables. Créez plusieurs espaces de travail pour segmenter les données selon les exigences d’environnement ou de conformité.
Surveillance des applications : Application Insights collecte les données de télémétrie au niveau de l’application, notamment les taux de requête, les temps de réponse et les exceptions. Activez le suivi distribué pour mettre en corrélation les performances entre les composants distribués.
Surveillance de l’infrastructure : activez les paramètres de diagnostic sur tous les services Azure pour collecter les journaux et les métriques de plateforme. Utilisez l’extension Diagnostics Azure pour obtenir des données détaillées sur les performances des machines virtuelles. Explorez les options de télémétrie pour votre plateforme spécifique. Par exemple, les clusters Kubernetes émettent des données de télémétrie de performances enrichies via des intégrations Prometheus .
Base de données et stockage : Azure Monitor fournit une surveillance intégrée pour azure SQL Database, MySQL, PostgreSQL et les services de stockage. Azure Storage Analytics effectue le suivi des indicateurs clés de performance tels que le débit et la latence dans les Stockages Blob, Table et File d’attente.
Alertes et analyse : créez des règles d’alerte avec des seuils personnalisables, des fenêtres de temps et des actions (e-mail, webhooks, Azure Functions). Utilisez les journaux Azure Monitor pour interroger et mettre en corrélation les données de performances. Pour plus d’informations sur la tarification, consultez la tarification d’Azure Monitor.
Exemples
- Application web des services d’application de base hautement disponibles et redondants au niveau des zones
- Surveiller une application de microservices dans Azure Kubernetes Service (AKS)
- Surveiller les composants de zone d’atterrissage des plateformes Azure
Liens connexes
Liste de contrôle de l'efficacité de la performance
Référez-vous à l’ensemble complet des recommandations.