Expertise PrestaShop

Conseils techniques e-commerce et PrestaShop

Une question ? Contactez Les Vikings

Logs Amazon Lightsail : activer general log et slow query MySQL

Activer et exploiter le general log et le slow query log MySQL sur Lightsail — réglages, rotation, sécurité et checklist de rollback pour PrestaShop.

Kévin DECQ-CAILLET

|

|

Mis à jour le Lecture : 14 min

Écran d'ordinateur affichant une interface MySQL avec des paramètres de logs et des graphiques.

Table des matières :

  1. Général log vs slow query log : ce que vous activez vraiment (et pourquoi ça peut casser votre prod)
  2. Prérequis Lightsail : identifier votre distribution, votre moteur (MySQL/MariaDB) et vos chemins de configuration
  3. Activer le general log MySQL sur Lightsail (runtime vs persistant) sans se tirer une balle dans le pied
  4. Activer le slow query log : réglages utiles (long_query_time, not using indexes) et validation immédiate
  5. Exploiter les logs : de la ligne dans mysql-slow.log à une action concrète (EXPLAIN, index, modules)
  6. Rotation, rétention, sécurité : rendre les logs exploitables sans fuite de données ni disque plein
  7. Checklist de validation (5 minutes) et plan de retour arrière

Général log vs slow query log : ce que vous activez vraiment (et pourquoi ça peut casser votre prod)

Le general log MySQL (aussi appelé general query log) trace pratiquement tout ce que le serveur reçoit/traite : connexions, déconnexions, requêtes, changements de base, etc. La doc MySQL est explicite : “The general query log is a general record of what mysqld is doing.” Sur un PrestaShop en trafic réel, c’est un flux très volumineux : si vous l’activez sur une instance Lightsail avec disque limité, vous pouvez saturer l’espace disque en quelques minutes/heures et vous créer un incident (MySQL en lecture seule, erreurs 500 côté PHP-FPM, etc.).

Le slow query log est beaucoup plus exploitable pour diagnostiquer des lenteurs applicatives (TTFB, pages catégories, checkout), parce qu’il n’enregistre que les requêtes “anormales” selon vos seuils. Là encore, MySQL le définit sans ambiguïté : “The slow query log consists of SQL statements that took more than longquerytime seconds to execute …”. En pratique, c’est le premier levier quand vous suspectez un manque d’index, une jointure explosive, ou un module qui spamme la DB.

Sur Amazon Lightsail, le piège n’est pas spécifique à AWS : il vient du combo petites VM + IO limité + logs non rotatés. L’impact perf est réel : le general log est synchrone par rapport aux écritures de log (selon FS, buffering, etc.), et le slow log peut aussi générer de l’IO si vous le réglez trop bas (par ex. long_query_time=0.05). La règle : activer le general log uniquement en fenêtre courte, et préférer le slow query log en continu (avec rotation stricte) pour une analyse post-mortem.

Pour éviter les confusions, retenez aussi que MySQL propose plusieurs “niveaux” d’observabilité, et qu’ils n’ont pas le même coût :

Outil Ce que ça capture Coût / risque en prod Cas d’usage réaliste sur Lightsail
General log quasi tout (requêtes + events) Très élevé (IO + disque + données sensibles) Debug court et ciblé (quelques minutes)
Slow query log requêtes dépassant un seuil (et/ou scans) Modéré si bien réglé Analyse perf continue (rotation + seuils)
Performance Schema (digest) agrégats par “fingerprint” (sans écrire chaque requête en clair) Souvent plus “safe” qu’un general log, mais dépend de la config Top requêtes par temps cumulé, priorisation des optimisations

À noter : log_output=TABLE (écrire dans mysql.general_log / mysql.slow_log) existe, mais sur une petite VM c’est souvent une mauvaise idée (grosse table, contention, maintenance). Sur Lightsail, FILE + rotation est généralement le chemin le plus prévisible.

Prérequis Lightsail : identifier votre distribution, votre moteur (MySQL/MariaDB) et vos chemins de configuration

Les étapes ci-dessous sont valables pour une instance Lightsail Linux “classique” (Ubuntu/Debian) exécutant MySQL 8.x ou MariaDB 10.x, typiquement en stack Nginx/Apache + PHP-FPM (cas fréquent pour PrestaShop 8/9). Contexte recommandé : PrestaShop 8.1+ / 9.x, PHP 8.2/8.3, MySQL 8.0 ou MariaDB 10.6+. Vous devez avoir un accès SSH avec droits sudo. Toute modification persistante implique un redémarrage du service MySQL (micro-coupure), donc planifiez une fenêtre et ayez un rollback.

Avant toute activation de logs, vérifiez 2 points “Lightsail” très concrets :

  • Espace disque disponible (le risque n°1 avec le general log) :
  df -h
  sudo du -sh /var/log/mysql 2>/dev/null || true
  • Le niveau de monitoring dont vous disposez (CPU, réseau, mais aussi IO/disque selon les métriques exposées). Lightsail expose des graphes directement dans la console ; la doc AWS est ici : Documentation Lightsail – monitoring metrics
    (utile pour corréler “j’active les logs” vs “mon IO wait explose”.)

Commencez par identifier précisément les versions et le service systemd (selon distro, le service s’appelle mysql ou mariadb) :

mysql --version
php -v
sudo systemctl status mysql || sudo systemctl status mariadb

Ensuite, localisez la hiérarchie de configuration réellement chargée. Sur Debian/Ubuntu packagés, vous avez généralement /etc/mysql/my.cnf qui inclut /etc/mysql/mysql.conf.d/*.cnf et /etc/mysql/conf.d/*.cnf. Pour être certain (et éviter de modifier un fichier ignoré), utilisez :

mysqld --verbose --help 2>/dev/null | sed -n '/Default options are read from the following files in the given order:/,/^\s*$/p'

Dernier point : instance Lightsail “DB managée” vs “MySQL installé sur la VM”. Les commandes/fichiers ci-dessous concernent MySQL/MariaDB installé sur l’instance. Si vous utilisez une base managée Lightsail, vous n’avez pas l’accès filesystem ni systemd : l’activation des logs dépend des options exposées par AWS dans la console/paramètres. Dans ce cas, il faut soit exploiter ce que Lightsail permet, soit migrer vers un service où l’export des logs est industriel (RDS + CloudWatch), sinon votre investigation restera limitée.

Enfin, côté “terrain” : si votre instance Lightsail est dans une région (ex. Paris eu-west-3) mais que vous opérez depuis un fuseau différent, gardez-le en tête au moment d’aligner un incident (période lente) avec les timestamps des logs. Une simple confusion UTC/local peut vous faire diagnostiquer “le mauvais pic”.

Activer le general log MySQL sur Lightsail (runtime vs persistant) sans se tirer une balle dans le pied

Le bon workflow en production : activer à chaud, capturer ce dont vous avez besoin, désactiver, puis analyser hors ligne. L’activation runtime se fait via SET GLOBAL, mais elle saute au redémarrage. Avant de toucher quoi que ce soit, inspectez l’état actuel :

SHOW VARIABLES LIKE 'log_output';
SHOW VARIABLES LIKE 'general_log%';

Pour activer proprement en écriture fichier :

SET GLOBAL log_output = 'FILE';
SET GLOBAL general_log_file = '/var/log/mysql/mysql-general.log';
SET GLOBAL general_log = 'ON';

Si ça échoue, 90% du temps c’est un problème de permissions/chemin. Sur Debian/Ubuntu, le répertoire standard est /var/log/mysql/. Vérifiez :

sudo ls -ld /var/log/mysql
sudo ls -l /var/log/mysql
sudo chown -R mysql:mysql /var/log/mysql
sudo chmod 0750 /var/log/mysql

Deux limites importantes à connaître sur Lightsail (et que beaucoup découvrent trop tard). Premièrement, le general log peut contenir des données sensibles (emails, tokens, voire paramètres en clair si votre code fait n’importe quoi). Ne le laissez pas tourner longtemps, et évitez de l’envoyer vers un système de logs “shared” sans filtrage. Deuxièmement, il peut dégrader votre base plus vite que le problème initial.

Pour limiter le risque, appliquez une méthode “fenêtre courte + capture” :

  1. Activez le general log.
  2. Reproduisez l’action précise (ex. une page produit précise, le checkout, un export BO).
  3. Attendez 30–120 secondes (pas plus).
  4. Désactivez immédiatement.
  5. Copiez le fichier hors serveur (ou au moins hors partition critique) pour analyse.

Désactivation runtime :

SET GLOBAL general_log = 'OFF';

Si votre objectif est d’identifier des requêtes issues de PrestaShop, une alternative moins destructrice est souvent : activer le slow log à un seuil bas pendant 5–10 minutes, ou utiliser du profiling applicatif (cf. l’article interne sur le profilage PHP/Symfony : Optimisation code source : audit performance PHP/Symfony avec profilage).

Pour le rendre persistant (à éviter sur le general log en prod), modifiez un fichier inclus, par exemple /etc/mysql/mysql.conf.d/mysqld.cnf (MySQL) ou /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB). Exemple MySQL :

[mysqld]
log_output=FILE
general_log=0
general_log_file=/var/log/mysql/mysql-general.log

Puis :

sudo systemctl restart mysql

Astuce pratique : si vous devez “rejouer” un incident court, pensez à pré-créer le fichier et valider les droits avant la fenêtre (sinon vous perdez 5 minutes de collecte à débugger un Permission denied) :

sudo touch /var/log/mysql/mysql-general.log
sudo chown mysql:mysql /var/log/mysql/mysql-general.log
sudo chmod 0640 /var/log/mysql/mysql-general.log

Activer le slow query log : réglages utiles (long_query_time, not using indexes) et validation immédiate

Le slow query log est le meilleur compromis pour une instance Lightsail qui héberge PrestaShop : coût raisonnable, données actionnables, et analyse standardisée (EXPLAIN, indexation, refactoring). Par défaut, beaucoup de serveurs ont le slow log désactivé, ou bien long_query_time trop haut (2s/10s), ce qui masque les lenteurs “ressenties” côté front. Sur un e-commerce, une requête à 400 ms peut suffire à faire passer un TTFB de 200 ms à 800+ ms si elle est multipliée par page.

Inspectez la configuration actuelle :

SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';
SHOW VARIABLES LIKE 'min_examined_row_limit';

Activation runtime (MySQL 8.x) avec un seuil pragmatique pour investiguer (exemple 0.3s) :

SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.3;
SET GLOBAL log_queries_not_using_indexes = 'ON';
SET GLOBAL min_examined_row_limit = 1000;

Trois commentaires techniques, parce que c’est là que les configs “copiées-collées” deviennent dangereuses. (1) log_queries_not_using_indexes=ON peut générer beaucoup de bruit dans le slow log sur PrestaShop (certaines requêtes légitimes en full scan sur petites tables, ou des requêtes de modules mal écrits) ; couplez-le à min_examined_row_limit pour éviter du bruit. (2) Ne descendez pas long_query_time trop bas sur une petite VM : vous allez faire de la chauffe disque pour des micro-optimisations. (3) MySQL 8 supporte une granularité fine (float) pour long_query_time, mais gardez un seuil aligné avec vos SLO : par exemple viser < 300 ms sur pages critiques.

  • Investigation courte (5–15 min) : long_query_time=0.2 à 0.5, log_queries_not_using_indexes=ON, min_examined_row_limit=500 à 2000
  • Run continu (jours) : long_query_time=0.5 à 1, log_queries_not_using_indexes=OFF (ou ON mais très filtré), rotation stricte

Pour le rendre persistant (recommandé si vous gardez le slow log en continu), ajoutez dans le fichier de conf du serveur :

[mysqld]
slow_query_log=1
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=0.5
log_queries_not_using_indexes=0
min_examined_row_limit=1000

Puis redémarrez le service. Sur une boutique active, faites-le en maintenance (ou au minimum en heures creuses), parce que même un redémarrage “rapide” peut couper des transactions.

Alternative utile (souvent sous-utilisée) : si vous craignez l’impact disque du slow log mais voulez quand même prioriser les requêtes, regardez aussi du côté de performance_schema (si activé) : vous obtenez des agrégats par requête “normalisée” sans dumper chaque SQL en clair dans un fichier. Exemple simple (à adapter) :

SELECT
  DIGEST_TEXT,
  COUNT_STAR,
  SUM_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

C’est particulièrement pratique quand vous cherchez “quelles requêtes consomment le plus de temps cumulé” (souvent plus pertinent que “la requête la plus lente une fois”).

Exploiter les logs : de la ligne dans mysql-slow.log à une action concrète (EXPLAIN, index, modules)

Lire un slow log “à la main” ne scale pas. Les outils standards : mysqldumpslow (fourni) et Percona Toolkit (pt-query-digest) si vous voulez agréger par fingerprint, mesurer la distribution des temps, et sortir un top N propre. Exemple rapide :

sudo mysqldumpslow -s t -t 20 /var/log/mysql/mysql-slow.log

Avec Percona Toolkit (si disponible sur votre distro) :

sudo pt-query-digest /var/log/mysql/mysql-slow.log > /tmp/slow-report.txt

Pour rendre les lignes du slow log immédiatement “actionnables”, apprenez à lire ces champs (ils orientent la décision index/refacto) :

  • Query_time: temps total côté MySQL (pas le temps PHP)
  • Lock_time: si élevé, suspectez contention/verrous
  • Rows_examined: si énorme vs Rows_sent, suspectez index manquant / mauvais plan
  • Rows_sent: si énorme, suspectez “overfetch” (requête trop large) ou pagination mal faite

Mini-scénario typique en PrestaShop (vu en prod) : une page catégorie devient lente après installation d’un module de filtrage/facettes. Le slow log montre une requête répétée avec Rows_examined très élevé sur une table de liaison (ou sur ps_specific_price / ps_stock_available). Vous avez alors 3 pistes rationnelles (à valider avec EXPLAIN) :

  • index composite (ordre des colonnes cohérent avec WHERE + JOIN)
  • réduction du nombre d’exécutions (cache, éviter l’appel dans un hook trop fréquent)
  • réécriture de la requête (éviter une condition non sargable, éviter des fonctions sur colonnes dans WHERE, etc.)

Une fois la requête problématique isolée, le passage obligé c’est EXPLAIN (et souvent EXPLAIN ANALYZE en MySQL 8.0) pour comprendre le plan réel, les index utilisés, et les estimations foireuses. Pour une méthodologie structurée (et éviter l’index “magique” ajouté au hasard), vous pouvez vous appuyer sur l’article interne : Index MySQL : composer, mesurer avec EXPLAIN et optimiser les requêtes. Ce n’est pas du luxe : sur PrestaShop, beaucoup de lenteurs viennent de combinaisons ps_product, ps_product_shop, ps_stock_available, ps_specific_price, ou de recherches/facettes.

Cas typique observé en e-commerce : un module ajoute une jointure ou une condition non indexée sur une table volumineuse (ex. logs métier, table de mapping, table de tracking), puis la requête est exécutée en boucle dans un hook (header, product footer, cart). Le slow log vous montrera souvent le pattern : même requête, même fingerprint, des dizaines/centaines de fois par minute. L’action n’est pas seulement “ajouter un index” : parfois il faut corriger le module, réduire le périmètre du hook, ou mettre en cache applicatif (Redis, page cache, etc.). Pour l’angle “boutique lente / TTFB / bots”, l’article interne utile est : PrestaShop lent : diagnostic TTFB, bots et optimisation serveur.

Enfin, ne négligez pas la dimension “audit global” : le slow log est une pièce du puzzle, pas une vérité unique. Sur une instance Lightsail, une requête peut être “lente” parce que la VM swap, parce que l’IO est saturée, ou parce que PHP-FPM ouvre trop de connexions. Croisez vos résultats avec la supervision (CPU steal, IO wait, buffer pool, threads). Si vous n’avez rien, instrumentez : l’article interne sur Netdata est un bon point de départ pour une VM : Netdata collecteurs : supervision temps réel Kubernetes, Docker et AWS.

Rotation, rétention, sécurité : rendre les logs exploitables sans fuite de données ni disque plein

Activer des logs sans rotation, sur Lightsail, c’est du sabotage involontaire. Vérifiez d’abord si un fichier logrotate existe déjà (souvent /etc/logrotate.d/mysql-server ou équivalent). Sinon, créez une rotation dédiée, par exemple /etc/logrotate.d/mysql-slow-general :

/var/log/mysql/mysql-slow.log /var/log/mysql/mysql-general.log {
  daily
  rotate 7
  compress
  missingok
  notifempty
  create 0640 mysql adm
  sharedscripts
  postrotate
    # Recharge des logs côté mysqld
    test -x /usr/bin/mysqladmin && /usr/bin/mysqladmin flush-logs
  endscript
}

Trois points à valider après mise en place : (1) les permissions (0640 mysql adm) doivent correspondre à votre distro (parfois groupe mysql, parfois adm) ; (2) mysqladmin flush-logs nécessite un accès admin, donc configurez ~/.my.cnf root (ou utilisez sudo mysql -e "FLUSH LOGS;") ; (3) surveillez l’espace disque (df -h, du -sh /var/log/mysql). Sur une instance Lightsail petite, 7 rotations “daily” peuvent être trop si le general log s’emballe.

Concrètement, adaptez la politique à votre contexte :

  • Si slow log en continu : daily + rotate 7 est souvent OK (à valider avec la volumétrie).
  • Si general log ponctuel : vous pouvez même le sortir de logrotate et le gérer “à la main” (activation 2 minutes, copie, suppression). Ça réduit le risque de laisser tourner “par accident”.

Si vous souhaitez écrire les logs sur un volume différent (ex. disque attaché Lightsail), attention : sur Ubuntu/Debian, AppArmor peut bloquer mysqld d’écrire hors des chemins autorisés. Symptôme : vous définissez slow_query_log_file=/mnt/logs/mysql-slow.log, MySQL “accepte”, mais aucun fichier n’apparaît, ou vous avez des erreurs dans syslog. Dans ce cas, restez sur /var/log/mysql/ ou modifiez le profil AppArmor (/etc/apparmor.d/usr.sbin.mysqld) et rechargez-le, ce qui est une opération à documenter et à tester (risque de sécurité).

Côté conformité et fuite de données, le rappel est simple : les logs SQL peuvent contenir des PII (emails clients), des références commande, et parfois des tokens si votre code passe des valeurs brutes. Minimisez la rétention, limitez les droits de lecture (chmod 0640, pas de world-readable), et évitez d’envoyer ces fichiers tels quels dans un outil tiers. Si vous devez centraliser, faites-le avec filtrage et contrôle d’accès, ou via un moteur dédié (par ex. OpenSearch) — sur le sujet “moteur de logs”, vous avez aussi un contenu interne : OVHcloud Managed OpenSearch : moteur NoSQL managé pour logs et recherche.

Point souvent oublié : si vous partagez un extrait de slow log à un prestataire (ou en ticket), purgez/anonymisez ce qui ressemble à des emails, adresses, tokens, IDs commande. Même si la requête “a l’air technique”, elle peut contenir des valeurs applicatives.

Checklist de validation (5 minutes) et plan de retour arrière

Après activation, validez immédiatement que MySQL écrit réellement. Pour le slow log : générez une requête volontairement lente sur un environnement de test (ou en prod avec prudence), puis vérifiez le fichier :

sudo tail -n 50 /var/log/mysql/mysql-slow.log

Pour le general log : même logique, mais sur une fenêtre courte. Vérifiez aussi les variables runtime :

SHOW VARIABLES LIKE 'general_log';
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

Checklist “5 minutes” (à faire dans l’ordre, et à garder en runbook) :

  • [ ] df -h : au moins quelques Go libres (sinon, n’activez pas le general log)
  • [ ] Chemin de log existant + droits OK (/var/log/mysql, propriétaire mysql)
  • [ ] Variables MySQL cohérentes (log_output=FILE, chemins de fichiers corrects)
  • [ ] tail montre des entrées récentes après une action applicative
  • [ ] Rotation en place et testée :
  sudo logrotate -f /etc/logrotate.d/mysql-slow-general
  • [ ] Si pic de latence : corréler avec métriques Lightsail (CPU, IO) pour éviter de conclure “c’est le SQL” alors que c’est du swap/IO

Plan de rollback : il doit être trivial et immédiat. Runtime :

SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';

Persistant : commentez/supprimez les lignes ajoutées dans le fichier .cnf, puis systemctl restart mysql. Si vous diagnostiquez une boutique PrestaShop réellement lente, ne vous contentez pas de “voir des requêtes lentes” : enchaînez sur un audit DB/SQL (top tables, index, cardinalités, buffer pool, contention). Sur ce point, l’article interne le plus proche est : Audit MySQL/MariaDB : optimiser les requêtes lentes e‑commerce.

Une fois les logs en place, vous avez une base rationnelle pour arbitrer : corriger une requête, ajouter un index, mettre en cache, augmenter les ressources (vertical scaling Lightsail), ou sortir MySQL de la VM (managed DB) pour isoler les IO. Le cœur de PrestaShop n’est pas “magiquement” optimisé pour toutes les boutiques : le SQL dépend énormément de vos modules, de votre catalogue, et de vos patterns de trafic. Les logs (slow log surtout) sont votre point d’entrée le plus fiable pour arrêter de deviner.

À lire aussi