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 Les informations de base de données Aurora DSQL permettent d'accéder à des données échantillonnées par seconde pour chaque session active de votre cluster, collectées par l'échantillonneur **DASH (DSQL Active Session History)** qui enregistre l'état d'attente et les instructions SQL normalisées pour 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 les plus gourmandes en ressources et diagnostiquer les problèmes de performances. Vous n'avez pas besoin de configurer DASH. Il est automatiquement activé pour chaque cluster SQL Aurora, et les données agrégées par minute sont disponibles via Amazon CloudWatch Database Insights et via des requêtes Prometheus Query Language (ProMQL) exécutées sur des métriques OTel sans frais supplémentaires. CloudWatch **Topics** + [Qu'est-ce que DASH ?](#dash-what-is) + [Indicateurs DASH et événements d'attente](#dash-metrics-wait-events) + [Accès aux données DASH](#dash-accessing-data) + [Ressources connexes](#dash-related-resources) ## Qu'est-ce que DASH ? Une session active représente une connexion unique à votre cluster ayant une transaction 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 + Inactif pendant la transaction, en attente du prochain relevé de votre application dans le cadre d'une transaction ouverte DASH suit uniquement 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. Voir [Événements d'attente DASH](#dash-wait-events) la liste complète. + **L'instruction SQL** : les 256 premiers caractères du code SQL exécuté par la session, ce qui est suffisant pour identifier la plupart des requêtes. DASH agrège 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 sur 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 de base pour l'analyse des performances d'Aurora DSQL. La répartition des temps d'attente indique le temps consacré à vos sessions, et pas seulement le niveau d'affluence du cluster. Les attributs de ventilation SQL sont chargés dans des requêtes individuelles. **Astuce** Aurora DSQL adapte le processeur de manière élastique, de sorte que le signal de diagnostic le plus utile est 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 vCPU 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. ## Indicateurs DASH et événements d'attente DASH expose une métrique unique dont les dimensions vous permettent de découper 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 défini. | La métrique comporte les dimensions (étiquettes) suivantes, que vous pouvez utiliser pour regrouper et filtrer les données. | Dimension | Description | | --- |--- | | db.wait.class | Classification plus large des événements d'attente afin d'identifier le type général de ressource contribuant au chargement de la base de données. Par exemple, class:oncpu cela signifie que l'instruction est activement exécutée sur le processeur et class:io qu'elle attend la fin d'une input/output opération. | | db.wait.event | État d'attente dans lequel se trouvaient les sessions échantillonnées. Consultez [Événements d'attente DASH](#dash-wait-events) 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 pendant laquelle les sessions étaient en cours d'exécution. | | db.query.normalized\_text | Le texte SQL normalisé de l'instruction que les sessions étaient en cours d'exécution. 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 | L'ARN du rôle IAM supposé 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 l'annuler au moment de la connexion. DASH inclut cette dimension uniquement si vous la définissez explicitement. | ### Événements d'attente DASH Les sessions Aurora DSQL peuvent connaître les événements d'attente suivants. Les événements d'attente liés au stockage (`SequentialScanRead`,, `ScatteredBatchRead` `SingleRead``UniqueConstraintCheck`, et`FkExistenceCheck`) représentent la communication entre la couche de traitement des requêtes et la couche de stockage, ainsi `Commit` que 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 | Cours d'attente | Description | | --- |--- |--- | | OnCpu | class:oncpu | La session n'attend aucune entrée externe et s'exécute activement sur le processeur, qu'il s'agisse d'analyser, de planifier, d'évaluer des expressions ou de traiter les résultats. | | ClientRead | class:client | La session est inactive au cours d'une transaction ouverte et attend que l'application envoie la prochaine instruction SQL ou commit/rollback commande. Les temps d'ClientReadattente fréquents ou longs sont souvent le signe d'un nombre excessif d'allers-retours ou de 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 de grands ensembles de résultats 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 du tableau ; 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 (recherche par point) depuis le stockage. ScatteredBatchReadavec une taille de lot de 1 remplace largement cet événement, qui est rare 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 autres que la 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) organisée et sans code pour explorer le chargement des bases de données et le code SQL le plus élevé. 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 d'intelligence artificielle pour le diagnostic du système Aurora DSQL** : agent de contrôle de santé basé sur l'intelligence artificielle (IA) qui analyse automatiquement les données DASH, compare la distribution des événements d'attente sur plusieurs périodes 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 créé 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 consulter les données DASH dans Database Insights 1. Ouvrez la CloudWatch console et choisissez **Database Insights** dans le volet de navigation de gauche. 1. Dans la vue **Fleet Health**, 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. 1. Choisissez l'**identifiant de base** de données pour ouvrir le tableau de **bord de l'instance de base** de données. 1. Utilisez le graphique de **charge** de base de données pour visualiser le nombre moyen de 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 le niveau d'affluence du cluster et les bandes indiquent à quoi les sessions consacrent leur temps. 1. Utilisez le contrôle **Slice By** sur le graphique de **charge de la base** de données pour basculer entre les **événements d'attente** et **le texte SQL**. 1. La section **Analyse de la charge de base** de données présente l'AAS en fonction des **principaux événements d'attente** et **le code SQL** le plus important classé en fonction de leur contribution à l'AAS. 1. Utilisez le sélecteur de plage horaire 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étrique`db.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 où le sélecteur de temps gère la fenêtre d'évaluation. Le nom de la métrique contenant 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`étiquette pour étendre les résultats à un seul cluster. {{cluster-id}}Remplacez-le par l'identifiant de votre cluster. Si vous n'avez 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 `{"db.active_sessions.avg"}` une requête 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 : la même AAS-by-wait-event vue est disponible dans le graphique de charge de 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 représentant la contribution AAS moyenne de cet état d'attente. **Nombre moyen de requêtes SQL les plus utilisées par session active** 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 Database Insights **Top SQL**. ``` 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 à la charge, ajoutez-les `db.wait.event` à la clause de regroupement. Comme cela permet de classer toutes les combinaisons ensemble, les résultats peuvent inclure plusieurs temps d'attente pour le même relevé contributif élevé : ``` topk(5, avg by ("db.query.normalized_text", "db.wait.event") ( { "db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="{{cluster-id}}" } ) ) ``` **Instructions SQL effectuant le plus grand nombre de lectures de stockage** Renvoie les cinq instructions SQL les plus consacrées aux opérations de lecture du stockage, en filtrant en fonction des événements d'attente liés à la 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 du stockage dont les noms commencent `S` et se terminent par `Read` (`SequentialScanRead`,`ScatteredBatchRead`,`SingleRead`). Le modèle inclut `.*Check` explicitement parce que les événements `UniqueConstraintCheck` et d'`FkExistenceCheck`attente ne correspondent pas au premier modèle, mais sont également des événements d'attente liés au stockage et à la lecture. ### Utilisation de la compétence AI de diagnostic du système Aurora DSQL La compétence AI de diagnostic du système Aurora DSQL automatise l'analyse de l'état de votre cluster Aurora DSQL en lisant les données DASH, en comparant la distribution des événements d'attente sur plusieurs périodes et en générant un rapport de diagnostic. La compétence fait partie du plugin [databases-on-aws dans Agent Plugins for AWS](https://github.com/awslabs/agent-plugins/tree/main/plugins/databases-on-aws) dans le référentiel [awslabs/agent-plugins](https://github.com/awslabs/agent-plugins) et fonctionne avec n'importe quel agent de codage AI pris en charge. Pour analyser l'état du cluster, émettez une invite telle que : *« Vérifiez les performances de mon cluster {{cluster-id}} Aurora DSQL {{us-east-1}} et rédigez-moi un rapport Markdown. »* 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 avec celles de lundi dernier. »* Lorsque des requêtes spécifiques semblent problématiques, la compétence lance un flux de travail de SQL-focused diagnostic plus approfondi et indique des solutions potentielles pour cette déclaration. Il décide s'il convient d'explorer une requête en fonction du décalage des événements d'attente qu'il détecte, de sorte que vous n'avez pas besoin d'instructions supplémentaires. ## Ressources connexes + [Métriques de requêtes avec ProMQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html) — aperçu de la prise en charge de ProMQL dans. CloudWatch + [Exécution de requêtes ProMQL dans Query Studio](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL-QueryStudio.html), le pupitre de requêtes interactif de la console. CloudWatch + [AWS a vendu des métriques au OpenTelemetry format](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-OTelEnrichment.html) : comment les métriques de AWS service, y compris celles pour Aurora DSQL, sont présentées sous forme de séries PromQL-queryable chronologiques. + [Amazon CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) : CloudWatch interface utilisateur permettant de surveiller la charge et les performances des bases de données. + [Plug-ins d'agent pour AWS](https://github.com/awslabs/agent-plugins) sur le GitHub site Web : référentiel source pour le `databases-on-aws` plug-in contenant la compétence AI de diagnostic du système Aurora DSQL.