Sortie de WebDruid 0.5.3

Posté par (page perso) . Modéré par rootix.
Tags :
0
5
mai
2004
Internet
WebDruid est un logiciel libre (GPL) qui génère des rapports de statistiques pour les sites web. Il est né du fork de Webalizer, logiciel utilisé par de nombreux sites dont LinuxFR.

Le développement de Webalizer ayant stagné depuis quelques années, WebDruid reprend différents correctifs jamais inclus dans Webalizer, et ajoute de nouvelles fonctionnalitées :

- Support IPv6.
- Localisation à l'exécution, et non plus à la compilation.
- Le code d'analyse des moteurs de recherche à été ré-écrit, il est plus rapide et facilite l'ajout de nouveaux moteurs.
- Affichage des mot-clés par moteurs de recherche, et par URL.
- Graphes des chemins les plus suivis, et graphes des flux utilisateurs.
- Les graphes utilisent des fonts "true type", et permettent l'affichage des caractères non-ASCII.
- Support de log au format CLF (utilisé par IIS).

Les sources et les paquets Debian sont disponibles sur le sites :

Aller plus loin

  • # Statistiques

    Posté par . Évalué à 1.

    Et qui a vu les statistiques du mois de mai pour linuxfr ?
    C'est bizarre : déjà autant de hits qu'en avril !
    On note une hausse du nombre de mozilla, qui en profite pour casser sa chute débutée il y a plusieurs mois...
  • # XHTML/CSS

    Posté par . Évalué à 2.

    ca existe un truc aussi complet que webalizer mais qui fait des sorties en XHTML que l'on puisse utiliser la CSS que l'on veut parce que même si c'est plus joli que webalizer, je trouve pas ca au top encore ! Bon j'ai vu que c'est prévu dans la roadmap mais c'est plutot le developpeur qui cherche d'autres membres connaissant le XHTML
    • [^] # Re: XHTML/CSS

      Posté par . Évalué à 10.

      on m'a chaudement recommendé AWSTAT, il semble être capable de générer des rapport en XHTML :

      ...Static reports in one or framed HTML/XHTML pages, experimental PDF export,...

      http://awstats.sourceforge.net/(...)


      quelqu'un a-t-il une expérience du produit et comparé avec Webaliser/Webdruid ?

      Envoyé depuis mon Archlinux

      • [^] # Re: XHTML/CSS

        Posté par . Évalué à -2.

        recommendé/recommandé
        rapport/rapports

        Envoyé depuis mon Archlinux

      • [^] # Re: XHTML/CSS

        Posté par . Évalué à 4.

        J'ai pas eu l'ocasion d'utiliser souvant AWSTAT mais ce que j'en n'est vu ne m'a pas convaincu. Les graphs ne sont pas claire (je trouve) et ils ne sont pas générés à l'avance. Il faut demmander leur génération sur la page web au moment de les consulter. L'utilisation des frames et d'un CGI ne me plaids pas non plus. Maintenant c'est pas moi qui l'avait configuré alors... Il y a peut-etre des reglages.
        • [^] # Re: XHTML/CSS

          Posté par . Évalué à 10.

          > ils ne sont pas générés à l'avance

          si,si c'est possible : tu peux lancer le calcul en cron (comme webalizer). D'ailleurs le bouton pour le calcul en temps réel peut être supprimé.

          > L'utilisation des frames et d'un CGI ne me plaids pas non plus.

          il y a une option dans le fichier de config pour afficher les frames ou non (si il n'y a pas de frame, le menu se retrouve en haut de l'écran)

          on peut également se passer du CGI si on génère les stats sous forme de pages statiques (comme webalizer aussi), mais dans ce cas on ne peut plus avoir le frame

          > Il y a peut-etre des reglages.

          y'en a pleins !!!!
      • [^] # Re: XHTML/CSS

        Posté par . Évalué à 3.

        Le gros problème des produits de calcul de stats web est la gestion des logs multiples (cas de serveurs web "loadbalancés"). Je n'en ai trouvé aucun qui soit capable d'"avaler" les logs tels quels sans avoir à passer un gros sort sur la concaténation des différents fichiers.
        Quelqu'un a déjà vu un produit capable de faire ça?
        • [^] # Re: XHTML/CSS

          Posté par (page perso) . Évalué à 2.

          Et bien WebDruid le fait :o)

          Le fichier de configuration de WebDruid permet d'avoir plusieurs directives "LogFile", il est aussi possible de spécifier plusieurs fichiers de log sur la ligne de commande. De plus, WebDruid ne charge pas tout en mémoire, et trie "au fur et à mesure".
        • [^] # Re: XHTML/CSS

          Posté par (page perso) . Évalué à 3.

          Pour les "loadbalancés", je suis tombé sur ça :
          http://www.backhand.org/mod_log_spread/(...)
          jamais essayé ....

          Mais pour les stats web j'utilise lire :
          http://logreport.org/(...)
          ex :
          http://logreport.org/lire/ex/html.php?type=apache(...)

          Un des rares à produire des stats parlantes et utilisables
        • [^] # Re: XHTML/CSS

          Posté par (page perso) . Évalué à 1.

          Pas de problème, une fois encore AWStats te les traite sans problème, sans copncaténation, sans sort. Il faut utiliser la directive LogFormat avec l'outil LogResolveMerge.pl qui fait du merge à la volée.
          Test effectué sur des 5 fichiers de 5 Go. Passage sans problème et les résultats sont autrement meilleurs et plus clair que Webalizer.

          Responsable Agence Bordeaux de la société Open Source TecLib (https://www.teclib.com)

      • [^] # Re: XHTML/CSS

        Posté par . Évalué à 3.

        Parmi les gros plus de AWStats je citerai la possibilité d'avoir le listing complet pour chaque liste, une meilleure gestion des navigateurs et des os et des informations supplémentaire tels que la date de la dernière visite et le nombre de visite des robots d'indexation.

        Ceci-dit je trouve effectivement que AWStats est moins facile à installer et à configurer que Webalizer et que le choix de mettre tout le code dans un seul fichier perl a autant d'avantages que d'inconvénients.
    • [^] # Re: XHTML/CSS

      Posté par . Évalué à 4.

      faut leur laisser un peu de temps , ils en sont que a la version 0.5.3. Faut etre confiant pour le futur en vu de la road map :)
    • [^] # Re: XHTML/CSS

      Posté par (page perso) . Évalué à 5.

      Juste comme ca... tu peux faire du XHTML très peu adaptable via des CSS si tu codes mal (idem pour HTML 4.0 d'ailleurs). Ce qu'il te faut plutot chercher, c'est un outil qui te sorte des résultats en XHTML/CSS (CSS-2.0 serait un gros plus).
    • [^] # Re: XHTML/CSS

      Posté par . Évalué à 3.

      Le fait de faire une sortie en pur XHTML n'a rien à voir avec celui de pouvoir utiliser les CSS. L'utilisation d'un Doctype HTML 4.01 strict suffit largement et d'une manière générale organiser une page web de manière sémantique c'est ce qui permet de faire un bon usage des CSS.
    • [^] # Re: XHTML/CSS

      Posté par (page perso) . Évalué à 3.

      Ça tombe trés bien, tu peux parfaitement le faire avec webdruid !

      Je viens de regarder les sources.

      La génération des pages se basent sur des fichier XSLT

      Il suffit de modifier ces fichiers XSLT pour avoir des pages XHTML ou HTML strict et ainsi utiliser CSS..

      et Hop !
    • [^] # Re: XHTML/CSS

      Posté par (page perso) . Évalué à 1.

      AWStats le peut depuis quelques versions. Il génère en statique ou dynamique des pages XHTML.
      Mais il t'offre en plus dans la derniere version sa base de données au format XML. A toi de générer tes pages comme tu veux avec des feuilles des styles XSLT.

      Responsable Agence Bordeaux de la société Open Source TecLib (https://www.teclib.com)

  • # L'option qui tue

    Posté par . Évalué à 5.

    J'apprécie particulièrement dans cet outil le fait de pouvoir visualiser les "déplacements" des utilisateurs.

    Mon projet: faire des pages web qui se "positionnent" sur le site en relation avec le nombre de passages sur cette même page ...
    Voir des pages avec un algo génétique derrière qui les "positionne" pour les mettre bien.
    • [^] # Re: L'option qui tue

      Posté par . Évalué à 1.

      Pourquoi un algo génétique ?
      Si tu veux que les pages les plus visitées soient "positionnées" en priorité sur ton site, il n'y a qu'a faire des stats (AMHA).
      Aprés il y a peut être une subtilité que je n'ai pas intercépté, dans quel cas je serais interessé par plus d'explication sur ton projet.
      Entre autre, que représenterait l'ADN dans ton algorithme génétique et quelle serait la fonction d'évaluation ?
      • [^] # Re: L'option qui tue

        Posté par . Évalué à 3.

        Les stats, c'est bien mais il faut faire des choses derrières apprès, je voyais plus un programme d'analyse qui tourne en regardant les logs et qui analyse l'enchaînement des visites des utilisateurs et qui fait les modification nécessaires dans une DB par exemple avec du PHP derrière qui est en charge d'afficher les pages.

        Mais bon, c'est au terme embryonnaire dans ma TODO liste...


        Sinon, mon ADN, c'est le positionnement des pages par rapport à la racine avec un poids indiquant le nombre de passages (page de garde exclue).
        A partir de la, on fait tourner le site, et genre chaque semaine ou fait une modif de positionnement des pages. On fait ca pendant trois ou quatre mois afind de générer des mutations:
        Une brun d'ADN= une page
        L'ensemble du site = une cellule
        On part sur une base de quatre cellules pour la première génération (voir au dessus pour le nombre de quatre).

        Puis le programme fait evoluer le tout... A voir dans les détails pour la suite.
        • [^] # Re: L'option qui tue

          Posté par . Évalué à 1.

          Du coup à chaque mutation du site, les moteurs de recherche balancent plein de liens morts et les 404 fleurissent. Par suite la page la plus demandée devient la page qui affiche le 404 et le site meurt du cancer...

          Sans compter l'utilisateur qui retrouve jamais la page qu'il veut au bonne endroit.

          Effectivement c'est un option qui doit bien tuer un site.
          • [^] # Re: L'option qui tue

            Posté par . Évalué à 2.

            Je n'ai pas dit que je changais les noms des pages web, j'ai dit que je reditribué, SUR LE SITE, la position de leur affichage ...

            De plus, après un certain temps, les pages vont afficher leur lien toujours au meme endroit.
            Comme le nom ne change pas, les pages vont etre accessible.

            C'est juste un concept, ca peut etre sympas de voir son fonctionnement non ?
            • [^] # Re: L'option qui tue

              Posté par . Évalué à 1.

              Évidemment que le concept est sympa, faut pas prendre tout au premier degré.

              Non plus sérieusement si les statistiques de fréquentation influent sur le positionnement, et qu'on sait déjà que le positionnement influence énormément la fréquentation. Faut voir si les mutations rendent le système viable, ou si le cycle boucle sur lui même et bloque certaines pages à certains endroit...
    • [^] # Re: L'option qui tue

      Posté par . Évalué à 1.

      Le "déplacement'" dans un site c'est bien, mais tu n'as pas vraiment de moyen pour le suivre : voir le paragraphe 4.v du doc suivant http://analog.cx/docs/webworks.html(...)
      • [^] # Re: L'option qui tue

        Posté par . Évalué à 2.

        En fait, le V4, j'en ai, pour une grande partie, déjà connaissance. Mais ce que je souhaite, ce n'est pas de suivre leur passage, mais de voir quels pages recoivent le plus de passage.
        • [^] # Re: L'option qui tue

          Posté par . Évalué à 1.

          Avoir du style une boîte "Most visited pages" ?
          • [^] # Re: L'option qui tue

            Posté par . Évalué à 2.

            Non, me servir de ce genre de stats avec un moteur en arrière qui gère de manière dynamique la "visibilité" des pages sur le site, voir de gérer la présence de liens menant à ces pages.
  • # Pourquoi pas un projet sourceforge?

    Posté par . Évalué à 1.

    Interessante idée de reprendre la succession de webalizer, mais ce serait AMHA
    mieux si cela se faisait sous la forme d'un projet sourceforge, au lieu de se
    la jouer "perso" :-)

    Swix, curieux de voir comment ça va évoluer.
  • # ModLogAn

    Posté par . Évalué à 3.

    Il y a le projet ModLogAn qui un peu pris le relais de Weblizer :

    http://jan.kneschke.de/projects/modlogan/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.