Magento 2 : logs et observabilité (New Relic, Elastic) + alerting — guide 2026

Magento 2 : logs et observabilité (New Relic, Elastic) + alerting (guide 2026)

Magento 2 est souvent un des CMS e-commerce les plus exigeants en production : beaucoup de requêtes, des pics imprévisibles (soldes, campagnes), et une chaîne technique qui mélange PHP, base de données, cache et moteur de recherche.

Le problème : quand ça ralentit (ou que ça tombe), on perd vite du temps si on n’a ni visibilité, ni alertes actionnables. Ce guide vous donne une méthode simple pour :

• collecter les bons journaux (application, web, base)
• corréler ce qui se passe côté utilisateur, côté serveur et côté base
• mettre des alertes qui évitent les faux positifs

Si vous voulez déployer Magento sans passer vos journées à opérer l’infrastructure (déploiement 1 clic, facturation à l’heure, start/stop, sauvegardes automatiques, scaling CPU/RAM), vous pouvez tester Magento sur adgents.cloud.

Vidéo (YouTube, FR)

Pour comprendre la centralisation des logs et les tableaux de bord : .

1) Les 3 piliers : métriques, traces, journaux

Pour diagnostiquer vite, pensez en 3 axes :

1. Métriques : CPU, RAM, latence, erreurs 5xx, saturation PHP-FPM, temps DB…
2. Traces (APM) : une requête lente, quel composant est responsable (PHP, DB, cache) ?
3. Journaux : l’explication détaillée (exception, endpoint, payload, utilisateur, contexte).

En pratique :

• si vous ne faites que des journaux, vous avez l’explication mais pas le “signal global”
• si vous ne faites que des métriques, vous voyez le problème mais pas la cause
• si vous combinez les 3, vous gagnez du temps et vous évitez les “pannes fantômes”

Pour compléter cette approche côté performance, gardez aussi sous la main Magento 2 performances : réduire le TTFB, maîtriser le cache, sécuriser l’indexation.

2) Où sont les logs Magento 2 (et ce qu’ils signifient)

Les journaux Magento 2 sont généralement dans :

• var/log/system.log : événements “système” (comportements applicatifs, intégrations)
• var/log/exception.log : exceptions applicatives
• var/log/debug.log : utile en diagnostic ponctuel, à éviter en permanence en prod

À ajouter, presque toujours :

• logs du reverse proxy / serveur web (ex : Traefik / Nginx) : accès, erreurs, temps de réponse
• logs PHP-FPM : erreurs, warnings, saturation
• logs DB (MySQL/MariaDB) : erreurs + slow queries (si activé)
• logs du moteur de recherche (OpenSearch/Elasticsearch) : pression mémoire, GC, temps de réponse

Objectif : pouvoir répondre à ces 4 questions en 2 minutes :

• qui (route / endpoint / user / back-office) ?
• quoi (erreur, timeout, saturation) ?
• quand (période, fréquence, corrélation avec déploiement) ?
• où (web, PHP, DB, recherche) ?

Côté sécurité, faites le tri entre journalisation utile et fuite d’informations. Bon complément : Sécuriser Magento 2 : patches, WAF, best practices.

3) Quoi monitorer en priorité (prod)

Expérience utilisateur (ce que vos clients ressentent)

• taux d’erreurs 5xx
• latence p95/p99 (front + API)
• pages clés : panier, checkout, recherche, compte

Sur un e-commerce, la recherche et le checkout sont souvent les premiers à souffrir.

Santé applicative (PHP / Magento)

• erreurs PHP (fatal, out-of-memory)
• saturation PHP-FPM (nombre de workers occupés, queue)
• temps des requêtes Magento les plus coûteuses

Base de données

• CPU/RAM
• connexions (pics, timeouts)
• requêtes lentes (top 10)

Cache / sessions

• hit ratio cache (si disponible)
• temps de réponse Redis

Recherche (OpenSearch/Elasticsearch)

• mémoire consommée (JVM)
• latence des requêtes
• erreurs d’indexation

Si vous souhaitez une base technique reproductible (HTTPS, persistance, cache, recherche), voir Installer Magento 2 avec Docker Compose (prod).

4) Centraliser les logs avec Elastic : stratégie simple

L’idée n’est pas de tout ingérer “au hasard”. L’objectif est de centraliser ce qui aide à diagnostiquer.

Étape A — Normaliser un minimum

• un format cohérent (idéalement JSON)
• un champ “service” (magento / web / php-fpm / db / recherche)
• un identifiant de corrélation (request id)

Même si tout n’est pas parfait, le fait d’avoir un champ request_id (ou équivalent) vous permet de relier :

• un 500 côté web
• une exception Magento
• une requête lente DB

Étape B — Expédier les logs

Deux schémas courants :

• expéditeur sur l’hôte (Filebeat) → Elastic
• conteneurs → stdout → agrégateur → Elastic

L’important : éviter de perdre les logs (rotation mal réglée, volumes non persistants, etc.).

Étape C — Créer 3 vues utiles

1. “Erreurs critiques” : exceptions, 5xx, timeouts
2. “Trafic & latence” : routes, top endpoints, p95
3. “Recherche & DB” : lenteurs, erreurs, saturation

Pour éviter de surdimensionner inutilement, relisez aussi Coûts d’hébergement Magento 2 : ce qui coûte (CPU/RAM) + 12 optimisations.

5) New Relic sur Magento : ce que ça apporte vraiment

New Relic est souvent choisi parce qu’il apporte :

• APM (traces de transactions, temps DB, erreurs)
• visibilité “end-to-end” (du navigateur au serveur)
• alertes prêtes à l’emploi

Le point clé : en APM, vous identifiez rapidement la transaction lente (par exemple un endpoint de recherche), puis vous descendez :

• temps passé en PHP
• temps DB
• appels externes

Ensuite, vous revenez dans Elastic (ou vos journaux) pour avoir le détail et le contexte.

Si vous cherchez une page d’entrée pour démarrer, le “quickstart Magento” New Relic donne une bonne idée des alertes standard (disponibilité, erreurs, performance).

Et si vous déployez Magento avec des conteneurs, assurez-vous aussi d’avoir une visibilité côté reverse proxy et base : c’est souvent là que les problèmes se manifestent en premier.

6) Alerting : comment éviter les alertes inutiles

Une alerte doit déclencher une action, pas de l’anxiété.

Règle 1 — Alerter sur des symptômes, puis sur des causes

Commencez par 3 alertes “symptômes” :

• taux d’erreurs 5xx (sur 5–10 min)
• latence p95 (sur 10 min)
• indisponibilité (healthcheck)

Puis ajoutez 3 alertes “causes” :

• saturation PHP-FPM
• DB lente / CPU DB élevé
• mémoire élevée côté moteur de recherche

Règle 2 — Utiliser des fenêtres de temps

Les pics e-commerce sont normaux. Privilégiez :

• une fenêtre glissante (ex : 10 min)
• un seuil raisonnable
• un “nombre minimum de requêtes” pour éviter de déclencher sur un petit trafic

Règle 3 — Avoir un runbook minimal

Pour chaque alerte, définissez :

• où regarder en premier (APM / journaux / métriques)
• la commande la plus utile (docker logs, métriques DB, etc.)
• la décision rapide (scale, rollback, purge cache, corriger config)

Ce point s’articule très bien avec une démarche de déploiement propre. Si vous déployez avec Docker Compose, gardez une procédure de redéploiement et de rollback claire (voir Installer Magento 2 avec Docker Compose (prod)).

Lancez-vous avec Magento.

Envie de vous lancer avec Magento ? Créez votre site web en quelques clics.

Magento

E-commerce enterprise

Déployer Magento

7) Mini plan d’action (priorités)

Si vous partez de zéro, faites dans cet ordre :

1. activer une journalisation fiable (Magento + web + PHP-FPM)
2. centraliser les logs (Elastic) avec un format cohérent
3. installer un APM (New Relic) pour les transactions lentes et les erreurs
4. mettre 6 alertes (3 symptômes + 3 causes)
5. tester une “panne” (erreur 500 volontaire, surcharge) pour valider le circuit

Déployer Magento plus simplement

Si votre objectif est de vendre, pas d’opérer des serveurs, vous pouvez déployer Magento avec :

• déploiement en 1 clic
• facturation à l’heure
• start/stop
• sauvegardes automatiques (24h par défaut, jusqu’à 1/h)
• rétention longue (jusqu’à 10 ans)
• scaling CPU/RAM à la demande

Découvrir : Magento sur adgents.cloud.