Discussion :

[Nico28]

Bonjour à tous,

Pour une application de supervision de processus industriel, je dois inclure un journal de "log", répertoriant les erreurs et les actions de l’utilisateur et/ou du processus.
Pas de souci pour collecter les informations mais c'est plutôt au niveau de la sauvegarde. Je m'explique :

A chaque "événement", ouvrir le fichier le fichier en mode "append", écrire la ligne puis refermer le fichier, je me rends compte que cela consomme énormément de temps lorsque je passe un analyseur de performances.

Quelqu'un a t il une meilleur idée du principe à utiliser ? création d'un cache ? autres ...

[sevyc64]

Çà consomme énormément de temps mais tout est relatif.

Tu ne dois pas y écrire si souvent que ça, dans le log quand même.

Tout autre solution signifierait de ne pas écrire directement dans le fichier, mais de garder ça dans une mémoire temporaire ?
Il faut que cette mémoire soit pérenne. Imagine que ton logiciel, pour une raison ou une autre, plante. A quel moment le cache sera réellement écrit dans le fichier ? Ton logiciel aura-t-il eu le temps de le faire avant de planter ?
Si non, quand tu relance le logiciel par exemple, est-ce que le cache non encore écrit est toujours disponible pour être écrit dans le fichier ou est-il définitivement perdu ?

Si ces points là ne sont pas problématiques, tu peux utiliser un cache. Si la priorité est d'avoir le log, il faut écrire au plus vite.

Une solution serait de garder le fichier ouvert (c'est effectivement généralement l'ouverture et fermeture qui prennent le plus de temps), mais c'est pareil, si ça plante alors que le fichier reste ouvert, faut être sur que tout est bien écrit quand même dans le fichier, faut-être sur aussi que le fichier sera récupérable après plantage. S'il reste ouvert, il peut être endommager lors du plantage.

Il n'y a pas de solutions parfaites, il n'y a pas de réponses universelles, mais pour moi Ouverture/Écriture/fermeture me semble bien souvent la méthode la plus fiable.
Et si les volumes à écrire sont trop important, on remplace le fichier par une base de données gérée par un SGBD

[Nico28]

Mon diagnostic est le même que le tient, pas d'autres solutions en cas de plantage !!

Mais je m'interroge sur le fonctionnement des journaux de logs sous Windows, qui eux justement fonctionnent en cas de plantage !!

[Pol63]

si tu as une base de données autant logger dans celle ci
si tu n'en as pas je trouve ça étrange ...


après sur la consommation ca dépend de ce que tu fais
enregistrer un texte complet qui se retrouve souvent le même c'est idiot, un identifiant de message suffit
de plus le format texte prend de la place pour rien (enfin sauf si on veut que le fichier soit lisible sans passer par ton logiciel)
sinon une date c'est 8 octets et un identifiant du type de message ca en prendra 4 ou 8, soit 16 octets au pire à ajouter à chaque évènement

après le log de windows ne fonctionne que quand le programme qui log les infos de plante pas, je ne vois pas ce que voulez dire par là
et sinon il doit enregistrer une date, un type d'event et un identifiant d'event, les infos détaillées et donc variables doivent être dans un autre fichier (ce qui permet d'afficher la liste rapidement, et le détail quand on clic sur un event)

[sevyc64]

après le log de windows ne fonctionne que quand le programme qui log les infos de plante pas, je ne vois pas ce que voulez dire par là

Il veut certainement parlé du DrWatson. Ce système est une surveillance externe du processus directement pas Windows. lorsque Windows détecte un plantage du processus il génère très probablement un évènement qui peut être capturé, pas par le processus lui-même qui est planté mais par un processus ou logiciel annexe.

Je ne sais pas comment cela marche exactement, mais j'utilise un outil comme ça dans un des logiciel que je maintiens actuellement. J'utilise MadExcept (pour Delphi), ça rajoute des composants dans le logiciel. A l'utilisation, j'imagine que le code de surveillance vient s’exécuter dans un thread séparé de sorte qu'au moment du plantage (tel qu'on l'à paramétré, nous), une copie de l'écran du logiciel est faite, une copie de certaine données de l'espace mémoire du logiciel est faite, le tout est envoyé par mail sur nos serveurs.

[Pol63]

enfin si on met des try catch partout et qu'on a pas de fuite mémoire un programme .net ne plante pas
donc dans le catch on peut enregistrer tout ce qui est nécessaire

et s'il plante hors try catch en général il y a la pile des appels dans le log windows