tutoriels : Procédure simple pour chercher des consultations dans les lignes de logs rejetées par ezPAARSE

Bonjour,

Dans un précédent article sur les comparaisons des statistiques éditeurs avec les ECs d’ezPAARSE, nous avions exposé les bonnes pratiques à adopter pour vérifier la reconnaissance des plateformes dans ezPAARSE avec l’outil ezLOGGER.

Aujourd’hui, nous vous proposons une méthodologie simple pour chercher des consultations dans les lignes de logs rejetées par ezPAARSE.

Ce tutoriel prendra pour exemple la plateforme Nature dans les logs du portail INSB de BibCNRS.

Nous avons observé une augmentation importante des consultations de type ARTICLE dans les rapports COUNTER de l’éditeur à partir du mois de mai 2018. En consultant les données générées par ezPAARSE pour la même période, nous avons constaté qu’il n’y avait aucune augmentation et que la courbe était stable par rapport aux mois précédents.

La méthode que nous exposons ici est simple et ne s’adresse pas obligatoirement à un informaticien. Elle demande par contre un peu de pratique, une connaissance de l’environnement Linux et du logiciel ezPAARSE. N’hésitez pas à consulter l’équipe qui se fera un plaisir de vous aider si vous souhaitez la tester !

1) Vérifications au préalable

Comme mentionné dans l’introduction, nous avons d’abord vérifié que les consultations de type ARTICLE HTML et PDF étaient bien reconnues par ezPAARSE grâce à l’outil ezLOGGER.  Nous avons pour cela balayé l’ensemble de la plateforme Nature dans un navigateur web en vérifiant dans ezLOGGER que les consultations étaient bien prises en charge par le parseur dédié.

Une fois les consultations validées, vous pouvez passer à l’étape suivante.

2) Dans Linux ou ubuntu

Dans l’environnement Linux, vous devez pouvoir accéder aux fichiers de logs de votre établissement.

Vous allez utiliser uniquement une partie des logs en filtrant sur la plateforme Nature. Cette opération va permettre de réduire le nombre de lignes de log et la taille du fichier à traiter. Dans notre test, nous avons travaillé sur le mois de mai 2018.

Pour récupérer les lignes avec la chaîne « nature » dans tous les fichiers « .log » du dossier courant, utilisez la commande grep :

grep nature *.log > nature.log

Si vos fichiers sont compressés :

zcat *.gz | grep nature > nature.log

Le fichier nature.log ne contiendra que des logs avec la chaîne de caractères « nature ».

Concrètement, la majeure partie du fichier contiendra les logs de la plateforme Nature, avec quelques logs d’autres plateformes qui contiennent cette chaîne de caractères.  Mais l’opération permet de réduire considérablement la taille du fichier.

 

3) Traitement du fichier Nature.log dans ezPAARSE

ezpaarse prepa traitement

 

Dans l’interface de votre instance locale (mise à jour au préalable) vous insérez le fichier log ainsi obtenu.

Dans les paramètres, veillez à vérifier que le prédéfini de votre établissement est bien sélectionné.

L’objectif de ce traitement est d’obtenir les fichiers des logs rejetés et les domaines inconnus.

Pour cela, il faut ajouter un « Header » dans la partie « Headers (avancé) » en sélectionnant « Reject-files », et lui attribuer la valeur « all » (qui demande à ezPAARSE de générer tous les fichiers de rejets).

ezparse traitement headers

ezpaarse rejets page complete

A la fin du traitement, vous pouvez télécharger les fichiers de rejets des domaines inconnus et des ECs non qualifiés dans l’onglet « Rapport ». Vous y retrouverez tous les lignes logs qui ne sont pas traitées dans ezPAARSE car non prises en charge par le parseur :

ezpaarse domaines inconnus et ecs non qualifiés

 

4) Bonnes pratiques pour utiliser un fichier de rejets

 

ezpaarse liste des log non qualifiées

Pour ouvrir un fichier de rejet contenant des logs, nous vous conseillons d’utiliser un éditeur de texte spécialisé, comme Vim, Emacs ou Notepad ++ (utilisable depuis un ordinateur sous Windows).

Ce fichier peut contenir des milliers de lignes, donc il est préférable de procéder par élimination. C’est-à- dire supprimer tous les logs qui s’avèrent ne pas être des consultations. Dans le jargon informatique, on les appelle des « assets ».  Pour résumer, les assets sont les composantes (ressources) à l’élaboration d’une page web et ne sont donc pas des documents consultés à proprement parler.

Vous pouvez facilement les reconnaître car les URLs contiennent les éléments suivants (liste non exhaustive) :

/static/

/css/

/fonts/

/verify/

/status/

/search/

/jquery/

/login/

/js/

Dans notre exemple de fichier, vous pouvez retrouver tous ces éléments. L’objectif du traitement est de supprimer toutes ces lignes de log pour arriver à un fichier contenant potentiellement des logs de consultations non analysées dans analogIST.

Il peut y avoir aussi des logs avec des URL déjà analysées mais non reconnues par le parseur car un caractère de l’identifiant (DOI par exemple) n’est pas décrit dans l’expression régulière.  Cela peut être un « . » ou « – » ou « / ». Nous avons remarqué que certains éditeurs n’avaient pas uniformisé leurs identifiants. Et ces caractères spéciaux n’avaient pas été détectés dans l’analyse.  C’est le cas de la plateforme Nature.

Le travail de recherche dans les lignes de log a donc permis de mettre à jour le parseur en ajoutant les caractères spéciaux à l’expression régulière de départ,  et d’ajouter des exemples de ces URLs :

ezpaarse parseur nature differents identifiants

4-a) les domaines inconnus

Ce deuxième fichier contient les URLs avec des domaines inconnus dans ezPAARSE.

De la même manière que le fichier précédent, vous pouvez chercher si certains logs contiennent des domaines non pris en charge dans ezPAARSE.

ezpaarse rejets domaines inconnus

Les URLs de ces logs ne doivent pas non plus contenir d’assets pour être potentiellement exploitables.

 

Si vous trouvez à la fin du traitement des URLs (ou domaine) correspondant à des consultations de documents « fulltext « non détectées dans ezPAARSE, vous pouvez procéder à une analyse dans analogIST et ajouter un commentaire dans la carte Trello se rapportant à la plateforme. 

 

5) Conclusion

Ce travail d’analyse des fichiers de rejets de logs permet de compléter les tests d’un parseur avec ezLOGGER.

Il permet aussi d’éliminer chaque problème potentiel :

  • mauvaise analyse d’URL
  • analyse incomplète
  • parseur trop restrictif (identifiants non uniformisés d’une plateforme)
  • un domaine non détecté

Mais il permet aussi de confirmer une certitude dans le comptage des consultations via un reverse-proxy.

Si ezPAARSE reconnaît parfaitement une plateforme mais qu’il y a une différence avec les statistiques (en faveur de l’éditeur), il est peut-être intéressant pour le négociateur de demander à l’éditeur de préciser sa manière de calculer et de dédoublonner les consultations sur sa plateforme. 

 

Bonne journée.

Frédéric Truong pour ezTEAM