Aller au contenu

AWS Mis à jour le 2026-07-04

Requêtes lentes sur RDS : activer et lire le journal des requêtes lentes sur MySQL et Postgres

Comment activer le journal des requêtes lentes sur RDS MySQL (slow_query_log, long_query_time) et Postgres (log_min_duration_statement), où les journaux atterrissent, et comment vraiment les lire.

Sur RDS, on active la journalisation des requêtes lentes par le groupe de paramètres de la base, pas en éditant des fichiers de configuration : réglez slow_query_log = 1 et long_query_time sur MySQL, ou log_min_duration_statement sur Postgres. Les deux sont des paramètres dynamiques, donc aucun redémarrage n’est requis si l’instance utilise déjà un groupe de paramètres personnalisé. Les journaux atterrissent sous Logs & events sur la page de l’instance, et l’étape que la plupart des équipes sautent — l’exportation vers CloudWatch Logs — est ce qui les rend réellement interrogeables quand quelque chose est lent à 2 h du matin.

Ce qui se passe

RDS ne vous donne pas de SSH, donc tout ce qui serait normalement une modification de my.cnf ou postgresql.conf passe par les groupes de paramètres. Les instances commencent leur vie sur le groupe de paramètres par défaut, qui est immuable — si la vôtre est encore sur default.mysql8.0 ou default.postgres16, votre premier geste est de créer un groupe personnalisé et de l’attacher (attacher un nouveau groupe exige un redémarrage pour l’association elle-même; les paramètres de journalisation ensuite, non). On a couvert la discipline plus large de leur gestion dans le réglage des groupes de paramètres.

Sur MySQL, les paramètres pertinents sont slow_query_log (0/1), long_query_time (en secondes, fractions permises — les valeurs utiles en production sont 0,5-2, pas l’antique valeur par défaut de 10), et optionnellement log_queries_not_using_indexes. log_output décide si les entrées vont vers FILE (lisible et exportable, utilisez ça) ou TABLE (mysql.slow_log, qui mange le stockage en douce et ne peut pas être exporté vers CloudWatch).

Sur Postgres, il n’y a pas de fichier de journal lent séparé — les instructions lentes vont dans le journal postgres principal quand elles dépassent log_min_duration_statement (en millisecondes; 500-2000 est une plage de production raisonnable; 0 journalise tout et inondera une instance occupée). Deux extensions de soutien font le gros du travail : pg_stat_statements pour les statistiques cumulatives (activée en l’ajoutant à shared_preload_libraries — celui-là est statique et exige un redémarrage) et auto_explain si vous voulez les plans journalisés avec les instructions lentes.

Une mise en garde honnête : journaliser n’est pas gratuit. long_query_time = 0 ou log_min_duration_statement = 0 sur une instance à haut débit ajoute des I/O mesurables et peut lui-même dégrader la performance. Journalisez la queue lente, pas le déluge.

Quoi vérifier en premier

  • Quel groupe de paramètres l’instance utilise, et si c’est un groupe par défaut — RDS > Databases > votre-instance > Configuration.
  • Si la journalisation est déjà active — bien des instances l’ont, activée par un prédécesseur, sans que personne le sache.
  • log_output sur MySQL — s’il est à TABLE, les requêtes lentes passées sont dans mysql.slow_log, et le stockage se remplit peut-être en douce.
  • Si Performance Insights est activé — pour « qu’est-ce qui est lent en ce moment », il répond plus vite que les journaux; la valeur du journal lent, c’est le dossier durable et détaillé.

Comment vérifier

Confirmez les valeurs actuelles sans vous connecter à la base :

aws rds describe-db-parameters \
  --db-parameter-group-name prod-pg16 \
  --query "Parameters[?ParameterName=='log_min_duration_statement'].[ParameterValue,ApplyType]"

Ou depuis une session :

-- MySQL
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_output';

-- Postgres
SHOW log_min_duration_statement;

Listez et récupérez les fichiers de journaux eux-mêmes :

aws rds describe-db-log-files --db-instance-identifier prod-db

aws rds download-db-log-file-portion \
  --db-instance-identifier prod-db \
  --log-file-name slowquery/mysql-slowquery.log \
  --output text > slowquery.log

Le runbook

  1. Passer à un groupe de paramètres personnalisé au besoin. Créez-le avec aws rds create-db-parameter-group, copiez les personnalisations existantes, attachez-le via modify-db-instance, et redémarrez dans une fenêtre de maintenance. Faites-le une fois; ça rapporte pour chaque réglage futur.
  2. Régler les paramètres. MySQL : slow_query_log = 1, long_query_time = 1, log_output = FILE. Postgres : log_min_duration_statement = 1000. Appliquez avec aws rds modify-db-parameter-group --db-parameter-group-name prod-pg16 --parameters "ParameterName=log_min_duration_statement,ParameterValue=1000,ApplyMethod=immediate". Les paramètres dynamiques prennent effet en quelques instants; la console affiche in-sync quand c’est fait.
  3. Exporter vers CloudWatch Logs. Dans RDS > Databases > votre-instance > Modify > Log exports, cochez le journal des requêtes lentes (MySQL) ou le journal postgresql (Postgres). C’est la différence entre fouiller des fichiers téléchargés au grep et lancer une requête sur des semaines d’historique. L’ingestion et le stockage CloudWatch Logs se facturent au Go, une raison de plus de journaliser la queue, pas tout.
  4. Lire avec des outils, pas à l’œil. Agrégez avant de juger : pt-query-digest slowquery.log pour MySQL regroupe les instructions identiques et les classe par temps total; pgbadger fait pareil pour les journaux Postgres. La requête qui compte est rarement la plus lente en solo — c’est la requête de 40 ms exécutée deux millions de fois.
  5. Chercher dans CloudWatch Logs Insights pour les questions ciblées. Exemple contre un journal Postgres exporté :
fields @timestamp, @message
| filter @message like /duration:/
| parse @message "duration: * ms" as duration_ms
| sort duration_ms desc
| limit 25
  1. Agir sur les pires contrevenants. Passez-les à EXPLAIN, indexez ou réécrivez, puis regardez le volume du journal rétrécir — le journal lui-même est votre mesure avant/après.

Quand c’est la mauvaise approche

Si l’instance brûle en ce moment, ne commencez pas par activer des journaux — Performance Insights montre déjà le top SQL actuel sans aucun délai d’installation, et le journal lent ne capture que les instructions qui se terminent. Une tempête de requêtes rapides n’apparaît jamais dans un journal lent, peu importe le seuil; ce diagnostic exige les agrégats de pg_stat_statements ou de performance_schema. Et si vous ne pouvez pas vous permettre le redémarrage pour attacher un groupe personnalisé cette semaine, Performance Insights couvre l’écart jusqu’à la fenêtre de maintenance. Les références de paramètres par moteur vivent dans la documentation Amazon RDS.

Erreurs fréquentes

  • Régler long_query_time ou log_min_duration_statement à 0 en production « juste pour tout voir » et créer un problème d’I/O par-dessus un problème de latence.
  • Laisser log_output = TABLE sur MySQL : mysql.slow_log grossit dans votre stockage alloué et n’atteint jamais CloudWatch.
  • Activer le journal sans jamais l’exporter — RDS fait pivoter les fichiers locaux, et la preuve de l’incident de mardi dernier a disparu vendredi.
  • Lire les journaux bruts de haut en bas au lieu d’agréger : la requête la plus lente en solo est habituellement un rapport hebdomadaire, pas votre problème.

Prévention

  • Gardez la journalisation des requêtes lentes activée en permanence à un seuil raisonnable (1 s) sur chaque instance de production — le coût est petit, la valeur d’enquête est grande.
  • Exportez vers CloudWatch Logs avec une politique de rétention (30-90 jours) pour garder le coût borné.
  • Faites un condensé mensuel (pt-query-digest / pgbadger) et ouvrez des billets pour le top trois — ça attrape la dégradation pendant qu’elle est encore bon marché.
  • Jumelez le journal avec Performance Insights : PI pour « maintenant », le journal lent pour « le mois passé ».
  • Revérifiez les seuils après une forte croissance des données; un seuil fixé à 10x la latence typique n’attrape plus rien une fois la latence typique triplée.

Un journal de requêtes lentes activé, exporté et réellement lu chaque mois transforme la performance de la base de données d’une urgence récurrente en tâche d’entretien. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.