« Le make sait ce qu’il a fait à 14h32, mais il ne sait pas dans quel ordre. » Cette phrase, entendue lors d’un débogage difficile impliquant WordPress, un service de recherche externe et une file d’attente asynchrone, résume bien le problème que pose l’absence d’un identifiant commun entre les journaux de plusieurs services distincts. Chaque service loggue fidèlement ce qui le concerne, mais sans repère partagé, relier ces lignes entre elles pour reconstituer le parcours complet d’une requête reste un exercice de déduction approximative.
La solution mise en place ne concerne pas le choix de l’outil de centralisation des journaux lui-même, déjà en place par ailleurs, mais la manière de générer et de propager un identifiant de corrélation unique à travers l’ensemble des services impliqués dans le traitement d’une requête.
Générer l’identifiant au point d’entrée
L’identifiant de corrélation est généré une seule fois, au moment où la requête entre dans le système, généralement au niveau du serveur web ou, à défaut, dès le tout premier hook exécuté par WordPress. Un identifiant existant transmis par un service amont est réutilisé s’il est présent, sinon un nouveau est généré via wp_generate_uuid4(), fonction native de WordPress déjà utilisée à d’autres fins dans le cœur du logiciel.
<?php
add_action( 'init', function() {
if ( ! defined( 'CORRELATION_ID' ) ) {
$id_entrant = $_SERVER['HTTP_X_CORRELATION_ID'] ?? null;
define( 'CORRELATION_ID', $id_entrant ?: wp_generate_uuid4() );
}
}, 1 );
Cet identifiant, une fois défini, est disponible tout au long du cycle de traitement de la requête, sans avoir à le recalculer ou à le retransmettre manuellement d’une fonction à l’autre.
Propager l’identifiant vers les services appelés
Chaque appel sortant depuis WordPress vers un service externe, que ce soit une file d’attente, un service de recherche ou une API interne, transporte cet identifiant dans un en-tête HTTP dédié, nommé X-Correlation-Id. Ce nom d’en-tête n’est standardisé par aucune spécification officielle, mais sa convention s’est imposée par l’usage dans l’écosystème des architectures distribuées.
<?php
$reponse = wp_remote_post( 'https://recherche.interne.example/index', [
'headers' => [
'X-Correlation-Id' => CORRELATION_ID,
'Content-Type' => 'application/json',
],
'body' => wp_json_encode( $donnees ),
] );
Chaque service recevant cette requête relit l’en-tête à son tour, l’inclut dans ses propres lignes de log structurées en JSON, et le propage à son tour vers les services qu’il appelle éventuellement en aval.
Structurer les lignes de log pour rendre l’identifiant filtrable
Un identifiant de corrélation n’a d’intérêt que si les journaux sont structurés de manière à permettre un filtrage précis sur ce champ. Les journaux de WordPress ont donc été reformatés en JSON plutôt qu’en texte libre, chaque ligne comportant systématiquement les champs correlation_id, service, niveau et message.
{"correlation_id":"3f2a9c1e-...","service":"wordpress","niveau":"info","message":"Requête reçue sur /panier"}
{"correlation_id":"3f2a9c1e-...","service":"recherche","niveau":"info","message":"Index interrogé, 42 résultats"}
Cette structuration permet, dans l’outil de centralisation des journaux, de reconstituer en une seule recherche l’intégralité du parcours d’une requête à travers tous les services impliqués, dans l’ordre chronologique exact des événements survenus.
Une limite à connaître : les tâches asynchrones
Les tâches déclenchées via wp_schedule_single_event() ou traitées par une file d’attente externe s’exécutent en dehors du cycle de requête HTTP d’origine, ce qui coupe naturellement la propagation automatique de l’identifiant. Il a fallu ajouter explicitement l’identifiant de corrélation aux métadonnées de chaque tâche planifiée, pour qu’il reste disponible au moment de son exécution différée, parfois plusieurs minutes après la requête initiale.
En résumé
Un identifiant de corrélation propagé de bout en bout ne remplace pas le choix d’un outil de centralisation des journaux, il en démultiplie l’utilité. Sans lui, chaque service raconte sa propre histoire isolément ; avec lui, l’ensemble du parc raconte la même histoire, dans le bon ordre, pour chaque requête individuelle.
