ZEP-11 : Interface de statistiques sur les tutoriels

ça fait un moment que je n'ai pas donné de nouvelle sur le développement de cette ZEP. J'ai eu un peu de mal à dégager du temps de libre pour avancer dessus. Mais si vous jetez un œil à la mise à jour des cases du premier post, vous verrez que ça commence à verdir pas mal.

Le parsing des logs, le filtrage et le stockage des logs est développé et fonctionnel. L'étape finale va être de benchmarker cette partie par rapport aux moteurs InnoDB et MyISAM.

Étant donné que ce code devra être testé par la suite, j'ai écrit un script qui permet de générer un fichier access-log fictif en passant juste en paramètre le nombre de lignes voulues (ce qui me permettra donc de faire facilement des tests de charges). Donc on a un fichier de log fictif qui est généré, un script permet de parser ledit fichier et d'identifier les urls relatives à du contenu, pour ensuite stocker la log ainsi que l'identifiant de son contenu dans zds. J'ai codé cette partie en prenant en compte le fait que la forme d'une url peut varier dans le temps (cc zep12), donc je considère les étapes 1,2 et 3 presque finies.

J'ai commencer l'API, je n'ai pas vu de mauvaises surprises par rapport à ce qui était prévu, donc c'est une simple question de temps pour cette partie. Cependant, une question qui m'est venue à l'esprit, et je pense que vous pourrez m'aider à y répondre c'est la suivante :

Ouch. Et à l'inverse, je sais pertinement que j'utilise plusieurs IPs (au moins une au travail¹ et une à la maison). Par ailleurs, en Belgique, les IPs ne sont pas fixes (elles changent au moins à chaque fois qu'on redémarre le routeur), donc je "suis" une belle liste d'adresse IPs, par exemple. Du coup, pour moi, tracker les utilisateurs uniques va être très complexe si Google ne le fait pas pour nous. Et c'est sans parler des petits malins qui font du multiboot (situation assez courante sur un site comme ZdS pour des raisons évidentes).

Dans les systèmes que j'ai eu à manipuler jusqu'à présent, c'était la plupart du temps sous un format IP + cookie.

Pourquoi pas simplement cookie ? Car dans la combo ip+cookie avec une ip dynamique sur 1 mois on est considérer comme plein de visiteur unique…

Merci bien pour vos retours. Le cookie devrait faire l'affaire techniquement. Meme si ce dernier n'est pas parfait (car si je me connecte via mon téléphone et via mon pc j'ai deux cookies differents pour un même visiteur)

La question donc qui me vient à l'esprit quand je dois utiliser le cookie est de savoir si c'est légal de stocker les cookies dans les logs.

Si j'en crois la page de la CNIL on reste dans la légalité avec le cookie de session. Et l'idée de le coupler à l'identifiant du membre (quand il est connecté) est effectivement un bon moyen de séparer tout ceci.

Je vais voir comment tout ceci se traduit techniquement.

Merci bien pour votre aide la dessus.

Autre question un peu tordue.

http://www.user-agents.org/ ?

Ou mieux : http://fr.wikipedia.org/wiki/User-Agent#Robots

Bon, je viens de me rendre compte en fouinant dans la doc de la lib que j'utilise pour parser les user-agent, qu'il existe une fonction is_bot qui fait le boulot. Ce problème est donc résolu.

Attention la liste des bots est bien moins complète que celle de Wikipedia.

Je ne sais pas si c'est problématique ou non mais ça vaut le coup de soumettre un patch à ta lib, parce qu'elle ne contient que Google comme bot :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

    "google_bot": {
        "is_bot": true,
        "is_mobile": false,
        "is_pc": false,
        "is_tablet": false,
        "is_touch_capable": false,
        "ua_string": "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)",
        "str": "Spider / Other / Googlebot 2.1"
    },
    "googlebot_mobile": {
        "is_bot": true,
        "is_mobile": true,
        "is_pc": false,
        "is_tablet": false,
        "is_touch_capable": false,
        "ua_string": "Mozilla/5.0 (iPhone; U; CPU iPhone OS) (compatible; Googlebot-Mobile/2.1; http://www.google.com/bot.html)",
        "str": "Spider / Other / Mobile Safari"
    },
    "googlebot_mobile_2": {
        "is_bot": true,
        "is_mobile": true,
        "is_pc": false,
        "is_tablet": false,
        "is_touch_capable": true,
        "ua_string": "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)",
        "str": "Spider / Other / Mobile Safari"
    },

Notamment il semble manquer (pour la France, donc j'exclue Baidu notamment) Yahoo!, Google Image et msnbot.

Après je sais pas ce que ça représenterait réellement…

Bien vu. Par contre on voit bien aussi que la liste de Wikipedia n'est pas exhaustive, puisqu'elle n'a pas le user-agents des bots mobiles.

Si j'en crois la page de la CNIL on reste dans la légalité avec le cookie de session. Et l'idée de le coupler à l'identifiant du membre (quand il est connecté) est effectivement un bon moyen de séparer tout ceci.

Pour être sûr d'être dans la légalité, on pourrait même faire un hash de cookie+identifiant ?

Um… mauvaise idée.
Il faut penser à un utilisateur non connecté qui s'identifie…

La première fois que j'arrive sur le site je n'ai pas de cookie, j'en reçois un qui identifie mon terminal, si je m'identifie ensuite on ne touche pas au cookie du terminal mais on écrit une association entre l'utilisateur et le cookie terminal.

Effectivement, au moment du parsing des logs il faut allé voir dans la bdd si tel cookie est lié à un compte utilisateur… mais il n'y a pas d'autres moyen de le faire, sinon, quand j'arrive sur le site en tant que non identifier, au moment ou je m'identifie je vais compter pour deux utilisateurs unique.

A noté qu'une autre possibilité serai au moment de l'identification allé ré-écrire dans les logs le cookie d'identification. C'est valable, mais j'aime moyen l'idée d'aller modifier les logs après coups.

j'aime moyen l'idée d'aller modifier les logs après coups.

+1 : vaudrait mieux se passer de ce genre de blagues. Pour peu que t'aies un caractère mal placé, une regex un peu foireuse dans certains cas marginaux, t'as foutu en l'air ton fichier de logs :\

Après réflexion, une ligne de log ne contient pas le pseudo de utilisateur, du coup au moment ou les logs sont parsés, il est difficile de savoir quel utilisateur exactement est à l'origine d'une ligne de logs. Donc l'association que propose La source n'est techniquement pas possible (à part si je rate quelque chose).

Du coup, la seule info qui tient la route pour le moment est le cookie (à travers la variable $http_cookie de nginx) pour identifier le visiteur unique.

De toutes façons, n'essayez même pas de proposer une solution qui impliquerait de modifier les logs avec autre chose que ce que Nginx peut mettre dedans, ce sera refusé

Si je regarde les cookie du site, on retrouve un cookie sessionid, qui, j'imagine m'identifie sur le site. Ce cookie peu être enregistré dans les logs. Hors s'il m'identifie il y doit y avoir moyen de savoir que le cookie abcd1234 correspond à La source

L'idée c'est d'ajouter un deuxième cookie xyz789 qui lui restera toujours et représentera mon navigateur (que je soie ou non identifié).

Dans les logs il faudra sauvegarder ses deux cookies, et au moment du parsing voir si le cookie abcd1234 correspond à un utilisateur.

Si tu me dis comment je suis preneur, car la relation entre un cookie http (je parle bien ici du cookie http accessible via nginx et non du cookie de session que je ne vois pas comment récupérer dans mes logs) et un pseudo n'existe pas.

Ici le cookie sessionid est de type http, tu devrai pouvoir le lire non ?

Après, faire le lien entre la valeur du cookie et le compte utilisateur… en php j'utiliserai la fonction session_id(), en python je dois dire que j'y connais pas grand chose mais il doit bien y avoir l'équivalent non ?

Par contre, effectivement, cela nécessite de sauvegarder quelque par cette information dans la bdd.

Je vais essayer de voir ce que donne cette piste alors.

Merci bien.

Salut, est-ce que faire la doc de l'API des stats est envisageable si je n'ai pas participé ? Ou c'est trop complexe ?

Je ne dis pas que je vais le faire, mais si j'ai le temps, ça fait partie des seules tâches que je peux faire pour l'instant