Aller au contenu
NessFlow
Menu

Récupérer vos journaux Cloudflare avec Logpush

Cloudflare répond à la place de votre serveur pour une partie du trafic. Voici comment obtenir ses propres journaux, et ce qui manque quand on ne prend que ceux de l’origine.

L’équipe NessFlow (Ingénierie produit, NessFlow) · · 2 min de lecture

Capture de l’écran Couverture des journaux analysés de NessFlow, sur un jeu de démonstration.

Écran réel du produit, rendu sur un jeu de démonstration fictif : les chiffres affichés ne sont ceux d’aucun client.

Quand un site passe derrière Cloudflare, une partie des requêtes ne touche jamais le serveur d'origine : elles sont servies depuis le cache. Les journaux de l'origine décrivent donc ce qui est passé au travers, pas ce que les moteurs ont demandé. Sur un site bien mis en cache, l'écart est considérable, et il porte précisément sur les pages les plus populaires.

Ce que Logpush apporte

Logpush envoie les journaux de Cloudflare vers un stockage que vous choisissez, à intervalle régulier. C'est la seule source qui voie l'intégralité des requêtes, cache compris.

La fonctionnalité demande un plan payant. Sur un plan gratuit, la seule voie reste les journaux de l'origine, avec la réserve ci-dessus : ils sous-comptent le trafic des robots sur exactement les pages que vous voulez surveiller.

Créer le job

Dans le tableau de bord, ouvrez le domaine concerné, puis la section Analytics & Logs, puis Logpush. Créez un job sur le jeu de données HTTP requests, et choisissez une destination : un stockage objet compatible S3, un bucket Google Cloud Storage, ou un simple point de collecte HTTP.

Le format de sortie est du JSON, une requête par ligne. C'est ce que l'assistant d'import attend quand vous déclarez Cloudflare comme origine.

Les champs qui comptent

Le sélecteur propose plusieurs dizaines de champs, et la tentation est de tous les cocher. Cinq suffisent à une analyse de fréquentation, et en cocher moins allège beaucoup le volume transféré.

  • EdgeStartTimestamp, l'horodatage de la requête ;
  • ClientRequestHost, indispensable si le job couvre plusieurs domaines ;
  • ClientRequestURI, le chemin demandé ;
  • EdgeResponseStatus, le code de statut réellement servi ;
  • ClientRequestUserAgent, sans lequel aucun robot n'est identifiable.

Deux champs méritent une décision explicite. ClientIP n'est utile à aucune analyse de fréquentation, et une adresse est une donnée personnelle : le plus simple est de ne pas l'exporter du tout. CacheCacheStatus, en revanche, vaut la peine : il dit quelle part de vos pages n'atteint jamais l'origine, ce qui est justement la raison d'utiliser Logpush.

Une période à couvrir

Un job Logpush démarre au moment où vous le créez, il ne remonte pas dans le passé. Comptez donc quelques jours entre la configuration et une première analyse qui vaille la peine. Un cycle d'exploration complet demande souvent plus qu'une semaine sur un site de taille moyenne.

Ensuite

Les fichiers arrivent compressés et se déposent tels quels. Si votre job couvre plusieurs domaines, l'analyse écarte d'elle-même les lignes qui concernent les autres hôtes, en s'appuyant sur le champ ClientRequestHost.

Pour ce qu'on tire ensuite de ces données, voyez notre guide sur l'analyse de journaux serveur. Les robots que nous savons reconnaître sont listés dans le répertoire des robots.

Capture de l’écran Origine des journaux à importer de NessFlow, sur un jeu de démonstration.

tutoriel

Exporter les journaux W3C de Microsoft IIS

IIS écrit un format à en-tête, dont les colonnes se choisissent une par une. Voici celles qui comptent, et la case qui manque presque toujours.

L’équipe NessFlow · · 2 min de lecture

Commencez par une mesure, pas par une promesse

Lancez un audit sur votre site et lisez ce que le moteur trouve. Si vous avez besoin d’un cadrage, demandez une démo : nous la faisons sur votre site, avec vos propres URL à l’écran.

Les accès s’ouvrent par vagues, nous prévenons par e-mail.