Thread safe logging

Bonjour,

N'étant pas très sur que les terme "Thread safe logging" correspondent bien à mon besoin, je vais tenter de l'expliciter :

Je cherche une bibliothèque, capable de gérer une pile d'écriture sur un fichier log, et qui éviterai des chevauchement de message de type :
Entête A
Entête B
Corps A
Entête C
Corps B
Corps A

Pour obtenir quelque chose comme :
Entête A
Corps A
Entête B
Corps B
Entête C
Corps C.

Le tout étant de ne pas bloquer l'exécution des threads qui attendrait la fin de l'écriture dans le fichier log pour continuer leurs taches.

Connaitriez-vous des bibliothèques qui correspondrait à mon besoin?
(Si vous en connaissez plusieurs, tant mieux, j'ai besoin d'être exhaustif dans mes recherches).

Merci d'avance,

Olivier

A priori, si tu trouves un programme ou une lib qui permet de faire ça, ça m'intéresse fortement. Elle devrait comporter une module de lecture dans les pensées du programmeur qui pourrait probablement se revendre assez aisément et pour une somme non négligeable :)

Tu n'auras pas d'autre solution que d'implémenter ce qui correspond à tes besoins par toi même. Note quand même que ce type de log (qui regroupe les informations) est tout de même dangereux, parce que tu bufferises nécessairement (donc en cas de problème, tu peux manquer des infos).

Je pense que je n'ai pas saisi l'origine de la pointe d'humour..

Il ne s'agit pas de deviner quelles sont les intentions du programmeur, mais d'éviter qu'un message que l'on souhaite inscrire dans un log soit entrecoupé par un autre message provenant d'un autre thread.

Il m'avait semblé avoir entendu parler de log4j pour faire ce genre de chose en java..

Citation:

---

Envoyé par Olivier.Ramon

Je pense que je n'ai pas saisie l'origine de la pointe d'humour..

---

Ah ?

Citation:

---

Envoyé par Olivier.Ramon

Il ne s'agit pas de deviner quelles sont les intentions du programmeur, mais d'éviter qu'un message que l'on souhaite inscrire dans un log soit entrecoupé par un autre message provenant d'un autre thread.

---

Et comment est-ce que le système est censé deviner que tel message viens de tel thread ? Et plus important, comment est-ce qu'il est censé savoir quel sont les points où il peut donner la main à un autre thread ? Le tout, sans attente de du thread appelant ?

Citation:

---

Envoyé par Olivier.Ramon

Il m'avait semblé avoir entendu parler de log4j pour faire ce genre de chose en java..

---

log4j implémente un mécanisme de synchro donc ça veut dire qu'à un moment ou à un autre, il y a une attente. A un moment donné, il faut de toute façon qu'on implémente un point de synchronisation, même le plus petit possible, pour éviter qu'une opération atomique ne soit entrecoupée par d'autres opérations. Demander à une librairie de le faire revient à lui demander de mettre elle-même les points de synchro en fonction de ce qu'elle doit afficher, donc de comprendre non seulement ce qu'elle affiche mais aussi les intention du programmeur - parce qu'une chaine peut être fractionnée, et dans ce cas la lib doit se dire "ok, je sais qu'il va encore m'envoyer quelque chose donc je ne donnes pas la main tout de suite à un autre message de log").

D'ou mon trait d'humour :)

Si c'est pour un environnement Windows regarde Winlog. Cela fait ce que tu demandes.

Je vois ce que tu veux dire. Mais en fait, mon but n'est pas qu'il gère la priorité de tel ou tel thread, mais que les messages ne soit pas coupé en plusieurs morceaux.

Alors certes, il est possible de bloquer l'accès à l'écriture aux autres threads pour que le message soit écrit en un bloc, mais ne serait-il pas possible d'avoir un thread à part, qui gère une pile d'évènement ( un évènement = une écriture sur le log). Et n'y a-'il pas de bibliothèques donnant les outils pour ce genre de tache?

J'entrevois les problèmes que cela induit (pile qui s'allonge, risque de perte d'info en cas de crash), mais ces risques semblent rentrer dans mon cahier des charges.

€dit : Merci ram-0000, je vais regarder ça

Citation:

---

Envoyé par ram-0000

Si c'est pour un environnement Windows regarde Winlog. Cela fait ce que tu demandes.

---

Juste pour info: log4j implémente une écriture atomique pour un seul statement de log, donc pas de magie si on fractionne son message de log il y a entrelacement entre les threads...par contre c'est fait pour que la partie synchronisée soit la plus courte possible. Il prend des messages entiers, donc chaque thread paie le temps d'élaboration du message sur son temps CPU, en-dehors de la section critique.
Globalement, comme Emmanuel, je vois mal comment une lib de log pourrait "deviner" que l'entrée atomique est finie...

Citation:

---

Envoyé par therwald

Juste pour info: log4j implémente une écriture atomique pour un seul statement de log, donc pas de magie si on fractionne son message de log il y a entrelacement entre les threads...

---

Qu'est ce que tu entends par "statement de log"?

(C'est pas que j'ai réellement compris le reste du message, mais je pressens que cette information est nécessaire pour comprendre le reste)(noobie inside)

il veut dire que si tu fais:

Code:

---

1 2 3 4

log("Error: in file "); log(filename); log(" error message: "); log(message);

---

ton messahe sera fractionné
et que donc tu vas devoir faire

Code:

---

1 2 3

sstringstream message; message << "Error: in file " << filename << " error message: " << message; log(message.c_str());

---

un statement de log c'est un appel de méthode sur le logger.

exemple log4j:

Code:

---

1 2	logger.info("Bien qu'il fasse plusieurs lignes et aggrège des infos\nCe message sera loggé de manière atomique. Contenu:\n"+contenu);

---

contenu étant une chaîne de caractère élaborée avant l'appel. Comme le message envoyé contient des \n, il sera sur plusieurs lignes. Il aggrège plusieurs données. Mais il sera loggé unitairement car il est transmis en un seul appel de méthode de logger. A ma connaissance, c'est le seul moyen de faire savoir à une API de log que ce message est une unité indivisible.

Merci pour l'explication (très claire qui plus est), je comprend un peu mieux.


Mais quitte à dire une connerie, pourquoi ne pas ajouter un paramètre indiquant si le message est terminé ou s'il va y avoir un deuxième envoi ?

Citation:

---

Envoyé par Olivier.Ramon

Mais quitte à dire une connerie, pourquoi ne pas ajouter un paramètre indiquant si le message est terminé ou s'il va y avoir un deuxième envoi ?

---

Ce serait possible en java en utilisant un stockage local à la thread pour le buffer de message qui accumule. C'est faisable en java avec un threadlocal (mais avec des coûts de synchro supplémentaires), mais les concepteurs de log4j n'ont pas jugé utile de le faire peut-être pour des raisons de rapport coût (complexité, contention, conso mémoire)/bénéfice(fréquence du cas) défavorable, je ne sais pas. Je ne connais pas les primitives dispo en C++ pour faire du stockage local aux threads, mais c'est certainement dispo dans les différentes implémentations de thread, avec la même analyse coût/bénéfice à faire. Finalement il est peut-être plus simple et efficace pour tout le monde de laisser la thread élaborer son message puis le logger en un seul appel. Par ailleurs, en java il y a moyen de marquer les messages avec un identifiant de thread pour suivre les séquences. Peut-êrtre qu'on peut faire pareil avec les différentes implémentations de thread en C++.

Citation:

---

Mais quitte à dire une connerie, pourquoi ne pas ajouter un paramètre indiquant si le message est terminé ou s'il va y avoir un deuxième envoi ?

---

je vais dire que c'est possible, mais tu repousses le problème sur tous les programmeurs qui utiliseront la bibliothèque; ils peuvent tous commettre une erreur et tu multiplies les chances de bug par le nombre de programmeur.
en gros tout ce qui est necessaire au bon fonctionnement du log devrait être dans le log lui même et la partie incombant au programmeur externe devrait être minimal. c'est très important surtout pour du log, on veut que ce soit aussi simple et rapide que possible de pouvoir logger tout ce dont on a besoin.

Je ne sais pas exactement à quoi tu fais allusion, screetch, mais:
1) combinaison de messages. Finalement, il n'y a rien à faire: élaborer ton message unitaire comme tu as besoin qu'il soit et le logger en un appel. De toute façon ce sera spécifique à chaque application => pas de moyen simple de le faire dans la lib pour remplir tous les besoins
2) marquage par les threads: c'est définitivement une fonctionnalité de log4j. Une lib en C++ pourrait aussi le faire sans doute. Je ne sais pas dans quelle mesure ce serait compliqué puisqu'au lieu de devoir manipuler une seule implémentation de threads bien connue, tu dois dealer avec plusieurs, pas nécessairement compatibles.

je répondais au post d'avant, il y a eu cross posting

Citation:

---

je répondais au post d'avant, il y a eu cross posting

---

Alors je comprends mieux ta réponse, et je plussoie fortement!

Par ailleurs, dans la colonne "coûts", rappelons ce que dit Emmanuel:

Citation:

---

Note quand même que ce type de log (qui regroupe les informations) est tout de même dangereux, parce que tu bufferises nécessairement (donc en cas de problème, tu peux manquer des infos).

---

Et le log étant avant tout une question de diagnostic, maximiser la fiabilité d'écriture est clairement plus important que faire de la collecte de message que les applications peuvent tout aussi bien faire elles-mêmes.

Pour les histoires de thread, la lib peux très bien mettre dans le log le pid, le thread id, et au final les infos sont là.

Par contre, il me semble que c’est conceptuellement une grosse connerie de vouloir grouper au moment de l’écriture du log. Ce que je demande à un log, c’est de refléter la réalité. Si des choses sont entrecoupées, alors il est normal qu’elles le soient dans le log. L’atomicité doit se faire au niveau d’une ligne de log, pour garder la lisibilité, mais pas plus.

Pour ce qui est de vouloir suivre le log, et notamment suivre le chemin d’exécution d’un seul thread, par exemple, alors c’est un problème d’outil de lecture, qui doit savoir extraire l’information pertinente. Le log doit seulement lui donner les moyens de le faire (pid/thread id doit être suffisant).

Je suis d'accord avec toi sur le plan général:oui, l'entrelacement est représentatif de ce qui se passe vraiment dans l'application. Concernant la problématique en-tête/contenu soulevée initialement par Olivier.Ramon, il peut être compréhensible de vouloir les garder groupés, dans la mesure où l'en-tête contient des informations récoltées au même moment que le contenu principal. On reste alors dans le cadre d'un état instantané de l'appli. Ceci dit, il n'y a alors pas besoin d'un mécanisme complexe susceptible de diminuer la fiabilité des logs: il suffit simplement d'élaborer le message complet et de le logger en une fois.

ou alors comme le dit white_tentacle, il suffit a la lecture du log de faire cat log.txt | grep 3456 si tant est que le thread ID qu'on est en train de regarder est 3456.

Je suis assez d'accord.
Simplement au lieu de faire

Code:

---

1 2 3 4 5

logger.log("Fichier courant"); logger.log(nomFichier); logger.log("élément courant"); logger.log(nomElement);

---

il faut faire:

Code:

---

1 2	logger.log("Fichier courant:"+nomFichier+" élément courant:"+nomElement);

---

Parce que c'est:

1. plus lisible
2. plus efficace (une contention par appel, remember)
3. éventuellement plus clair si d'aventure certains logs ressemblants pouvaient être produits en d'autres points de code.

Il ne s'agit pas de faire des opérations complexes susceptibles d'effet de bord dans le but d'élaborer les logs, simplement de se rappeler que pour un message atomique, même variablilisé, il faut élaborer puis logger en un appel.

Finalement, il a été décidé d'implémenter intégralement le logging, avec un thread possedant une pile (deque) d'évènement, contenant chacun un message à écrire ; le mutex étant sur la modification de la pile.

Je vous remercie tous pour vos avis et vos conseils.

De rien. Notez que mutex ou pas si vous ne voulez pas d'entrelacement votre deque devra recevoir en un appel le message en-tête+contenu. Si vous ne souhaitez pas cette contrainte, le log sera entrelacé, mais en postant sur chaque appel un thread_id vous pourrez filtrer avec un outil d'extraction et n'avoir que les traces d'une thread, comme le suggérait white_tentacle