yahi un agrégateur de statistiques dans l'esprit d'awstats

Posté par  (site web personnel) . Édité par Benoît Sibaud, palm123 et Xavier Teyssier. Modéré par Xavier Teyssier. Licence CC By‑SA.
Étiquettes :
18
24
avr.
2025
Administration système

J’ai la nostalgie d’awstats : la possibilité de faire des statistiques web sans déployer des tonnes d’infrastructure (genre Grafana).

Pour cela, j’ai codé Yahi, un module Python qui agrège dans sa forme basique les statistiques web en format usuel (nginx, apache, lighthttpd, varnish) pour les présenter dans une page web « tout en un ».

Il se décompose pour sa partie utilitaire en deux scripts:
- un d'agrégation des statistique de journaux de serveurs webs dont l'écriture d'une version personnalisée ici celle que j'utilise pour faire des démos sans IP ou URLs est relativement simple;
- un de génération d'une page de visualisation HTML avec les données.

Certes cette page requiert du JavaScript pour fonctionner, mais elle requiert zéro dépendance vers des liens externes et inclut autant toutes les visualisations que les données dans une seule page (données, CSS, visualisations). Cela permet de l’avoir en marque-page grâce à quelques ruses de javascript, et cela rend son hébergement aisé pour les sysadmins. (NdM: goaccess (MIT en C) sait faire aussi).

Son API permet en outre de faire des agrégations plus compliquées.

Et, je recherche des bétas testeurs pour en faire un produit fini.

Aller plus loin

  • # performances ?

    Posté par  . Évalué à 3 (+1/-0).

    J'ai une petite infra avec quelques services. Je génère 5M d'access logs par mois.
    Quel temps cela prendrait de générer les statistiques pour ce volume ?

    • [^] # Re: performances ?

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Sur ma machine je suis ~10K lignes par secondes (ce qui est la métrique pertinente au vu de la manière de parser) soit aux alentours de 2.5Mb en 1.5 seconde (core i3 3.5Ghz 2 procs).

      Il y a possibilité de par la nature du problème à paralléliser (map/reduce) si il y a besoin de performance, mais j'ai pas mis ça dans mes développements actuels.

      • [^] # Re: performances ?

        Posté par  . Évalué à 2 (+0/-0).

        J'ai écrit un outil un peu similaire, en python aussi. Ça fait du 25kl/s. Donc du même ordre de magnitude. GoAccess affiche 100kl/s … sur un i7.

        Je gagne un peu de temps en déplaçant le parsing du log dans un script awk pour produire un format unique en TSV qui est d'ailleurs le facteur limitant dans le pipeline.

        Le parsing de date est particulièrement et surprenamment coûteux en Python (et dans d'autre langage d'ailleurs) ; c'est souvent bénéfique de se passer de la lib standard et de faire le parsing soi-même.

        Quant aux structures de données, yahi utilise archery, j'utilise defaultdict ; je suppose que cela ne fait pas grande différence.

        De toutes façons 1/ il faut profiler pour savoir 2/ il ne faut pas attendre des performances de folie en Python.

  • # Python 2, abandonné?

    Posté par  . Évalué à 3 (+3/-0).

    Bien le bonjour, suite à ton article, j'ai tenté.
    Un bon vieux serveur sous Debian 8 Amd64 / Jessie, char d’assaut qui a survécu à plus d'une vague.
    Juste, ce n'est pas pip de python 3.
    Yahi / Debian 8 Jessie

    • [^] # Re: Python 2, abandonné?

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Ah ?!

      Ça passe. 0_o

      Content de voir que mes test avant installation sont appelés et chouinent pas :D

      • [^] # Re: Python 2, abandonné?

        Posté par  . Évalué à -1 (+0/-1).

        Bonjour Jul, heuuuu…. ça passe???
        J'ai pas vu pareil en fait, dans la première on voie :
        Oui des tests effectués… mais se ballade une syntaxe error à peine plus haut.

        J'avoue, ne pas toucher le python, perso je m'en passerais bien.
        Mais trop de compile dépend de lui (j'accepte pour le Perl, mais python, comme un truc qui gratte)

        Quand j'ai vu votre réponse, j'y ai douté, me suis dit, surement comme vous,
        le test passe, ça roule… ma… non!

        Nan, c'est pas passé, il semblerait, qu' au fichier "yahi/init.py", ligne 161,
        une opération typé Python 3 exclusif genre :

        'if dt := dt_format(data.get("datetime")):'
        _____|-----> Invalide Syntax

        Là; j'ignore complétement si on fait une affectation, une comparaison ou une concaténation.
        Y a t'il un expert du Boa, ici?

        https://ibb.co/4Z4ygg2n

        au fait, Python c'est un serpent monstre sorti d'un labo nucléaire qu'a fini chez MS, non?
        Okay après sa retraite… retour au source.

        A vous les codeurs
        DarkHack

    • [^] # Re: Python 2, abandonné?

      Posté par  . Évalué à 6 (+4/-0).

      Par curiosité, pourquoi utiliser debian 8 plus supportée depuis 5 ans alors que debian 12 supporte très bien le matériel ancien ?

      J'ai un pc de 2008 en 32bit et il n'a pas de soucis à tourner sous Bookworm…

      • [^] # Re: Python 2, abandonné?

        Posté par  . Évalué à -3 (+1/-4).

        Bien le bonjour Steph1978, votre question est pertinente, mais pourquoi pas mettre à jour…
        J'me présente, DarkHack, seul DevOps de https://www.darkweb.fr, le domaine est mien depuis sa création en 2011, et jamais mit l’hébergement autre que chez moi.

        Cela ma permit d'avoir une solide expérience du libre, et cela me fait converger sur la maîtrise des capacités de calcul, plus c'est complexe, plus ça craint. Petit clin d’œil aux principes KISS.
        Au fond, j'aimerais même ne pas quitter Linux 2.6…

        Quand on découvre Debian, on réalise que c'est lui même, un ralentissement du cycle de développement, mais (et ici en est semble t'il un peu le sujet) en contrepartie, une stabilité
        des services assurée, par le temps des retours de bugs, d'adaptation etc oui, Debian, a un cycle de développement proche du produit FINI.

        Alors, je n'ai pas suivi ce rythme lent et stable 'en apparence'… Oui en effet, et pire encore, j'ai avancé et reculé… Linux 5.10 en 4.19.
        Pourquoi 2.6? Apothéose de la maitrise matériel Host, tunnel ip, toute la couche ipv4/6, gestion proc, mémoire, d'un stabilité à faire fonctionner une calculatrice sans écran (j'parlerais pas de Plan 9, promis ! ).

        En raccourci, rien de mieux qu'un bon exemple, aux quels je suis à l'heure actuelle impacté.

        OpenSSH… Dinosaure de nos servers, le machin qu'a permis à un OS en forme de poisson d'affirmer ne pas avoir eu de bugs depuis des années à la limite de la décennie…
        Tu fais tes mises à jour et boume tu tombes sur :

        CVE-2024-6387

        Regardez le web, observez, vous constaterez, que ce bug donne accès root à la machine.
        l'étrange étant que cela n'affecte que les version 8.5p1 à 9.7p1.
        C'est pas le protocole, c'est le source, un truc ajouté en forme de backdoors à partir du
        8.5p1… Je pense à une opération espadon, on attaque plus la banque mais le source du ssh…

        Le libre c'est bien, mais ça n’empêche pas la corruption, c'est humain…
        En ce moment, je pleure, je vois montagne de projet libre, se corrompre…

        On ne devrait mettre à jour qu'après avoir vu le 'diff' et valider concepts…

        RUST, c'est un flingue sur la tempe de professionnel qui avait chanté la même chanson par
        convictions le long de leur carrière pour changer tout à la fin… non, c'est pas l'argent.

        En espérant avoir pu vous partager le doute de la MAJ.
        Salutations à l'équipe
        DarkHack

  • # merci

    Posté par  (site web personnel) . Évalué à 1 (+0/-0).

    merci à l'équipe de linuxfr pour avoir pris le temps de rédiger la dépêche.

    La ndm sur goaccess est bienvenue car ça permet de se positionner sur le coté versatile plus que le coté web.

    Donc : merci.

  • # bravo

    Posté par  . Évalué à 1 (+1/-0).

    Super boulot,

    enfin une alternative crédible au vénérable awstats.

    simple, pratique est super efficace.

Envoyer un commentaire

Suivre le flux des commentaires

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