View a markdown version of this page

Surveillance des clusters Aurora DSQL avec Aurora DSQL Database Insights - Amazon Aurora DSQL
Qu'est-ce que DASH ?Métriques DASH et événements d'attenteAccès aux données DASHRessources connexes

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 des clusters Aurora DSQL avec Aurora DSQL Database Insights

Aurora DSQL Database Insights permet d'accéder à des données échantillonnées par seconde pour chaque session active de votre cluster, collectées par l'échantillonneur DASH (Active Session History) DSQL qui enregistre l'état d'attente et l'instruction SQL normalisée de chaque session en cours d'exécution. Per-minute les résultats agrégés du DASH sont publiés sous forme de métriques CloudWatch OpenTelemetry (OTel). Utilisez ces données pour comprendre la charge de votre base de données, identifier les requêtes qui consomment le plus de ressources et diagnostiquer les problèmes de performances.

Vous n'avez pas besoin de configurer DASH. Il est automatiquement activé pour chaque cluster Aurora DSQL, et des données agrégées par minute sont disponibles via Amazon CloudWatch Database Insights et via les requêtes Prometheus Query Language (ProMQL) exécutées sur les métriques OTel sans frais supplémentaires. CloudWatch

Qu'est-ce que DASH ?

Une session active représente une connexion unique à votre cluster pour laquelle une transaction est ouverte. À tout moment, chaque session active se trouve dans l'un des trois états suivants :

  • Utilisation du processeur

  • En attente de la fin d'une opération externe, telle qu'une lecture de stockage ou un accusé de réception de validation

  • Transaction inactive, en attente du prochain relevé de votre application dans une transaction ouverte

DASH ne suit que les sessions pour lesquelles une transaction est ouverte. DASH capture cette activité en échantillonnant toutes les sessions actives de votre cluster une fois par seconde. Chaque échantillon enregistre deux choses :

  • L'événement d'attente  : état dans lequel se trouvait la session au moment de l'échantillonnage. Consultez Événements d'attente DASH la liste complète.

  • L'instruction SQL  : les 256 premiers caractères du code SQL que la session était en train d'exécuter, ce qui est suffisant pour identifier la plupart des requêtes.

DASH regroupe ces échantillons par seconde et les publie CloudWatch une fois par minute, ventilés par événement d'attente et par instruction SQL. Le résultat est une métrique de série chronologique unique qui enregistre le nombre moyen de sessions actives au cours de chaque période d'échantillonnage. db.active_sessions.avg Cette valeur est également connue sous le nom de sessions actives moyennes (AAS).

L'AAS est le signal fondamental pour l'analyse des performances d'Aurora DSQL. La répartition des événements d'attente indique à quoi vos sessions consacrent du temps, et pas seulement à quel point le cluster est occupé. Les attributs de répartition SQL se chargent dans des requêtes individuelles.

Astuce

Aurora DSQL fait évoluer le processeur de manière élastique. Le signal de diagnostic le plus utile est donc la forme du profil d'attente (la distribution proportionnelle du temps de session entre les événements d'attente) plutôt que l'AAS par rapport à un plafond de processeur virtuel fixe. Comparez cette forme à la ligne de base que vous observez en fonctionnement normal. Une modification de ces proportions indique une modification de la charge de travail ou du comportement du système.

Métriques DASH et événements d'attente

DASH expose une métrique unique dont les dimensions vous permettent de répartir le chargement de la base de données par événement d'attente et par instruction SQL. Le tableau suivant décrit la métrique DASH.

Métrique Unité Description
db.active_sessions.avg Nombre Nombre moyen de sessions actives sur le cluster au cours de la période d'échantillonnage (AAS). Chaque session active est exécutée sur le processeur ou dans un état d'attente nommé.

La métrique comporte les dimensions (étiquettes) suivantes, que vous utilisez pour regrouper et filtrer les données.

Dimension Description
db.wait.class Classification élargie des événements d'attente pour identifier le type général de ressource contribuant à la charge de la base de données. Par exemple, class:oncpu signifie que l'instruction est en cours d'exécution sur le processeur et class:io que l'instruction attend la fin d'une input/output opération.
db.wait.event L'état d'attente dans lequel se trouvaient les sessions échantillonnées. Consultez Événements d'attente DASH la liste complète des valeurs.
db.session.state État de la session : active (exécution d'une instruction) ou idle in transaction (attente de la prochaine commande de l'application alors que la transaction reste ouverte).
db.query.id Empreinte du texte SQL normalisé de l'instruction que les sessions étaient en train d'exécuter.
db.query.normalized_text Le texte SQL normalisé de l'instruction que les sessions étaient en train d'exécuter. DASH supprime les valeurs littérales afin de regrouper les instructions qui ne diffèrent que par leurs paramètres.
aws.auroradsql.session.role.arn Le rôle IAM ARN assumé pour se connecter au cluster Aurora DSQL.
application.name Le nom de l'application que vous avez défini dans les paramètres de connexion. Vous pouvez le modifier au moment de la connexion. DASH inclut cette dimension uniquement lorsque vous la définissez explicitement.

Événements d'attente DASH

Les sessions Aurora DSQL peuvent rencontrer les événements d'attente suivants. Les événements d'attente liés au stockage —SequentialScanRead, ScatteredBatchRead SingleReadUniqueConstraintCheck, et FkExistenceCheck — représentent la communication entre la couche de traitement des requêtes et la couche de stockage, et Commit représentent la communication avec le service de validation. Cette liste peut s'allonger au fil du temps à mesure qu'Aurora DSQL identifie de nouveaux événements d'attente.

Événement d'attente Classe d'attente Description
OnCpu class:oncpu La session n'attend aucune entrée externe et s'exécute activement sur le processeur : analyse, planification, évaluation d'expressions ou traitement des résultats.
ClientRead class:client La session est inactive dans le cadre d'une transaction ouverte et attend que l'application envoie la prochaine instruction SQL ou une commit/rollback commande. Les ClientRead attentes fréquentes ou longues indiquent souvent un nombre excessif de demandes, des allers-retours ou des transactions que vous maintenez ouvertes plus longtemps que nécessaire.
ClientWrite class:client La base de données envoie les résultats à l'application via le réseau. Un niveau élevé ClientWrite peut indiquer des jeux de résultats volumineux ou une latence réseau entre l'application et la base de données.
SequentialScanRead class:io La session lit une plage contiguë de clés depuis le stockage. Il ne s'agit pas nécessairement d'une analyse complète de la table ; elle peut couvrir une plage relativement restreinte de clés contiguës.
ScatteredBatchRead class:io La session effectue des lectures par lots depuis le stockage, récupérant plusieurs clés non contiguës en un seul appel au stockage.
SingleRead class:io La session lit un seul tuple (point de recherche) depuis le stockage. ScatteredBatchReadavec une taille de lot de 1 remplace largement cet événement, qui est peu courant dans les versions actuelles d'Aurora DSQL.
UniqueConstraintCheck class:io La session valide des contraintes clés uniques, ce qui nécessite des lectures de stockage pour vérifier la présence de doublons. Cela s'applique à la fois aux contraintes uniques sur les colonnes ne contenant pas de clé primaire et aux contraintes de clé primaire lors de l'insertion de nouvelles lignes.
FkExistenceCheck class:io La session valide l'existence d'une ligne de clé étrangère référencée, ce qui nécessite des lectures pour confirmer la relation.
StartTransaction class:io La session prépare le début de la transaction distribuée.
Commit class:io La session a lancé une validation et attend un accusé de réception de la part du service de validation. La réponse est soit un succès, soit un abandon (erreur de sérialisation) ; une Commit attente précède les deux résultats.
PgSleep class:timeout La session est en veille car l'application l'a explicitement appeléepg_sleep(). Il s'agit d'une attente initiée par l'application, et non d'une attente imposée par la base de données.

Accès aux données DASH

Vous pouvez accéder aux données DASH de trois manières :

  • Amazon CloudWatch Database Insights — Une interface utilisateur (UI) sans code conçue pour explorer la charge de la base de données et les requêtes SQL les plus fréquentes. C'est le point de départ de la plupart des enquêtes.

  • ProMQL  : interrogez la db.active_sessions.avg métrique sous-jacente par programmation pour l'intégrer à des outils de surveillance tiers ou pour une exploration interactive.

  • Compétence IA de diagnostic du système Aurora DSQL  : agent de contrôle de santé alimenté par l'intelligence artificielle (IA) qui analyse automatiquement les données DASH, compare la distribution des événements d'attente sur une période donnée et génère des rapports de diagnostic.

Tous ces chemins d'accès sont lus à partir du même jeu de données DASH.

Utilisation de CloudWatch Database Insights

Amazon CloudWatch Database Insights présente les données DASH via un tableau de bord DSQL-specific organisé par Aurora. Vos clusters Aurora DSQL apparaissent automatiquement dans Database Insights. Vous n'avez besoin d'aucune configuration autre que la création du cluster et l'exécution de transactions sur celui-ci.

Pour afficher les données DASH dans Database Insights

  1. Ouvrez la CloudWatch console et choisissez Database Insights dans le volet de navigation de gauche.

  2. Dans la vue État de la flotte, localisez votre cluster Aurora DSQL dans la liste des ressources de base de données. Vous pouvez également accéder directement à la page Instance de base de données et sélectionner votre cluster dans le panneau de gauche.

  3. Choisissez l'identifiant de base de données pour ouvrir le tableau de bord de l'instance de base de données.

  4. Utilisez le graphique de charge de la base de données pour afficher la moyenne des sessions actives au fil du temps. Le graphique est une visualisation empilée dans laquelle chaque bande colorée représente un événement d'attente. La hauteur totale indique donc l'occupation du cluster et les bandes indiquent les sessions auxquelles elles consacrent leur temps.

  5. Utilisez le contrôle Slice By sur le graphique DB Load pour basculer entre Wait Events et SQL Text.

  6. La section Analyse de la charge de la base de données classe AAS selon les meilleurs événements d'attente et Top SQL selon leur contribution à l'AAS.

  7. Utilisez le sélecteur d'intervalle de temps en haut de la page pour vous concentrer sur une fenêtre de surveillance spécifique, telle que la période pendant laquelle un ralentissement a été signalé.

Utilisation de ProMQL

DASH expose les données sous forme de CloudWatch métriquedb.active_sessions.avg, que vous pouvez interroger avec ProMQL dans CloudWatch Query Studio.

Les exemples suivants fonctionnent dans Query Studio, où l'espace de travail actif étend déjà les résultats à votre compte et à votre région, et le sélecteur de temps gère la fenêtre d'évaluation. Comme le nom de la métrique contient des points, les exemples utilisent le formulaire de sélection de noms entre guillemets ProMQL,. {"db.active_sessions.avg"}

Note

Tous les exemples incluent un filtre d'@resource.aws.auroradsql.cluster_idétiquettes pour étendre les résultats à un seul cluster. Remplacez-le cluster-id par l'identifiant de votre cluster. Si vous ne possédez qu'un seul cluster, vous pouvez omettre ce filtre ou utiliser les filtres de l'interface utilisateur de Query Studio à la place. Pour découvrir toutes les étiquettes disponibles sur la métrique dans votre environnement, exécutez une requête {"db.active_sessions.avg"} de série et inspectez l'étiquette définie sur chaque série renvoyée.

Chargement de la base de données par événement d'attente

Renvoie le nombre moyen de sessions actives regroupées par événement d'attente. Il s'agit de la même AAS-by-wait-event vue que celle disponible dans le graphique de charge de la base de données Database Insights, mais accessible par programmation.

avg by ("db.wait.event") (
  {
    "db.active_sessions.avg",
    "@resource.aws.auroradsql.cluster_id"="cluster-id"
  }
)

Le résultat comporte une série par db.wait.event valeur distincte, chacune contenant la contribution AAS moyenne de cet état d'attente.

Principales requêtes SQL en termes de sessions actives en moyenne

Classe les instructions SQL en fonction de leur contribution moyenne à la charge de la base de données. Il s'agit de l'équivalent ProMQL de la vue Top SQL de Database Insights.

topk(5,
  avg by ("db.query.normalized_text") (
    {
      "db.active_sessions.avg",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)

Pour voir les principales combinaisons d'instructions SQL et d'événements d'attente en fonction de leur contribution au chargement, ajoutez db.wait.event à la clause de regroupement. Comme cela classe toutes les combinaisons ensemble, les résultats peuvent inclure plusieurs événements d'attente pour le même relevé à forte contribution :

topk(5,
  avg by ("db.query.normalized_text", "db.wait.event") (
    {
      "db.active_sessions.avg",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)
Les instructions SQL effectuant le plus grand nombre de lectures de stockage

Renvoie les cinq instructions SQL qui consacrent le plus de temps aux opérations de lecture du stockage, en filtrant selon les événements d'attente de lecture du stockage.

topk(5,
  sum by ("db.query.normalized_text") (
    {
      "db.active_sessions.avg",
      "db.wait.event"=~"S.*Read|.*Check",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)

L'expression régulière S.*Read correspond aux événements de lecture mémorisés dont les noms commencent S et se terminent par Read (SequentialScanReadScatteredBatchRead,SingleRead). Le modèle inclut .*Check explicitement parce que les événements UniqueConstraintCheck and FkExistenceCheck wait ne correspondent pas au premier modèle mais sont également des événements d'attente lus pendant le stockage.

Utilisation de la compétence IA de diagnostic du système Aurora DSQL

La compétence IA de diagnostic du système Aurora DSQL automatise l'analyse de l'état de santé de votre cluster Aurora DSQL en lisant les données DASH, en comparant la distribution des événements d'attente sur une période donnée et en générant un rapport de diagnostic. La compétence fait partie du plug-in databases-on-aws d'Agent Plugins for AWS dans le référentiel awslabs/agent -plugins et fonctionne avec n'importe quel agent de codage AI pris en charge.

Pour analyser l'état du cluster, lancez une invite telle que :

« Vérifiez les performances de mon cluster Aurora DSQL cluster-id dans us-east-1 et rédigez-moi un rapport de démarquage. »

La compétence utilise le serveur MCP ( CloudWatch Model Context Protocol) pour analyser la db.active_sessions.avg métrique sur une sélection de périodes et renvoie un rapport Markdown. Vous pouvez diriger cette fenêtre de comparaison des performances à l'invite suivante :

« Vérifiez les performances des 4 dernières heures et comparez-les à celles de lundi dernier. »

Lorsque des requêtes spécifiques semblent problématiques, la compétence lance un flux de SQL-focused diagnostic plus approfondi et signale des solutions potentielles pour cette déclaration. Il décide s'il convient d'explorer une requête en fonction du décalage de l'événement d'attente qu'il détecte, de sorte que vous n'avez pas besoin d'instructions supplémentaires.