1. D’où viennent les données #
Le point de vue de l’application.
Les services de base de données #
Le OneAgent instrumente les pilotes utilisés par l'application (JDBC, ADO.NET, pilotes Node.js, Python, Go…). Chaque appel devient un span rattaché à la requête qui l'a déclenché, et Dynatrace regroupe les appels vers une même base dans un service de base de données. Il mesure le temps vu par l'application, sans agent sur le serveur de base de données.
À savoir : L'état interne du serveur de base de données (plans d'exécution, attentes, verrous) relève des extensions de base de données ou des outils de l'éditeur ; le service de base de données montre l'impact de la base sur l'application.
2. Les trois catégories #
Comment Dynatrace classe les instructions.
Classement des instructions #
Dans l'analyse d'un service de base de données, les instructions sont réparties en trois catégories, qui permettent de filtrer les graphiques et la liste des requêtes :
| Catégorie | Instructions | Ce qu’il faut surveiller |
|---|---|---|
| Modifications | INSERT, UPDATE, DELETE, MERGE | contention, verrous, volumes de mise à jour |
| Requêtes ou procédures | SELECT, appels de procédures stockées | nombre d’appels par requête, requêtes lentes |
| Transactions | COMMIT, ROLLBACK | temps de validation, nombre de validations |
Erreur courante : Lire « requêtes ou procédures » comme « lectures seules » : une procédure stockée peut modifier des données. Rappel des notions SQL dans Les types d’instructions SQL.
3. Diagnostiquer #
Des motifs fréquents.
Symptômes et causes #
| Ce que l’on voit | Cause probable |
|---|---|
| des dizaines d’appels identiques par requête | problème N+1 (boucle d’ORM) |
| les transactions pèsent lourd dans le temps total | un COMMIT par ligne, disque lent côté base |
| les modifications ralentissent aux heures de pointe | verrous, contention sur les mêmes lignes |
| temps d’attente avant la requête | pool de connexions saturé |
Bonne pratique : Partez de la requête utilisateur lente, ouvrez sa trace distribuée et regardez la part de la base de données : c'est plus fiable que de partir de la requête SQL la plus lente, qui peut être rare.
Requête DQL sur les spans #
Sur la nouvelle plateforme, les appels de base de données sont des spans stockés dans Grail :
fetch spans, from: -1h
| filter isNotNull(db.system) and span.kind == "client"
| summarize appels = count(), p90 = percentile(duration, 90), by: { db.system, db.statement }
| sort p90 desc
| limit 20Selon la version : Les noms d'attributs suivent les conventions OpenTelemetry : selon la version, le texte de la requête est dansdb.statementoudb.query.text. Vérifiez dans un notebook avant de construire un tableau de bord.
