Bienvenue sur le forum !

Si vous souhaitez rejoindre la communauté, cliquez sur l'un de ces boutons !

Qt 5 : 5.9.0 - Qt Creator : 4.3.0 - Qt Installer : 2.0.3 - JOM : 1.1.2 - Qt Build suite : 1.7.0 - VS Qt 5 : 2.0.0

HbLog : bibliothèque de log distribuée

September 2015 modifié dans Vos projets
Bonjour tout le monde,

Aujourd'hui je viens vous présenter une bibliothèque de log (HbLog) appartenant au projet global HB.
HB est une partie de mon travail que j'ai décidé de rendre open source. Cela comprend :
* HbLog
* HbPlugin
* HbLink
* HbNetwork

Je vais parler d'HbLog en particulier, les autres auront leur topic dédié.

HbLog est une bibliothèque de log distribuée simple et performante. Elle permet de tracer dans un contexte multi-thread, multi-application et multi-machine grâce à un mécanisme d’imbrication d'entrées/sorties.

Fonctionnalités:
- Niveaux de log standard : trace, debug, info, warning, error, critical, fatal
- Aucun blocage de l'application (free lock programming)
- Paramètrage facile des entrées/sorties (arguments de programme)
- Redirection des qDebug qWarning et qCritical
- Unicité des traces dans le temps
- Sorties possibles : console, gui, fichier (avec rotation), socket local, socket tcp
- Entrées possibles : socket local, socket tcp
- Réinjection des entrées dans les sorties, ainsi les traces peuvent être relayées par plusieurs applications avant d'être centralisées vers un outil de supervision.

Un superviseur de traces nommé HbLogViewer permet également d'afficher de manière commode les traces injectées dans le réseau.

Fonctionnalités :
- Configuration de HbLog via les arguments du programme
- Visualisation de fichier de log
- Choix des couleurs des niveaux de log
- Filtres
- Double clique sur la trace, elle s'affichera dans votre éditeur favoris

Pour plus d'infos =>
wiki/dépot : wiki.hb-io.com
docs : doc.hb-io.com
bin : bin.hb-io.com

keyga aka hasboeuf ;)

Réponses

  • Voila une excellente initiative, on n'a jamais assez de solution de LOG quand on est développeur.

    On espère toujours trouver le saint-grâal du log ;)
  • September 2015 modifié
    Pour un cas d'utilisation simpliste :

    Ajout d'une entrée tcp sur le port 3004 du superviseur :
    HbLogViewer.exe -hblog-input-tcp:3004

    Ajout d'une sortie tcp sur le port 3004 en local sur votre programme :
    MonProgramme.exe -hblog-output-tcp:3004:127.0.0.1

    main.cpp

    ...
    #include <HbLogService.h>

    int main(int argc, char *argv[])
    {
    QApplication a(argc, argv);

    hb::log::HbLogService::processArgs( argc, argv );

    Window w;
    w.show();

    return a.exec();
    }


    Window.cpp

    ...
    #include <HbLogService.h>

    using namespace hb::log;

    Window::Window(QWidget * parent) :
    QMainWindow( parent )
    {

    // Log -> Ajout d'une sortie console via le code.
    QString error;
    if( HbLogService::outputs()->addConsoleOutput( &error ) == 0 )
    {
    printf( "HbLog error: %s", HbLatin1( error ) );
    }

    QString url = "qtfr.org";
    HbInfo( "Hello %s", HbLatin1( url.toString() ) ); // Les traces respectent le printf style.
    }
    Voilà le strict minimum à savoir ;)
  • Bonsoir,
    Sympa comme projet.
    Merci du partage. Dommage qu'il manque une petite licence.
    Petite coïncidence, je suis justement entrain de tester Boost::Log.
    A tester donc.
  • Salut Loupium,

    quelle licence faudrait-il ?
  • September 2015 modifié
    Bonjour,
    A toi de choisir, ou de la faire.
    Maintenant, je t'avoue que je privilégie les lib LGPL, MIT ou BSD (les moins restrictives) car face au faible temps que je consacre à mes projets logiciels, je n'est justement plus le temps d'apprendre et de maitriser 2 lib : une pour les projets open source et l'autre pour les projets propriétaires.
  • J'ai regardé rapidement le code :
    - c'est vraiment du bon boulot (il y a toujours matière à discuter les choix, mais ton montre que tu as fait les choses en réfléchissant, pas en faisant des choix non réfléchis... et c'est le principal)
    - le code est clair, compréhensible. Il faut un peu plus de docs, mais celle qu'il y a déjà est beaucoup mieux que pas mal de projets
    - manque de tests (il y en a ?) Et donc plus généralement, testes tu ton code (tests unitaires, clang analyze, valgind, etc)
    - merci pour le remerciement de QtFr sur le wiki
    - il faut effectivement préciser la licence

    Une question plus délicate. Pour un système distribué, il y a toujours le problème de la syncho temps (surtout pour un système de log). J'ai regardé HbSteadyDateTime, mais manifestement, tu ne fais pas syncho. Oubli ou c'est volontaire ?

    Bon courage
  • Merci gbdivers d'avoir pris le temps de regarder ! Ça fait plaisir.

    Pour tes remarques en effet, il manque de la doc pour un dev qui reprendrait le projet. En revanche les classes fronts sont documentés (question de priorité).

    Pour les tests, j'avoue ne pas en avoir, du moins unitaires. Il faut que j'y remédie ou plutôt que je trouve le temps (pas plus tard qu'aujourd'hui on m'a fait la même remarque). Néanmoins les tests fonctionnels existent pour chacune de mes bibliothèques. L'occasion de tester QTest ? ;)

    Ta remarque est pertinente pour HbSteadyDateTime. Cette classe a surtout pour but d'avoir un timestamp unique au sein d'une application. J'ai déjà réfléchis au problème de synchro et je n'ai pas de solution légère pour le moment, si tu as des pistes je serais ravi de les entendre. Le plus simple en l'état est de synchroniser l'horloge des machines utilisées sur le même serveur ntp.

    Encore merci ;)
  • September 2015 modifié
    Salut,
    Je regarde un peu le code, je suis curieux ;)
    J'ai une question pure c++, a quoi sert de déclarer une fonction virtuelle en "final" dans le cas de la classe HbLogger par exemple.
    Cette classe n'hérite pas d'une autre classe, donc quel est le but de
    virtual void setLevel( Levels level ) final;
    par exemple ?
  • Bien vu

    Je ne vois a priori qu'un effet : interdire le masquage de la fonction (sans le virtual + final, rien n'interdit a quelqu'un de dériver la classe et de créer une fonction setLevel qui va masquer la fonction de HbLogger).

    En termes de coût, il est fort possible que le compilateur devirtualise la fonction et donc que cela n'a pas de coût supplementaire (http://hubicka.blogspot.co.uk/search/label/devirtualization).

    En termes de bonnes pratiques, je n'ai jamais vu cela. Et je suis un peu dubitatif, je n'aime pas trop cette syntaxe. Je ne sais pas d'ou elle vient (Java ? Les fonctions sont virtuelles par defaut je crois et il existe le mot clé final)
  • Salut baba,

    pour verrouiller l'API en quelques sortes. Si un dev a besoin d'hériter de HbLogger pour ajouter ses comportements, je m'assure de l'intégrité fonctionnelle de la lib en verrouillant les méthodes qui ne doivent pas être modifiées.
  • Merci à vous deux,
    effectivement, je vois maintenant l'intérêt d'éviter le masquage.
  • @keyga: je ne suis pas sur que ca soit une bonne pratique (en tout cas, je déconseille de faire cela).
    Le dev d'une lib fournit quelque chose qui respect un contrat. Mais ce n'est pas a lui d'obliger les utilisateurs a respecter ce contrat.
  • September 2015 modifié
    Tu as raison, mais je pense que ça se discute au cas par cas, un framework comme Qt ne pourrait par être verrouillé, ca serait inexploitable. Restreindre l'accès dans une bibliothèque minimaliste en fonctionnalités, pourquoi pas.

    En tout cas
    Et je suis un peu dubitatif, je n'aime pas trop cette syntaxe. Je ne sais pas d'ou elle vient (Java ? Les fonctions sont virtuelles par defaut je crois et il existe le mot clé final)
    n'est pas un argument valable, tu me l'accorde.

    A noter que j'utilise aussi "final" dans certaines classes non exportées. L’intérêt ? Verrouiller une conception initiale en évitant de la casser x mois plus tard, quand la réflexion est loin. Ca permet de s’interroger => "ah pourquoi j'avais verrouillé ce point au départ ? était-ce pertinent ?" et de déverrouiller au fur et à mesure des besoins.
  • Je ne disais pas que l'on ne pouvait pas interdire le masquage, mais qu'on ne devrait pas le faire.
    De plus, c'est une façon de détourner l'utilisation de mots-clés pour des usages qui n'ont pas été prévu (voir explicitement interdit - sinon final n'aurait pas eu de restriction aux fonctions virtuelles).
    et de déverrouiller au fur et à mesure des besoins.
    Et donc ne pas respecter l'OCP.
    A priori, cela n'a pas d'impact sur les appels de fonctions (et donc cela ne cassera pas le code), mais il faut éviter de casser une API.

    Bref, trop de raison pour ne pas faire cela et pas de raison en faveur de cette approche.
    De plus, une bonne pratique doit résulté d'une réflexion collégiale, ce code semble assez marginal. Je suis curieux d'avoir d'autres avis.
  • September 2015 modifié
    Marginal surement parce que ce mot clef est nouveau rien de plus et ce n’est pas avec des remarques comme "ça vient du java, c'est sale" que ça va changer (le compilo s'en sert pour optimiser certaines choses). Je vais enlever les brides dans HbLog, je suis d'accord de l'inutilité dans ce cas (et si ça fait tant de peine à l'OCP :D).

    J'ai travaillé quelques années dans un département dont le rôle était de créer des briques logicielles que d'autres départements utilisaient. Nos "clients" étaient donc internes à l'entreprise. Tu ne peux pas savoir à quel point brider nos API nous a fait gagner du temps et de la qualité. Les raisons ? Les personnes changent, ne restent pas longtemps, sont plus ou moins impliqués, n'ont pas le temps de faire les choses bien et de s’imprégner du fonctionnement des APIs etc. Tout ceci induit des débordements, une mauvaise utilisation de ces APIs et débouche sur des produits dont la qualité se dégrade très vite.

    Donc tu ne m’empêcheras pas de penser que ce mot clef a son utilité en entreprise. En revanche, dans un environnement open-source, c'est en effet plutôt ridicule.

    Bref... vous pensez quoi de "override" ? ahah



  • September 2015 modifié
    C'est toi qui interprète mon "Java ?" par "cela vient du Java, c'est mal". Je me posais juste la question de savoir ou tu avais trouvé cette pratique. (Beaucoup de nouvelles fonctionnalités du C++11/14/17 viennent de d'autres langages. Et franchement je m'en moque du Java).

    Mon problème n'est pas que tu utilises final (ou override), mais que tu l'utilises de façon détournée.
    Ok, supposons que c'est un hack nécessaire pour combler un manque du langage. Le problème reste : ce n'est pas a une lib de verrouiller son utilisation, juste vérifier les contrats.
  • September 2015 modifié
    D'où ma réponse, j'ai vu cette pratique en entreprise.

    Je réitère, je comprends qu'en distribuant une lib open source, ça n'est pas approprié (le but est pourtant de faire gagner du temps au dev m'enfin c'est une discussion sans fin), je vais donc faire les modifs nécessaires. Pour les autres situations, d'expérience, le gain peut être non-négligeable.
Connectez-vous ou Inscrivez-vous pour répondre.