viabilité de la bibliothèque de journalisation c++ pour la capture asynchrone de données à haut débit ?

Question

Je travaille avec un système en temps réel écrit en C++. Nous cherchons à utiliser soit boost soit pantheios pour la journalisation. Le système a des exigences de journalisation standard qui, j'en suis sûr, peuvent être satisfaites par l'un ou l'autre des frameworks, mais en plus nous voulons être capables de journaliser toutes les entrées capturées par ce système. Cette entrée sera capturée par plusieurs threads, y compris certains threads qui ont des contraintes en temps réel et ne peuvent pas se permettre des retards significatifs dus à une journalisation inefficace. Cela devrait se traduire par un débit élevé de données à enregistrer.

Je souhaite avant tout savoir si l'un ou l'autre de ces cadres peut être fiable pour gérer un tel débit de journalisation à partir de plusieurs threads sans retarder mes threads critiques. En outre, nous pourrions avoir besoin d'effectuer un nettoyage des données, ce qui nécessiterait l'ajout d'une sorte de crochet capable d'identifier les entrées de capture qui ont des données sécurisées, d'exécuter notre crochet de nettoyage des données et de maintenir un tampon contenant les mappings des valeurs qui ont déjà été nettoyées.

Je pense que les deux plateformes de journalisation peuvent le faire, mais ce n'est pas clair pour moi après un rapide coup d'œil à leur API. Quelqu'un qui a utilisé l'un ou l'autre de ces outils de journalisation peut-il me donner son avis sur leur efficacité dans ce contexte, sur la facilité avec laquelle il serait possible de mettre en œuvre ce que j'ai décrit, ou sa préférence entre les deux cadres de journalisation ? Toute information serait vraiment utile.

Merci

Answer 1

J'ai fait de la journalisation dans de grandes situations multithreadées. Mon expérience était la suivante :

• La journalisation n'est là que pour le bénéfice des développeurs. Personne d'autre ne lira ou ne comprendra les fichiers journaux.

• Découpler la génération des messages d'enregistrement et la manière dont ils sont enregistrés.

• Si vous voulez rendre la génération des messages de log plus efficace, utilisez d'abord un contexte rapide, vérifiez si quelque chose est en train de loguer ce contexte et si non ne générez pas. Sinon, générez le message. (L'utilisation la plus courante de cette technique est un "niveau" qui peut être "debug" "info" etc. et si rien n'est journalisé à ce niveau, nous ne créons pas le message).

• Chaque cas d'utilisation devrait avoir un identifiant spécial généré qui reste avec ce cas d'utilisation et tout ce qui est enregistré à partir de celui-ci affichera cet identifiant de cas d'utilisation.

• Enregistrez également l'identifiant du fil qui génère le message.

• Utilisez un fil d'exécution distinct de celui qui génère le message pour effectuer la journalisation. (La bibliothèque de journalisation de Boost procède de cette façon).

• Attention à ne pas devenir "fou de macros" bien que des macros légères permettent d'ajouter des choses comme DOSSIER y LIGNE automatiquement sont ok.

Answer 2

J'utilise la bibliothèque de journalisation Boost écrite par Jon Torjo et celle-ci propose d'effectuer toutes les écritures dans les fichiers de journalisation à partir d'un thread dédié, de sorte qu'il n'y a pas de retard d'E/S sur le thread qui effectue la journalisation. L'inconvénient est que, lorsque le système se plante, certaines déclarations peuvent ne pas être enregistrées, car la bibliothèque utilise une file d'attente interne.

Mais d'une manière générale, cette bibliothèque est très performante, elle vous offre de nombreuses options différentes et je pense qu'elle pourrait être une bonne option pour vous, si vous êtes prêt à faire des sacrifices sur les messages.

Si ce n'est pas possible, vous devrez effectuer des entrées/sorties à partir du thread qui doit enregistrer, ce qui n'est vraiment pas idéal sur un système en temps réel.

Si vous êtes sous Windows, vous savez que ce n'est pas un système d'exploitation RT, n'est-ce pas ?

Answer 3

Vous pouvez envisager http://www.logog.org . Il semble que vous soyez confronté aux mêmes problèmes que moi lorsque je l'ai écrit. Je l'ai écrit à l'origine pour enregistrer un moteur DSP audio multithread, ce qui est bien sûr l'essence du rendu à temps critique.

Voir aussi https://stackoverflow.com/questions/696321/best-logging-framework-for-native-c