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
É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.