Journal J'ai joué avec Crowl et OpenDBViewer conjointement

Sommaire

• Installation de Crowl
• Installation de OpenDBViewer
• Installation de mysql (mariadb)
• Lancement de Crowl
• Découverte du contenu de la base
• le schéma de base généré par Crowl
• les données à exploiter
  • Les urls
  • Les liens
  • Extrapolation SEO (en mode débutant)
  • Digression
• Conclusion
• Note de dernière minute

Suite aux dépêches très récentes présentant respectivement Crowl et OpenDBViewer 1.1.0, j'ai testé les deux… conjointement, et suis arrivé au point où je voulais faire des commentaires.

Oui mais… devais-je mettre les commentaires dans le fil de la dépêche sur Crowl ou dans le fil de commentaire de la dépêche sur OpenDBViewer ?

A force de ne pas me décider, j'ai décidé de faire un journal et d'y faire référence dans les deux dépêches.

Installation de Crowl

La documentation de Crowl indique qu'il faut une version python 3.6. J'ai fait l'installation avec python 3.5 et l'ai fait fonctionner avec succès.

Aucune remarque particulière sur l'installation. Il faut dire que je travaille chez Algoo, et on est relativement bien spécialisé en python, donc ça aide, d'autant que le socle technique sur lequel repose Crowl est Scrapy que nous avons utilisé sur d'autres projets, pyjobs en particulier.

Installation de OpenDBViewer

La documentation explique bien les dépendances à installer. Il manquait néanmoins cmake sur mon système, que j'ai naturellement installé via apt : apt install cmake

Puis j'ai procédé à la compilation en suivant la documentation, et exécution via ./opendbviewer dans le dossier du projet.

Le programme se lance.

Installation de mysql (mariadb)

Crowl nécessite mysql pour stocker les résultats du crawl, ainsi qu'un compte utilisateur autorisé à créer des bases de données.

Note : ceci est nécessaire car Crowl stocke ses résultats dans des bases de données nommées sous la forme <nom projet>_<date>-<heure>. Exemple : algoo_20180830-132701

Rien de bien particulier pour cette étape préliminaire :

• installation de mysql via la commande apt install mysql-server (en réalité cela installe mariadb, mais c'est très bien : c'est ce qu'on veut).
• puis, dans un terminal mysql exécuté en tant que root :
  • création d'un utilisateur : CREATE USER 'crowl'@'localhost' IDENTIFIED BY 'crowl';
  • attribution de tous les droits : GRANT ALL PRIVILEGES ON * . * TO 'crowl'@'localhost';
  • activation des privilèges : FLUSH PRIVILEGES;

Note : sur une machine sécurisée, vous penserez bien entendu à mettre un mot de passe convenable et à ne pas donner tous les droits à l'utilisateur mysql créé pour l'occasion.

Lancement de Crowl

J'ai lancé Crowl sur le site web de ma boîte : python crowl.py -l -c -u https://www.algoo.fr/ -b algoo

Les options utilisées sont les suivantes :

• -l pour "links" : outre les urls "crawlées" (et le résultat associé), on stockera les liens entre les pages avec leur ranking
• c pour "content" : on stocke le contenu des pages
• -u pour l'url de début de crawling
• -b pour "database", et plus exactement le project *base*name.

Intuitivement je me suis attendu à ce que les données soient stockées dans une base de données intitulée algoo, mais il n'en est rien : il s'agit bien du basename et le nom des bases sera de la forme évoquée dans la partie précédente : quelque chose comme algoo_20180830-132701

Découverte du contenu de la base

On lance OpenDBViewer via la commande ./opendbviewer, puis on choisit de créer une nouvelle connexion via les paramètres suivants :

• hôte : 127.0.0.1
• port : 3306
• nom d'utilisateur : crowl
• mot de passe : crowl
• nom de la base de données : ?!

Premier point d'achoppement : je ne connais pas le nom de la base de données, et OpenDBViewer ne me permet pas de me connecter sans ce nom. C'est dommage.

Je me connecte en ligne de commande et exécute un show databases; qui me liste les bases de données disponibles. Me voilà de retour dans OpenDBViewer.

Pour un simple copié-collé, ça donne ça : mysql -h 127.0.0.1 -u crowl -pcrowl -e "show databases;"

Là tout va bien, l'interface est simple et intuitive, ça me liste les tables, je peux en découvrir le schéma, les données, exécuter des requêtes SQL… bref ça semble faire le job.

le schéma de base généré par Crowl

Crowl propose par défaut de stocker les urls avec les informations associées, telle que le code HTTP résultat de la requête, les métadonnées, etc.

Le schéma de table est le suivant :

CREATE TABLE `urls` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `url` varchar(2048) COLLATE utf8_bin NOT NULL,
  `response_code` int(11) NOT NULL DEFAULT '0',
  `content_type` varchar(128) COLLATE utf8_bin DEFAULT NULL,
  `level` int(11) NOT NULL DEFAULT '-1',
  `referer` varchar(2048) COLLATE utf8_bin DEFAULT NULL,
  `latency` float DEFAULT '0',
  `crawled_at` varchar(128) COLLATE utf8_bin DEFAULT '0',
  `title` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `meta_robots` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `meta_description` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `meta_viewport` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `meta_keywords` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `canonical` varchar(2048) COLLATE utf8_bin DEFAULT NULL,
  `h1` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `wordcount` int(11) DEFAULT '0',
  `content` text COLLATE utf8_bin,
  `XRobotsTag` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `outlinks` int(11) DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=141 DEFAULT CHARSET=utf8 COLLATE=utf8_bin

En lançant l'exécution avec l'option -l on récupère également une table intitulée links dont le schéma est le suivant :

CREATE TABLE `links` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `source` varchar(2048) COLLATE utf8_bin NOT NULL,
  `target` varchar(2048) COLLATE utf8_bin NOT NULL,
  `text` varchar(1024) COLLATE utf8_bin NOT NULL,
  `weight` float DEFAULT '1',
  `nofollow` tinyint(1) DEFAULT NULL,
  `disallow` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3198 DEFAULT CHARSET=utf8 COLLATE=utf8_bin

les données à exploiter

OpenDBViewer permet de parcourir les données et cela a l'air relativement fluide. Petit regret : on ne peut pas trier les données par colonne.

Dans l'onglet feuille de travail il est possible d'exécuter des requêtes SQL. La saisie de la requête bénéficie de la coloration syntaxique.

Les urls

Exemple : select * from urls where response_code != 200;

Dans mon cas, cela me permet d'identifier qu'il n'y a pas d'erreur 404 ; j'obtiens 3 pages qui sont en 301 - à voir si c'est un problème.

Les liens

Crowl identifie tous les liens présents sur une page et calcule leur poids. Si j'ai bien compris, plus le poids est important (1) plus le lien est important (ie le premier dans la liste des liens).

Extrapolation SEO (en mode débutant)

A partir de ces données, on peut relativement facile extraire des données du type :

• retrouver toutes les pages qui contiennent des liens cassés
• identifier toutes les pages en 404
• identifier le temps de réponse d'un site (champ latencydans la base ; j'imagine que c'est le temps d'envoi du 1er octet)
• …

Je ne sais pas ce qu'on interprète d'une info comme outlinks mais j'imagine qu'il y a un vrai enjeu par rapport à ça (des informations comme le titre H1 ou encore le nombre de mots sont stockés en base et je sais que ce sont des éléments clés en SEO)

Digression

Je me suis dit qu'à partir de la liste des liens je pourrais faire un graphe de navigation.

Pour cela je procède de la manière suivante :

1. je requête la table
2. je génère un fichier .dot au format graphviz
3. je génère une vue SVG du .dot

La génération du fichier .dot est faite via l'enchaînement de 3 commandes bash :

echo "digraph G {" > /tmp/graph.map
mysql -B --disable-column-names -u crowl -pcrowl algoo_20180830-134542 -e "select concat('  \"', source, '\" => \"', target, '\"') from links;" >> /tmp/graph.map
echo "}" >> /tmp/graph.map

echo "digraph G {" > /tmp/graph.dot
mysql -B --disable-column-names -u crowl -pcrowl crowltech_20180830-213146 -e "select concat('  \"', source, '\" -> \"', target, '\"') from links;" >> /tmp/graph.dot
echo "}" >> /tmp/graph.dot

Ce qui génère un fichier de la forme :

digraph G {
  "https://www.algoo.fr/" -> "https://www.algoo.fr/#intro"
  "https://www.algoo.fr/" -> "https://www.algoo.fr/"
  [...]
}

Puis ce fichier est donné à ingurgiter à graphviz :

dot -Tsvg /tmp/graph.dot -o /tmp/graph.svg

Dans mon cas ça ne donnera rien d'exploitable car trop de liens sont présents (en particulier à cause de la section blog qui propose des tags et catégories).

Note : à vrai dire je ne vois pas trop l'intérêt d'extraire ce genre de graphe (on a vite des liens dans tous les sens, donc le graphe est imbitable), mais c'était plutôt pour la beauté du geste : générer un script graphviz à partir d'une requête SQL.

A noter que notre site web propose des flux RSS qui ne sont pas détectés en tant que tel par Crowl, et qui génère donc des erreurs python de type "index out of range" sur les requêtes XPATH //body0.

C'est un détail, le crawl fonctionne correctement - ces pages ne sont pas prises en compte (mais c'est normal).

Conclusion

Voilà deux bons outils. Des bugs à corriger et/ou améliorations à apporter mais c'est le lot de tous les logiciels :)

Les outils sont simples et bien documentés pour les premiers pas et le reste, c'est à chacun de le faire :)

Dans quel cas je pense utiliser ces outils :

• Crowl intégré dans un outil de reporting de notre site web pour détecter les erreurs 404 et peut-être les mots-clés associés aux pages de notre site web. Ce qu'il faudra que je fasse pour l'utiliser :
  • définir les indicateurs qui m'intéressent (pages en 404, mots clés et description par page)
  • mettre en place l'outil via un cron qui s'exécute chaque jour ou semaine
  • développer un tableau de bord qui requête la dernière base de donnée et en extrait les bons indicateurs
• OpenDBViewer pour visualiser le contenu de bases MySQL.
  • Pour PostgreSQL j'utilise pgadmin qui est très complet et fonctionne bien (même si visiblement il n'est plus activement développé)
  • Pour SQLite, j'utilise DB Browser for SQLite comme cité par plusieurs personnes dans les commentaires de la dépêche.

Note de dernière minute

En testant un autre site web je suis tombé sur une erreur python : un logger non défini. Je voulais remonter un bug mais je n'ai pas de compte gitlab.com… puis j'ai vu que je pouvais m'authentifier avec mon compte github… mais aussi que ça ne suffisait pas à gitlab.com car il fallait aussi que je leur donne mon email… tiens donc… et aussi que je le valide… bref. J'ai finalement créé le rapport correspondant : https://gitlab.com/crowltech/crowl/issues/10

J'ai également remonté un problème d'encodage qui vient a priori de OpenDBViewer… https://github.com/Jet1oeil/opendbviewer/issues/31