Concepts clés de DevOps Guru for RDS

Un aperçu est généré par DevOps Guru lorsqu'il détecte un comportement anormal ou problématique dans vos applications opérationnelles. Un aperçu contient des anomalies pour une ou plusieurs ressources. Une anomalie représente une ou plusieurs mesures connexes détectées par DevOps Guru qui sont inattendues ou inhabituelles.

La sévérité d'un aperçu est élevée, moyenne ou faible. La gravité de l'aperçu est déterminée par l'anomalie la plus grave qui a contribué à la création de l'aperçu. Par exemple, si l'aperçu AWS-ECS_ MemoryUtilization _and_others inclut une anomalie de faible gravité et une autre de gravité élevée, la gravité globale de l'aperçu est élevée.

Si les instances de base de données Amazon RDS ont activé Performance Insights, DevOps Guru for RDS fournit une analyse détaillée et des recommandations concernant les anomalies associées à ces instances. Pour identifier une anomalie, DevOps Guru for RDS développe une base de référence pour les valeurs métriques de base de données. DevOpsGuru for RDS compare ensuite les valeurs métriques actuelles à la base de référence historique.

Insights proactifs

Un insight proactif vous permet de connaître un comportement problématique avant qu'il se produise. Il contient des anomalies avec des recommandations et des mesures connexes pour vous aider à résoudre les problèmes avant qu'ils ne s'aggravent.

Chaque page d'information proactive fournit des informations détaillées sur une anomalie.

Insights réactifs

Un insight réactif identifie un comportement anormal lorsqu'il se produit. Il contient des anomalies avec des recommandations, des indicateurs connexes et des événements pour vous aider à comprendre et à résoudre les problèmes dès maintenant.

Anomalies causales

Une anomalie causale est une anomalie de premier niveau au sein d'un insight réactif. Elle est affichée en tant que métrique principale sur la page de détails des anomalies de la console DevOps Guru. Le chargement de la base de données (charge de base de données) est l'anomalie causale de DevOps Guru for RDS. Par exemple, l'aperçu AWS-ECS_ MemoryUtilization _and_others peut présenter plusieurs anomalies métriques, dont l'une est le chargement de base de données (charge de base de données) pour la ressource AWS/RDS.

D'après un aperçu, l'anomalie de charge de la base de données (charge de base de données) peut se produire pour plusieurs instances de base de données Amazon RDS. La gravité de l'anomalie peut être différente pour chaque instance de base de données. Par exemple, la gravité d'une instance de base de données peut être élevée alors que la gravité des autres est faible. La console détecte par défaut l'anomalie la plus grave.

Anomalies contextuelles

Une anomalie contextuelle est un résultat dans la charge de base de données qui est associé à un insight réactif. Il est affiché dans la section Métriques associées de la page de détails des anomalies de la console DevOps Guru. Chaque anomalie contextuelle décrit un problème de performance Amazon RDS spécifique qui nécessite une enquête. Par exemple, une anomalie causale peut inclure les anomalies contextuelles suivantes :

• Capacité du processeur dépassée : la file d'attente ou l'utilisation du processeur sont supérieures à la normale.

• Mémoire insuffisante dans la base de données : les processus ne disposent pas de suffisamment de mémoire.

• Nombre élevé de connexions à la base de données : le nombre de connexions à la base de données est supérieur à la normale.

Recommandations

Chaque aperçu comporte au moins une action suggérée. Les exemples suivants sont des recommandations générées par DevOps Guru for RDS :

• Réglez les identifiants SQL List_of_IDS pour réduire l'utilisation du processeur, ou mettez à niveau le type d'instance pour augmenter la capacité du processeur.

• Passez en revue le pic associé de connexions actuelles à la base de données. Envisagez de régler les paramètres du pool d'applications pour éviter l'allocation dynamique fréquente de nouvelles connexions à la base de données.

• Recherchez les instructions SQL qui effectuent des opérations de mémoire excessives, telles que le tri en mémoire ou les jointures volumineuses.

• Étudiez l'utilisation intensive des E/S pour les ID SQL suivants : List_of_IDS.

• Vérifiez les instructions qui créent de grandes quantités de données temporaires, par exemple celles qui effectuent des tris importants ou utilisent de grandes tables temporaires.

• Vérifiez les applications pour déterminer la cause de l'augmentation de la charge de travail de la base de données.

• Envisagez d'activer le schéma de performance MySQL.

• Vérifiez les transactions de longue durée et terminez-les par un commit ou un rollback.

• Configurez le paramètre idle_in_transaction_session_timeout pour mettre fin à toute session restée dans l'état « inactive en cours de transaction » pendant plus longtemps que la durée spécifiée.