Comment comparer le trafic en direct d’Astrina avec les journaux du serveur
Comparer le trafic en direct d’Astrina avec les journaux du serveur semble simple jusqu’à ce que la première divergence apparaisse. Un rapport indique 18 visites. Le journal affiche 24 requêtes. Cet écart a généralement une explication, et cette explication est souvent ennuyeuse dans le meilleur sens du terme : une redirection, un bot, un proxy ou un horodatage décalé de 60 secondes.
Le but n’est pas de forcer les deux chiffres à coïncider à tout prix. Le but est de rendre la comparaison assez honnête pour qu’on puisse lui faire confiance. Si vous voulez savoir comment comparer le trafic en direct d’Astrina avec les journaux du serveur, commencez par réduire le problème avant de commencer à contester les chiffres. Dans la pratique, cela revient souvent à comparer Astrina aux journaux serveur avec une méthode stable, puis à corréler trafic en direct Astrina et logs serveur avant de tirer des conclusions.
1. Confirmez le périmètre des journaux serveur avant de comparer
Choisissez d’abord les fichiers journaux exacts. Beaucoup d’équipes mélangent le trafic de production, de staging et de prévisualisation dans un seul tableur, puis se demandent pourquoi Astrina affiche un schéma et le serveur un autre. Gardez un seul site, un seul environnement et une seule tranche de trafic. Cela signifie nommer clairement l’hôte, l’application et la source des journaux avant toute autre chose.
Si votre serveur écrit plusieurs fichiers par jour, notez la règle de rotation. Si vous avez des journaux séparés pour l’edge du CDN et pour le serveur d’origine, choisissez un seul chemin et tenez-vous-y pour le premier passage. Un périmètre propre simplifie tout le reste. Un périmètre confus rend chaque écart suspect.
Exemple pratique : comparez uniquement www.example.com en production, uniquement les requêtes de pages, et uniquement les dernières 24 heures. N’ajoutez pas le trafic API, les contrôles de santé ni les URL d’administration dans la même comparaison. Ce sont d’autres catégories de trafic.
2. Choisissez une fenêtre temporelle exacte et normalisez les horodatages
Le trafic en direct d’Astrina fonctionne mieux lorsque la fenêtre est précise. Les journaux serveur aussi. Utilisez le même minute de début et la même minute de fin des deux côtés, pas “vers midi” ou “quelque temps après le déjeuner”. Un découpage à la minute près compte, car une requête à la limite peut faire bouger le total.
Utilisez un seul fuseau horaire pour les deux côtés. Si Astrina affiche l’UTC et que vos journaux serveur sont en heure locale, la comparaison échouera avant même de commencer. Convertissez les horodatages des journaux une seule fois, puis conservez ce format pendant toute l’analyse. Un décalage de 15 minutes peut créer un faux pic. Un décalage d’une heure peut donner l’impression que les données sont corrompues.
Voici une règle simple qui fait gagner du temps : ne comparez jamais une fenêtre glissante Astrina de 5 minutes avec un extrait de journal sur une journée civile. Cela semble évident. Les gens le font quand même. Choisissez une fenêtre, notez-la, et utilisez-la partout.
3. Filtrez les journaux serveur pour ne garder que les requêtes de pages humaines
Les journaux serveur contiennent tout, et c’est là le problème. Images, CSS, bundles JavaScript, requêtes de favicon, préchargements et hits de robots s’y mêlent aux visites de pages. Astrina compte généralement les visites de pages, donc le journal doit être réduit au même type de requête.
Retirez d’abord les ressources statiques. Ensuite, supprimez les contrôles de santé, les sondes de disponibilité, les endpoints d’administration et les outils internes. Si votre répartiteur appelle /health chaque minute, ces lignes peuvent fausser rapidement les totaux. Une page comme /pricing ne devrait pas être comparée à 400 requêtes de ressources et trois ping de surveillance.
Le filtrage des bots mérite aussi de l’attention. Certains bots ont l’air humains pendant quelques secondes, et certains navigateurs paraissent robotiques à cause de leur user-agent. Ne vous fiez pas à un seul signal. Utilisez, si possible, une combinaison du chemin de requête, du user-agent et des plages d’IP internes connues. Si votre journal inclut un marqueur “bot” provenant d’un WAF ou d’un proxy inverse, conservez cette étiquette. Elle sera utile plus tard.
4. Faites correspondre les champs d’Astrina aux champs du journal
Créez une carte simple des champs avant d’essayer de faire correspondre les enregistrements. Astrina peut afficher un horodatage, un chemin de page, un référent et un identifiant de type session. Le journal peut afficher la ligne de requête brute, le code de statut, le user-agent et l’adresse IP. Ce n’est pas la même chose, et il ne faut pas les traiter comme si c’était le cas.
Faites un tableau à deux colonnes sur papier ou dans un tableur. À gauche : champ Astrina. À droite : champ du journal. L’horodatage correspond à l’horodatage, le chemin correspond au chemin de requête, le référent à l’en-tête Referer, et le user-agent à la chaîne user-agent. Les identifiants de type session sont plus délicats, car le journal serveur peut ne pas en contenir du tout. Ce n’est pas un échec. C’est simplement une limite.
| Champ Astrina | Champ de journal le plus proche | Notes |
|---|---|---|
| Horodatage | Heure de la requête | Convertir d’abord vers un seul fuseau horaire |
| Chemin de page | Chemin d’URL | Supprimer les chaînes de requête pour le regroupement |
| Référent | En-tête Referer | Peut être absent ou tronqué |
| User-agent | Chaîne user-agent | Utile pour les vérifications de bots |
N’attendez pas que chaque champ Astrina ait un champ équivalent dans le journal. Certaines valeurs sont déduites. Certaines sont modélisées. Certaines ne figurent tout simplement pas dans le journal serveur. C’est pourquoi la carte est importante : elle indique où la comparaison directe est possible et où elle n’est qu’approximative.
5. Reconcilez le trafic par chemin d’URL, pas par ligne de requête brute
Les lignes de requête brutes sont bruyantes. Une visite vers /docs peut apparaître comme /docs, /docs/ ou /docs?utm_source=newsletter. Si vous comparez ces chaînes littéralement, vous diviserez une page en trois. Astrina normalise peut-être déjà une partie de cela. Votre journal, probablement pas.
Utilisez des chemins canoniques. Regroupez toutes les variantes sous le même chemin de page avant de comparer les compteurs. Supprimez les chaînes de requête si elles ne font pas partie de l’identité de la page. Fusionnez les slashs finaux lorsque le site traite ces variantes comme la même page. Si des redirections interviennent, comptez la destination finale, pas le premier saut.
Cette étape révèle souvent une surprise. Une page avec 50 visites Astrina peut afficher 63 entrées dans le journal, car 13 requêtes ont d’abord touché la version non canonique puis ont été redirigées. Ce n’est pas une erreur de trafic. C’est un problème de chemin. Corrigez la règle de regroupement avant de modifier l’interprétation.
6. Vérifiez les écarts causés par le cache, les proxies ou les CDN
Les couches intermédiaires modifient ce qui atteint le serveur d’origine. Un CDN peut répondre à la requête avant même que l’origine ne la voie. Un proxy peut réécrire les en-têtes. Un hit de cache peut servir une page à un utilisateur sans laisser de ligne correspondante dans l’origine. Cela signifie qu’Astrina peut voir une visite tandis que le journal serveur reste muet.
L’inverse peut aussi se produire. Le journal d’origine peut enregistrer une requête qu’Astrina ne compte jamais parce que le navigateur n’a pas fini de charger la page, que le script a été bloqué ou que la requête a eu lieu avant l’exécution du code de suivi. Une page de test rapide peut rendre cela évident. Ouvrez la page dans un navigateur, inspectez l’onglet réseau et voyez si la requête de suivi part avant la fin du chargement.
Si vous utilisez un CDN, vérifiez si la source du journal est l’edge ou l’origine. Ce sont des enregistrements différents. Une réponse 304, une réponse HTML mise en cache ou un objet obsolète en edge peuvent tous produire de fausses différences. C’est là qu’une courte note dans votre feuille de comparaison vous fera gagner une heure plus tard.
Pour les équipes qui configurent le traceur pour la première fois, le chemin d’installation compte aussi. La configuration de l’agent est plus facile à vérifier si vous suivez la même méthode de déploiement que celle utilisée en production, ce qui explique pourquoi de nombreuses équipes gardent le guide d’installation dans leur runbook, à côté du script d’export des journaux.
7. Utilisez un journal court des écarts pour classer chaque différence
Ne laissez pas les divergences sous forme de cellules rouges anonymes. Rédigez un journal des écarts avec une ligne par différence. Donnez une catégorie à chaque ligne. Cinq catégories suffisent généralement au départ : bruit de bot, couverture de journal manquante, ingestion retardée, doublons de hits et problème de normalisation de chemin.
Voici un format simple : chemin de page, compteur Astrina, compteur du journal, taille de l’écart, catégorie, note. Cette note doit mentionner une cause concrète, pas une impression. “Le CDN a servi du HTML mis en cache” est utile. “Ça a l’air bizarre” ne l’est pas. Si un écart se répète sur trois pages, c’est un indice. S’il n’apparaît qu’une fois, c’en est aussi un, juste plus petit.
Une équipe peut découvrir qu’un écart de 12 requêtes est causé par un retard d’acheminement des journaux. Une autre peut constater qu’une extension de navigateur bloque le script de suivi sur les appareils internes. Une troisième peut apprendre que le serveur écrit des lignes en double en cas de nouvelle tentative. Les catégories évitent de traiter chaque divergence comme la même panne.
Si vous voulez un cadre opérationnel plus approfondi pour ce travail, astrina pour les équipes produit internes qui suivent peut être un complément utile, surtout lorsqu’un écart de trafic est en réalité lié à un déploiement.
8. Relancez la comparaison sur un petit échantillon avant de passer à l’échelle
Commencez par une page ou une journée. Pas dix pages. Pas un mois entier. Un seul échantillon force à expliciter les règles, ce qui est une bonne chose. Si l’échantillon contient uniquement /pricing, vous pouvez examiner chaque divergence à la main et voir si la méthode tient.
Cherchez la stabilité avant l’ampleur. Si le même filtre, la même règle de chemin et la même fenêtre temporelle donnent deux fois la même réponse, passez à une deuxième page. Si les chiffres changent quand vous ajoutez un jour de plus, arrêtez-vous et vérifiez si un déploiement, un changement de cache ou une rotation de journaux a eu lieu au milieu. Un petit échantillon est plus rapide à corriger qu’un grand.
Il y a ici une discipline utile : ne modifiez qu’une seule variable à la fois. Passez d’une page à trois pages, ou d’un jour à deux jours, mais pas les deux en même temps. Sinon, vous ne saurez pas quelle modification a cassé l’accord. Cela semble lent. C’est plus rapide que de revenir en arrière à travers 40 lignes d’hypothèses erronées.
Les équipes qui migrent depuis un autre outil d’analyse voient souvent le même schéma pendant le travail de transition. Si c’est votre cas, comment migrer depuis plausible est une référence pratique à garder ouverte pendant que vous vérifiez le premier échantillon avec les journaux.
Que vérifier lorsque les chiffres ne s’alignent toujours pas
Si la comparaison semble toujours erronée après les huit étapes ci-dessus, inspectez trois éléments dans cet ordre : la source du journal, la règle de chemin et la fenêtre temporelle. Ne sautez pas directement au script de suivi. Un nombre surprenant de “bugs de tracking” sont en réalité des bugs d’extraction de journaux. Une autre cause fréquente est une redirection oubliée de /page vers /page/.
Vérifiez aussi si la session du navigateur se termine avant la fin de la requête de suivi. Les connexions mobiles sont plus fragiles que les connexions desktop. Une page peut se charger visiblement pendant que l’appel analytique est annulé. Cela laisse à Astrina moins de visites que le journal serveur. L’inverse peut se produire lorsque le navigateur réessaie une requête et que le serveur compte les deux tentatives.
Un autre détail : si votre site possède une page ou un mode de maintenance, traitez ce trafic à part. Un événement de maintenance modifie à la fois le comportement des utilisateurs et la forme des journaux. Si vous avez besoin d’une référence complémentaire pour cette situation, que faire quand la disponibilité d’Astrina peut aider à cadrer l’incident avant de le comparer aux journaux.
Les comparaisons les plus solides sont petites, documentées et reproductibles. Un périmètre propre, une fenêtre temporelle unique, des requêtes de pages filtrées et des chemins canoniques expliqueront généralement la majeure partie de l’écart. La différence restante est l’endroit où se trouve le travail utile. C’est aussi là qu’il faut analyser les écarts entre Astrina et les journaux serveur pour décider s’il s’agit d’un problème de suivi, de cache ou de normalisation.
