curl -X POST vers l’endpoint Sentry, exécuté à chaque requête, avec un payload qui pesait en moyenne 42 Ko avant intervention. Sur un WooCommerce à fort trafic générant plusieurs dizaines de requêtes par seconde aux heures de pointe, ce volume cumulé de données envoyées au service de remontée d’erreurs représentait une charge réseau et CPU non négligeable, entièrement invisible dans les métriques habituelles de performance front.
Symptôme : un payload qui grossit sans rapport avec le trafic d’erreurs réel
Le nombre d’erreurs réellement remontées par Sentry restait stable, de l’ordre de quelques dizaines par jour. Ce qui augmentait, en revanche, c’était le poids moyen de chaque payload envoyé, y compris pour des requêtes qui ne généraient aucune erreur. Le SDK Sentry PHP journalise en effet des « breadcrumbs », des traces d’événements internes (requêtes SQL exécutées, appels HTTP sortants, hooks WordPress déclenchés) qui s’accumulent tout au long du traitement d’une requête, dans l’idée de fournir un contexte utile en cas d’erreur ultérieure.
Diagnostic : des breadcrumbs par défaut bien trop verbeux
En inspectant la configuration active, l’intégration SQL du SDK journalisait chaque requête MySQL exécutée, avec sa chaîne complète, ses paramètres liés, et son temps d’exécution, comme breadcrumb distinct. Sur une page produit WooCommerce typique, qui exécute facilement 80 à 120 requêtes SQL (métadonnées produit, variations, avis, produits associés), cela représentait autant de breadcrumbs générés à chaque affichage, indépendamment de toute erreur :
[Sentry\Breadcrumb]
category: "db.query"
message: "SELECT * FROM wp_postmeta WHERE post_id = %d AND meta_key = %s"
data: { params: [4821, "_stock_status"], duration_ms: 2.4 }
Multiplié par une centaine de requêtes SQL par page, le payload transmis à Sentry pour chaque transaction gonflait mécaniquement, alors que l’immense majorité de ces breadcrumbs SQL ne serait jamais consultée : elles ne servent que si une erreur survient effectivement pendant cette même requête.
Correctif : filtrer par catégorie et par fréquence
La solution retenue consiste à intercepter chaque breadcrumb avant son ajout via le callback before_breadcrumb, pour écarter les catégories les plus verbeuses tout en conservant celles réellement utiles au diagnostic (navigation, clics, erreurs applicatives) :
\Sentry\init([
'dsn' => SENTRY_DSN,
'before_breadcrumb' => function ( \Sentry\Breadcrumb $breadcrumb ) {
if ( 'db.query' === $breadcrumb->getCategory() ) {
// Ne garder que les requêtes lentes, qui ont une vraie
// valeur diagnostique en cas d'erreur.
$duration = $breadcrumb->getMetadata()['duration_ms'] ?? 0;
if ( $duration < 50 ) {
return null; // supprime ce breadcrumb
}
}
return $breadcrumb;
},
]);
Ce filtre conserve uniquement les requêtes SQL dont la durée dépasse 50 millisecondes, celles qui présentent un intérêt réel en cas d’erreur ou de lenteur applicative, et élimine la masse des requêtes rapides et sans incident qui ne faisaient qu’alourdir chaque payload.
Résultat mesuré
Après application de ce filtre, le poids moyen du payload envoyé à Sentry est passé de 42 Ko à environ 9 Ko par transaction, soit une réduction de 78 %. Le nombre de breadcrumbs utiles conservés en cas d’erreur réelle n’a pas varié : les requêtes lentes, les appels HTTP sortants en échec et les erreurs applicatives continuent d’être journalisés avec le même niveau de détail qu’avant.
Prévention : revoir la configuration par défaut avant mise en production
- Ne jamais garder les intégrations Sentry sur leurs réglages par défaut sur un site à fort trafic sans avoir mesuré le poids réel du payload généré.
- Filtrer systématiquement les breadcrumbs de catégorie
db.querypar seuil de durée plutôt que de tout journaliser. - Revoir périodiquement la liste des intégrations actives : certaines (comme le suivi détaillé des requêtes HTTP sortantes) peuvent être désactivées si elles ne sont jamais consultées en pratique.
Un outil de remontée d’erreurs ne doit journaliser que ce qui aura une chance raisonnable d’être utile un jour. Le reste n’est que du poids ajouté à chaque requête.
En résumé
Sur un WooCommerce à fort trafic, les breadcrumbs par défaut de Sentry peuvent représenter une charge non négligeable, invisible dans les tableaux de bord de performance classiques mais bien réelle en CPU et en volume réseau. Filtrer ces breadcrumbs par seuil de pertinence, via before_breadcrumb, réduit fortement ce coût sans sacrifier la capacité de diagnostic en cas d’erreur applicative réelle.
