BETA

Configuration

Format des logs

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

Format custom

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.

Champs nécessaires

Les champs suivants doivent être présents dans les fichiers logs :

  • IP : utilisé pour détecter les bots et les cloakers, vous pouvez désactiver cette vérification sur la page de configuration. Peut être partiellement obfusqué (1.2.3.x).
  • User-Agent
  • Méthode HTTP
  • Status HTTP
  • Date
  • URL
Page speed

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.

  • Apache : Utiliser la variable %D dans la directive LogFormat du serveur.
  • NGINX : Utiliser la variable $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.
  • IIS : Le temps d'exécution peut être traqué grâce à la variable time-taken.

Envoi des logs

L'envoi des logs s'effectue en deux étapes : l'upload et le parsing.

upload

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 :

  • Trop vieux (30 jours dans le passé au maximum par défaut)
  • Avec une date future (aujourd'hui +3 jours maxi)
  • Situés avant votre jour en cours de parsing (ou d'analyse). Plus d'informations concernant ce dernier point dans la section ci-dessous.

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.

parsing

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.

Erreurs

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 dayApparait 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 oldVous 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 futureComme ci-dessus, vous ne pouvez uploader des logs situés trop loin dans le futur, +3 jours par défaut.
Max hit per day exceededCertains 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 champOù 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.
Uploadeurs

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.

Sitemap & crawl

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 :

  • Les pages non crawlées : La liste des pages présentes dans le sitemap non visitées par les bots.
  • Les pages surcrawlées : La liste des pages crawlées par les bots mais qui ne sont pas présentes dans le sitemap.
  • Les pages crawlées : La liste des pages présentes dans le sitemap et visitées par les bots.

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.

Comparer le crawl

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.

Tags

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.

Syntaxe TagEx

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]+)
Exemples
  • ^/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

Réinitialisation

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.

Limites

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.

  • URLs

    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.

  • Date limit

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

  • Tracked bots

    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.

  • Hits par jour

    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.

  • Quota par jour

    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.

  • Extra quota

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

  • Storable quota

    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.