🛠 La mise en service de LogAnalyzer nécessite deux sources de données : les logs quotidiens de vos serveurs web et le rapport de crawl de votre site. Le présent document décrit le processus d’installation, explique les éléments à fournir à Botify pour que notre équipe Support puisse effectuer cette mise en service puis fournit en annexe la check-list des informations attendues.
Processus d'intégration
Le processus de mise en service se réalise selon les étapes suivantes:
Fichiers dont Botify a besoin
Nous avons besoin de tous les fichiers de log de tous vos serveurs frontend qui reçoivent des requêtes des crawlers et des utilisateurs.
Si vous utilisez un CDN, deux possibilités:
soit tout votre trafic passe par votre CDN, auquel cas nous n'avons besoin que des logs de votre CDN,
soit une partie de votre trafic atteint directement votre site sans passer par le CDN, auquel cas vous avez besoin de nous envoyer les logs de vos serveurs web en plus des logs de votre CDN.
Contenu des logs serveur
Champs
Chaque ligne du fichier de log doit contenir:
Date : Date exacte de la requête avec de préférence la timezone (par exemple +0100
Exemple au format Apache : [Wed Oct 11 14:32:52 2000 +0100]
Exemple au format IIS : 2014-06-24 03:59:59
URL : L’URL complète avec les paramètres de la requête
Exemple au format Apache : "GET /cdn/H264-512x384/video/x8qujc.mp4?auth=1393905581-2-18kwwfcc-4a8a74d75a6e4e8575592bece46a8910 HTTP/1.1"
Exemple au format IIS : /world/communaute/moteur/googlepos/todo.asp Instance=jumbo-4&Version=20120717
Referer : Page de laquelle la connexion a été effectuée
User-Agent : Navigateur ou robot ayant émis la requête
HTTP Status Code : HTTP Status Code (code HTTP) de la réponse (200, 301, 404, etc...),
Domaine associé à l’URL : Si les logs contiennent des logs de sous-domaines différents, le virtual host (domain) associé à l’URL, soit dans l’URL, soit dans un champ séparé
Adresse IP du client : Si possible (optionnel), l’adresse IP du client pour les lignes de crawl (machine qui envoie la requête HTTP). Cette adresse IP nous permet de vérifier l’authenticité du User-Agent. Nous détectons les tentatives d’usurpation de User-Agent et ne traitons pas les lignes de log correspondantes
Protocole : Le protocole dans lequel est servi la page (http ou https), surtout si le site est en HTTPS, soit dans l’URL, soit dans un champ séparé
Ces champs sont tous contenus dans les formats par défaut d’Apache, nginx, Varnish et IIS.
Pour les serveurs non IIS, si cette configuration est possible sur vos serveurs, nous vous recommandons de configurer le Apache Combined Log Format sans aucun changement:
%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i"
Les logs peuvent contenir des commentaires commençant par un #.
Crawls
Nous détectons un passage de robot par le User-Agent présent dans les logs. Par défaut nous activons Google et ses sous-bots ainsi que Bing. Précisez-nous si vous souhaitez activer l’analyse des bots Yandex, Naver ou Baidu.
Voici un exemple de ligne de log correspondant à un passage de Googlebot :
forum.example.com 123.123.123.123 [17/Nov/2014:02:25:53 +0100] "GET /viewtopic.php?f=1&t=2&start=10 HTTP/1.1" "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 200 23066
Visites
Nous détectons une visite par le Referer présent dans les logs.
Nous attirons votre attention sur l’importance du Referer, indispensable pour la détection des visites et pour la qualité des données des rapports. Si vous passez par un CDN, il est possible que le Referer soit par défaut absent de vos fichiers de log. Nous vous encourageons à vérifier ce point et à leur demander l’activation de ce champ avant de nous transmettre vos premiers logs.
Si vous utilisez le service Google Ads, fournissez-nous les paramètres positionnés dans les URLs qui nous permettront d’identifier les visites SEA et de ne pas les traiter comme des visites SEO.
Voici un exemple de ligne de log correspondant à une visite depuis Google :
www.example.com 123.123.123.123 [17/Nov/2014:09:47:49 +0100] "GET /example/page.html HTTP/1.1" "http://www.google.fr" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0" 200 24230
Domaines
Si vos serveurs gèrent différents pays ou différents sites, les logs peuvent contenir des lignes n’appartenant pas au(x) domaines que vous souhaitez intégrer. Dans ce cas, indiquez-nous quels domaines nous devons conserver ou retirer des logs.
Protocole
Si nous n’êtes pas en mesure de nous préciser le protocole dans vos logs, dites-nous si nous devons prendre en compte toutes les URLs comme des URLs accédées en HTTP ou en HTTPS.
Mise à disposition des logs serveur
Introduction
Le traitement des logs de vos serveurs web nous permet d’analyser chaque jour le passage des robots des principaux moteurs de recherche sur votre site et de compter les visites SEO effectuées depuis les pages de résultats des moteurs de recherche.
Mise à disposition de l’ensemble des logs
Fichiers
Nous utilisons le sous-ensemble des lignes de log concernant les moteurs de recherche à monitorer. Vous pouvez au choix nous fournir ce sous-ensemble ou la totalité du contenu des fichiers de log.
Notez bien que nous avons besoin des logs de l’ensemble de vos serveurs web, y compris les serveurs de cache le cas échéant.
Le chemin complet de chaque fichier de log doit être unique à travers le temps. Lors du dépôt quotidien, les nouveaux fichiers ne doivent pas remplacer les fichiers précédents.
Chaque fichier de logs doit être compressé individuellement dans un des formats suivants : gzip, bzip2, zip, xz. Nous n’acceptons pas les formats suivants : fichiers zip contenant plusieurs fichiers, tar.gz, 7zip ou rar.
Les noms de fichiers ne doivent pas contenir d'espaces.
Volume
Il n’y a pas de limite théorique à la quantité de logs que vous pouvez déposer.
Si vous prévoyez de déposer plus de 200Go par jour, nous apprécions d’être prévenus afin de pouvoir l’anticiper.
Notre système gère des fichiers de taille maximale 5GB par fichier. Si vous nous envoyez des fichiers individuels plus gros, nous ajoutons en début de process une étape de découpage des fichiers. Ceci ajoute un délai de traitement, aussi bien au moment du setup initial que pour chaque mise à jour quotidienne.
Filtrage
Au début du traitement d'un fichier de log, Botify exécute un processus de filtrage qui supprime toutes les lignes de log qui ne sont ni des lignes de crawl ni des lignes de visites, puis un processus d'anonimyisation qui supprime toutes les adresses IP des lignes de visites. Le résultat est un fichier réduit à sa taille minimal et anonymisé, qui est ensuite traité à nouveau pour obtenir les données SEO affichées dans l'application.
Vous pouvez choisir que ce traitement de filtrage et d'anonymisation ait lieu dans l'Union Européenne ou aux Etats-Unis.
Si vous choisissez de filtrer et d'anonmyiser de votre côté avant de nous envoyer les logs, afin de réduire le volume de données transférées et d'anonymiser de votre côté, voici les étapes:
masquage de l’adresse IP pour les lignes de logs qui ne sont pas des lignes de crawl
Nous fournissons des scripts d’exemple pour ces étapes, à adapter selon votre infrastructure et vos technologies:
Mise à disposition
Botify propose deux méthodes pour obtenir les logs serveur :
soit le client dépose les logs dans un dépôt FTP/FTPS/SFTP,
soit Botify va récupérer les logs sur un partage AWS S3.
FTP/FTPS/SFTP
Pour déposer les logs, nous avons mis en place un espace de stockage privé .upload.botify.com pour votre organisation, accessible au choix en FTP, FTPS ou SFTP
pour FTP/FTPS, avec un mot de passe que nous vous transmettons par ailleurs.
pour SFTP, nous vous demandons de nous transmettre la clé publique que vous utiliserez pour déposer les logs.
Merci de déposer les logs dans le sous-répertoire logs de ce dépôt, sans créer de sous-répertoires, en respectant le nommage suivant : YYYYMMDD.<référence du serveur>.log..
Exemple :
logs/20150130.webserver1.log.gz logs/20150130.webserver2.log.gz logs/20150130.webserver3.log.gz logs/20150130.webserver4.log.gz logs/20150131.webserver1.log.gz logs/20150131.webserver2.log.gz logs/20150131.webserver3.log.gz logs/20150131.webserver4.log.gz ...
Quelques précisions techniques:
Le dépôt en FTP utilise les ports 20 et 21.
Notre configuration FTPS est plus précisément une configuration "FTP over TLS" mise en place sur un serveur pure-ftpd. Cette configuration utilise le port 21 pour le channel "command" et des ports aléatoires pour les channels "data". Pour plus d’informations techniques sur TLS et les clients qui le supportent, vous pouvez vous référer à la page http://download.pureftpd.org/pure-ftpd/doc/README.TLS.
Si vous voulez restreindre les flux, notre conseil est d'effectuer une restriction par IP sur l'adresse IP de .upload.botify.com.
AWS S3
Botify peut récupérer les fichiers de logs sur un partage AWS S3 dès lors que vous mettez en place la structure de logs et les autorisations adéquates.
Pour cela, vous devez créer un utilisateur AWS dédié et une paire de clés correspondantes (AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY), avec les autorisations sur les actions "s3:List" et "s3:Get", sur votre bucket et toute l'arborescence qui en dépend.
Exemple de politique IAM correspondant à cela :
{ "Id": "Policy1488876114416", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1488875932621", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::mon-bucket/*", "arn:aws:s3:::mon-bucket" ] } ] }
Une fois l'autorisation en place, fournissez-nous simplement :
les deux clés AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY du compte que vous aurez créé,
le nom de la région AWS où se trouve le bucket,
le nom du bucket,
l'heure de la journée à laquelle les logs doivent être rapatriés,
toutes les informations éventuelles pour déterminer quels fichiers rapatrier (sous-dossier, filtre à appliquer sur le début du nom des fichiers, …)
Botify utilisera ces informations pour récupérer les logs à heure régulière.
Notez que si le bucket ou sous-dossier contient beaucoup de fichiers et qu’il n’est pas possible de cibler les fichiers sur leur préfixe, il sera impossible à Botify de récupérer les fichiers.
Dès que Botify reçoit les premiers fichiers, nous vérifions le contenu pour s’assurer:
que nous supportons le format,
que les informations nécessaires sont bien contenues dans les données que vous nous envoyez (ensemble des champs attendus + présence d’au moins une ligne de robot et une ligne de visites).
Validation
Validation des volumes
Une fois l’accès au dashboard de logs transmis, nous avons besoin de la validation du client sur le fait que les volumes de données analysées correspondent au volume de données attendu. Nous vous remercions d’inspecter :
le nombre de visites SEO sur une journée
le nombre de pages actives sur une journée
le crawl total de Google sur une journée
le crawl unique de Google sur une journée et de nous confirmer que les volumes correspondent à vos attentes.
Validation des URLs et des Domaines
Merci de vérifier que les URLs et les domaines inclus dans votre dashboard correspondent à vos attentes (dans l’URL Explorer, filtrer sur “URL does not contain” et lister les domaines auxquels vous vous attendez, pour vérifier que toutes les URLs correspondent bien au périmètre souhaité).
En l’absence de confirmation de votre part sous une semaine, nous considérons que les données sont cohérentes.
Dépôt récurrent
En cas de dépôt quotidien, il est nécessaire que vous nous donniez accès chaque nuit aux données de logs de la veille.
Horaires
Nous prenons en compte les logs déposés toutes les 6 heures. Vous pouvez déposer vos logs sans contrainte horaire. Le délai de mise à disposition dans le rapport de logs dépend de votre volume de données, il est habituellement de moins d’1 heure après prise en compte si la segmentation n’a pas été modifiée depuis la prise en compte précédente.
En cas de changements
Nous avons besoin que vous nous préveniez de tout changement :
changement de format pour les noms de fichier
changement de format dans le contenu des fichiers
ajout de nouveaux types de fichiers à prendre en compte (nouveaux patterns de noms dans le répertoire de dépôt)
changement dans l’heure de dépôt. Nous avons également besoin que vous vérifiiez ne pas déposer de fichiers vides.
Crawl du site
Le passage de notre crawler nous permet de visiter chacune des pages dans la structure du site et de vous en livrer tous les détails SEO. Par défaut nous respectons les mêmes règles que Googlebot (robots.txt, no-follow, ajax, javascript).
Prérequis au niveau des logs
Nous croisons le crawl avec les logs serveur pour fournir un rapport sur le site et les visites. Pour que le rapport soit intéressant, nous vous recommandons de déclencher le crawl lorsque Botify dispose de 30 jours de log.
Mode opératoire
Vous pouvez lancer le crawl vous-même sur votre projet de logs. Le rapport de crawl sera un rapport “Botify Analytics” agrémenté des données de logs, dans l’URL Explorer et présentées dans un onglet dédié nommé Search Engines.
Vous configurez les paramètres de crawl dans votre projet présentant l’analyse de logs :
URL de départ (vous pouvez éventuellement en configurer plusieurs, ce qui est typiquement intéressant pour des sites multilingues afin de ne pas introduire de décalage entre langues lors des comparaisons de profondeur),
Protocoles à crawler (http, https ou les deux),
User-Agent : par défaut, notre user-agent est le suivant : Mozilla/5.0 (compatible; botify; http://botify.com). Si vous avez besoin que nous présentions un autre user-agent que celui-ci, merci de le configurer. Cela peut être utile en particulier si vous avez personnalisé votre fichier robots.txt en fonction des crawlers et que vous souhaitez que l’on suive le comportement d’un bot particulier.
Sous-domaines à inclure (selon ce qui vous intéresse en termes de comparaison de profondeurs, vous pourriez souhaiter ajouter la page d’accueil de certains sous-domaines en URLs de départ - typiquement pour les langues),
Sous-domaines à exclure et optionnellement, règles d’exclusion de certaines URLs, complémentaires à celles présentes dans le fichier robots.txt. Nous vous recommandons de définir avec attention les sous-domaines ou les URLs à exclure du périmètre du crawl. Deux cas que nous rencontrons fréquemment :
le cas des sous-domaines en “marque blanche” : si le crawler entame l’exploration de parties du site qui ne vous appartiennent pas, il sera très probablement blacklisté et cela faussera les résultats du rapport,
le cas des sous-domaines ou des URLs correspondant à des images : img.example.com ou www.example.com/image/url.png : sauf cas métier particulier, le crawler n’a probablement pas d’intérêt à parcourir ces images et le rapport s’en retrouvera complexifié sans valeur ajoutée.
Conseil : pour déterminer les sous-domaines à inclure ou exclure, nous vous recommandons de les confirmer avec la commande site dans la barre de recherche de Google :
site:example.com, regardez les premiers résultats, excluez-les pour en découvrir d‘autres,
site:example.com -inurl:fr.example, et poursuivez l’exclusion
site:example.com -inurl:fr.example -inurl:de.example , etc. Pour chaque domaine découvert, décidez si vous le souhaitez ou non dans le périmètre.
❗️Important
une fois le crawl lancé, ces paramètres ne sont plus modifiables.
Si vous avez mis en place des paramétrages particuliers sur votre site pour le crawler de Google (cloaking, par exemple via un cookie de session paramétré), assurez-vous de traiter de la même manière le crawler de Botify.
Exécution du crawl
Vous lancez le crawl à l’heure que vous souhaitez, ou planifiez le crawl pour qu’il démarre la nuit. Le crawl est lancé depuis une adresse IP AWS US East Coast (Northern Virginia). Vous pouvez ajuster la vitesse de crawl à tout moment pendant le crawl. Le crawl a une durée maximale de 25 jours calendaires.
Contact Support
En cas de question, contactez le Support.
Annexe
Check-list des éléments à nous fournir pour l’analyse de logs.
Dans tous les cas :
slug souhaité pour vous connecter au dépôt ftp ( .upload.botify.com )
activation ou non de l’analyse du bot Yandex,
activation ou non de l’analyse du bot Naver,
activation ou non de l’analyse du bot Baidu,
domaines à inclure dans le projet,
protocole à ajouter aux URLs s’il est absent des logs,
exécution du traitement d'anonymisation en Union Européenne ou aux Etats-Unis,
indiquer si vous souhaitez filtrer les visites sur certains paramètres d'URLs (ex: paramètres spéciaux pour identifier des pubs Adwords...).
En cas d’analyse récurrente :
heure estimée de fin de dépôt des logs chaque nuit,
liste des adresses email auxquelles envoyer le rapport quotidien.
Bien vérifier auprès de vos équipes techniques que vous déposez la totalité des logs, en particulier :
si vous avez plusieurs serveurs web,
si vous utilisez du cache HTTP (Varnish),
si vous avez des données délivrées par des systèmes externes (CDN typiquement).