Tous les formats sont supportés. Par défaut, l'analyseur est configuré pour analyser des logs apache au format par défaut. La plupart des serveurs webs utilisent ce format par défaut (comme nginx). Cependant, vous pouvez modifier ce format (voir ci-dessous).
Les formats de compression suivants sont supportés : gzip, bzip, zip, rar. Les logs non compressés sont également acceptés.
Vous pouvez uploader le log intégralement, ou juste le trafic des robots. Nous vous conseillons d'uploader votre fichier log en entier, sinon, vous manquerez des métriques très intéressantes comme, le page speed, les pages inactives, le trafic, le trafic organique...
Avant votre premier upload, ou après une modification de la configuration, vous devez utiliser le log tester afin de vérifier que votre fichier log est correctement parsé.
Le format des logs peut être modifié dans la page de configuration du site. Indiquer le type de serveur web ainsi que la directive "log format" utilisée.
Apache : Indiquer la directive LogFormat du fichier de configuration Apache. N'oubliez pas de corriger les quotes. \" doit être remplacé par ".
Voici un exemple de directive correct pour Apache :
%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i"
IIS : IIS doit être configuré pour utiliser le format de log W3C extended. La directive du format de log est indiquée par le champ #Fields en entête de chaque fichier log.
Voici un exemple de directive correct pour IIS :
date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status cs(User-Agent) cs(Referrer)
Nginx et autres serveurs: Il est possible de représenter le format des logs d'autres serveurs en utilisant les directives Apache ou IIS.
Les champs suivants doivent être présents dans les fichiers logs :
Si vous souhaitez voir les informations concernant le page speed, vous devez activer l'enregistrement du temps d'exécution des requêtes dans les fichiers log.
%D dans la directive LogFormat du serveur.$request_time dans la directive log_format du serveur. Ensuite, vous pouvez traduire la variable nginx $request_time au format Apache en la remplaçant par la variable%d dans la configuration de l'analyseur de logs.time-taken.L'envoi des logs s'effectue en deux étapes : l'upload et le parsing.
Vous pouvez envoyer vos logs via le site web (page upload) ou bien en utilisant l'API (plus intéressant pour les uploads récurrents).
Lors de l'upload, vos fichiers logs n'ont pas besoin d'être triés par date. Vous pouvez les uploader dans le désordre. Si votre site est hébergé sur plusieurs serveurs web, cela ne devrait pas poser de problème.
Cependant, il y a quelques restrictions concernant la date des logs, il est impossible d'uploader des logs :
Pour le moment, il est impossible d'uploader plusieurs fichiers de logs en parallèle.
Si vous avez uploadé un fichier de logs par erreur (doublon ou date incorrecte), vous pouvez l'effacer sur la page uploads. Seuls les logs qui n'ont pas été envoyés à l'analyseur peuvent être effacés.
Le rôle du parsing est de séparer et trier les logs par jour. Ce tri est effectué automatiquement par l'analyseur de logs, inutile de trier en amont vos fichiers de logs.
Une fois tous vos fichiers de logs uploadés, vous pouvez déclencher le parsing en cliquant sur le bouton "Parse uploaded logs" de la page uploads ou via l'API.
Une fois le parsing effectué, chaque jour sera analysé, sauf le dernier. (C'est pourquoi rien n'apparait au niveau de l'analyseur quand vous n'avez uploadé qu'un seul jour de log).
Ce jour spécial sera votre nouveau jour en cours de parsing (currently parsed day dans l'application) : Vous ne pouvez uploader que des logs situés après cette date. Si des fichiers de logs situés avant cette date venaient à être uploadés, ils seront ignorés.
Le jour en cours de parsing est toujours indiqué sur la page d'upload.
Vous pouvez réinitialiser votre site si vous souhaitez réuploader des logs depuis le début.
Après avoir été parsés, vos logs seront effacés du serveur (libérant du quota de stockage). Peu de temps après, vous devriez voir les résultats de l'analyse apparaitre sur le dashboard.
Cependant, si vous ne déclenchez par le parsing, les logs seront juste stockés sur le serveur et l'analyse ne sera pas effectuée. Vous devez déclencher le parsing après chaque session d'upload. Aussi, vous ne pouvez pas stocker une quantité infinie de logs sur les serveurs sans déclencher le parsing : en fonction de votre plan, certains quotas et limites peuvent s'appliquer.
Parfois, des erreurs peuvent apparaitre lors du parsing. Vous pouvez voir ces erreurs sur la page upload, onglet "uploaded logs".
Il est tout à fait normal d'avoir quelques erreurs dans ses fichiers logs. Les lignes avec des erreurs sont juste ignorées et n'empêchent pas le déroulement de l'analyse de logs.
Néanmoins, les logs avec un taux d'erreur anormal seront visibles en rouge. Cliquez sur le bouton détail ou la loupe pour voir plus d'informations sur les erreurs rencontrées.
Voici la liste des erreurs les plus courantes :
| Date before currently parsed day | Apparait lorsqu'un fichier de logs contient des données antérieures au jour en cours de parsing. Le jour en cours de parsing est le dernier jour extrait du précédent parsing. Vous ne pouvez uploader que des logs situés le même jour ou après celui-ci. Vous pouvez lire le processus d'envoi des logs afin de bien comprendre ce concept. |
| Date too old | Vous ne pouvez pas uploader des logs situés trop loin dans le passé, la limite est à -30 jours par défaut. Vous pouvez contacter le support si vous avez besoin d'uploader plusieurs jours d'archive. |
| Date in future | Comme ci-dessus, vous ne pouvez uploader des logs situés trop loin dans le futur, +3 jours par défaut. |
| Max hit per day exceeded | Certains plans sont limités à un nombre maximum de hit par jour (1 hit = 1 ligne de log). Une fois cette limite atteinte, les lignes suivantes sont ignorées et marquées avec cette erreur. |
| Invalid IP |
Dans la plupart des cas cette erreur arrive à cause d'un log format invalide (voir erreur suivante Invalid champ). Si vous êtes sur que votre LogFormat est correct, une ip peut être invalide pour plusieurs raisons : reverse dns à la place de l'ip, nous ne supportons pas encore ipv6 (pour le moment), ou l'ip est obfusquée. Attention également si vous êtes situés derrière un reverse proxy, si vous ne fournissez pas l'ip réelle du client dans vos logs, les principaux bots ne seront pas détectés (Google, Bing ...). Il est possible de désactiver la vérification IP sur la page configuration. |
| Invalid champ | Où champ peut être user-agent, uri, referrer... Si vous voyez un nombre important d'erreurs de ce type, il est très probable que la directive log format de votre configuration ne corresponde pas avec les fichiers de logs envoyés. Utilisez le logtester pour déboguer ce type de problème. |
Le moyen le plus facile d'uploader des logs est d'utiliser le formulaire sur la page uploads. Cependant ce formulaire est limité aux fichiers de 2GB maximum. Pour envoyer des fichiers plus gros ou de manière récurrente, nous vous recommandons d'utiliser l'API.
L'une des fonctionnalités les plus intéressantes est la possibilité de comparer le crawl à un sitemap.
Le sitemap étant une liste exhaustive des fichiers que vous souhaitez voir crawlé, nous l'utilisons pour déduire :
Par défaut, nous essayons de découvrir automatiquement le sitemap du site en consultant robots.txt et en téléchargeant le sitemap à intervalle régulier.
Vous pouvez également spécifier une URL alternative pour le sitemap au niveau de la configuration du site.
Un fichier sitemap n'est pas limité à un fichier .xml. Cela peut également être un simple fichier texte avec une URL par ligne. (Pour info, Googlebot accepte également ce type de sitemap).
Si vous utilisez un crawler on-site, vous pouvez exporter les URLs crawlées dans un fichier texte et l'utiliser à la place de votre sitemap.
De cette façon vous pouvez comparer le crawl de votre outil, à celui de GoogleBot.
Les tags permettent de classer les URLs et les métriques des rapports.
Les modifications des tags n'apparaitront qu'après la prochaine analyse. Cependant, vous pouvez vérifier vos tags instantanément grâce au log-tester (onglet tagging).
De cette façon vous n'aurez pas à attendre la prochaine analyse pour voir si vos tags sont OK.
L'ordre des tags est important : une URL ne peut être taguée que par un seul tag. Si une URL correspond à plusieurs tags, le premier tag sera utilisé. C'est pourquoi il est possible de réorganiser les tags.
Les TagEx sont comme des expressions régulières mais beaucoup plus simples (et plus limitées). Nous travaillons pour améliorer les TagEx.
The TagEx s'applique sur le chemin d'accès et la query de l'URL. La partie hostname n'est pas prise en compte.
http://example.com/matching?area=1
| ^ | URL commence par |
|---|---|
| $ | URL se termine par (attention en utilisant celle-ci, n'oubliez pas la query). |
| ::num:: | Un nombre (équivalent RegEx : [0-9]+) |
| ::alphanum:: | Une chaine de caractère alphanumérique (équivalent RegEx : [a-zA-Z0-9]+) |
| ::alpha:: | Une chaine de caractère (équivalent RegEx : [a-zA-Z]+) |
| ::alphalower:: | Une chaine de caractère en minuscule (équivalent RegEx : [a-z]+) |
| ::alphaupper:: | Une chaine de caractère en majuscule (équivalent RegEx : [A-Z]+) |
^/20::num::/
CORRESPOND /2015/02/04/title.html
NE CORRESPOND PAS /page/2015/02/04/title.html
/20::num::/
CORRESPOND /2015/02/04/title.html CORRESPOND /page/2015/02/04/title.html
^/category/c-::num::.html
TAG /category/c-12123.html?query=1
?id=::num::$
CORRESPOND /page?id=123
NE CORRESPOND PAS /?id=123&page=1
Une réinitialisation (ou un reset) effacera toutes les données de votre site. Seuls la configuration et les partages d'accès ne seront pas modifiés.
C'est le seul moyen de retirer des bots de votre configuration.
Un reset est également utile en cas d'erreur au niveau de l'upload : il permet de remettre à zéro le jour en cours de parsing.
Les sites sont sujets à des limites et quotas, en fonction de leur plan. Si vous êtes trop restreint par certaines limites, contactez le support ou choisissez un plan moins restrictif. Vous pouvez voir l'état de vos limites et quotas sur la page uploads.
Le nombre maximum d'URL unique autorisé pour un site. Une fois cette limite atteinte (via le sitemap ou via les logs), les nouvelles URLs seront ignorées.
Vous ne pouvez uploader des logs situés trop loin dans le passé, la limite est à -30 jours par défaut. Vous pouvez contacter le support si vous avez besoin d'uploader plusieurs jours d'archive (prestation payante).
Le nombre maximum de bots ou crawlers que vous pouvez suivre sur votre panel.
Les limites suivantes ne s'appliquent qu'au plan DEMO gratuit.
Nombre maximum de hits (ou ligne de logs) accepté par jour de logs. Lorsqu'un fichier log est analysé, une fois que cette limite est atteinte pour une date, les lignes suivantes de cette même date sont ignorées.
La taille totale des fichiers compressés que vous pouvez uploader par jour. Seulement la taille du fichier compressé est prise en compte. Par exemple, si vous uploadez un fichier gzipé de 20MB, d'une taille décompressée de 100MB, seul 20MB sera déduit de votre quota. Une fois que ce quota est totalement consommé, le quota extra sera utilisé. Le quota par jour est réinitialisé tous les jours. Il y a aussi une limite au nombre maximum de fichiers que vous pouvez uploader par jour.
Taille totale des fichiers compressés que vous pouvez uploader une fois que votre quota par jour est totalement utilisé. Principalement utilisé pour uploader des archives de logs. Ce quota n'est pas réinitialisé mais peut être étendu en contactant le support (prestation payante).
Taille totale des fichiers stockables sur le serveur sans déclencher de parsing. Il y a également une limite au nombre maximum de fichiers qui peuvent être stockés sur le serveur.