Discussion :

[mail.spam]

Bonjour,

Je suis développeur depuis quelques années sur Windev, je me suis auto formé à Windev avec le temps.

Lorsque je développe un logiciel j'y inclus toujours un fichier de LOG afin d'avoir un suivi des actions faites dans mon programme ainsi que les retours d'erreurs.

Quand j'ai commencé j'ai utiliser un fichier TXT, puis je suis passé un CSV et maintenant j'utilise XML (je préfère pour la lecture et je n'ai pas de souci de saut de ligne)

Mon problème aujourd'hui est que j'ai développé un programme qui tourne sur plusieurs jours en haut bout d'un certain temps j'ai mon fichier XML qui dépasse 2 Mo. Résultat je met des plombe à écrire dans mon log et je ralentie considérablement le programme.

Voici en gros le principe de ma procédure de log

Je charge le fichier log en cours dans une chaine avec fChargeTexte
Je cherche le nombre d'entrée de log afin d'y ajouter mon nouveau log à la fin du xml
Je reconstruit le XML avec XMLConstruitChaîne
puis je sauvegarde le fichier XML.

Voici un exemple de log

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?xml version="1.0" encoding="ISO-8859-1"?>
<WDTST Repertoire="C:\Program Files\PC-Soft\Windev 14\Programmes" Version="14.00Bic">
	<LOG Date="09/02/2011" Heure="09:38:00" Login="MailSpam" PC="SI" TypeLog="Information" Categorie="Programme" SousCategorie="">
		<Source>Initialisation de FPEE1_CENTRE_TRI_AUTO (), ligne 49</Source>
		<Description>Ouverture du programme</Description>
	</LOG>
	<LOG Date="09/02/2011" Heure="09:38:01" Login="MailSpam" PC="SI" TypeLog="Avertissement" Categorie="Programme" SousCategorie="ChangementMode">
		<Source>Procédure globale Set_Mode (Procedures Centre tri.Set_Mode), ligne 238
			Initialisation de FEN_Principale (FEN_Principale), ligne 2</Source>
		<Description>POM_OBLIGATOIRE</Description>
	</LOG>
	<LOG Date="09/02/2011" Heure="09:38:02" Login="MailSpam" PC="SI" TypeLog="Information" Categorie="Programme" SousCategorie="ChangementMode">
		<Source>Procédure globale Set_Mode (Procedures Centre tri.Set_Mode), ligne 186</Source>
		<Description>GESTIONCASES</Description>
	</LOG>
	<LOG Date="09/02/2011" Heure="09:38:10" Login="MailSpam" PC="SI" TypeLog="Erreur" Categorie="Programme" SousCategorie="">
		<Source>Procédure globale Put_RANGEMENT (Procedures Automate.Put_RANGEMENT), ligne 69 Procédure globale RangeOuvrant (Procedures Centre tri.RangeOuvrant), ligne 104</Source>
		<Description>Erreur lors de la demande de rangement, elle est annulé Si le problème persiste redémarrer le programme. si le problème continue après appelé le service informatique</Description>
	</LOG>
	<LOG Date="09/02/2011" Heure="09:38:13" Login="MailSpam" PC="SI" TypeLog="Information" Categorie="Programme" SousCategorie="">
		<Source>Fermeture de FEN_Principale (FEN_Principale), ligne 30
			Clic sur BTN_F12 (FEN_Principale.BTN_F12), ligne 1</Source>
		<Description>Quitter le programme</Description>
	</LOG>
</WDTST>

A oui ce fichier log est aussi consultable par notre service maintenance qui ne sont pas des informaticien mais qui sont amené à le lire pour leur besoin.
(C'est d’ailleurs pour cela que je suis partie sur le format XML plus lisible à mon avis)

Donc le but de ce post est d'avoir vos expérience sur la création de fichier LOG de gros volume. Comment les avez vous fait? quelles infos métez vous dedans? Comment les affichez vous pour des non informaticien?

Toutes les suggestions et avis sont les bien venu.

[Nicolas_Jeanneau]

Bonjour,

peut-être faudrait-il envisager de scinder le fichier en fonction d'un critère :
un par jour
un par taille de 1 Mo maxi
...

Le mieux est de voir ce qui est le plus significatif. Je pense qu'un par jour offre aussi la possibilité de gérer l'historique en supprimant les fichiers au bout d'un certains temps.

De scinder oblige malheureusement à revoir le processus de consultation des fichiers de log pour les jours précédents.

Ceci est une idée mais je ne pratique pas avec des fichiers. J'ai une table de traces directement dans ma base de données.

à bientôt,

Nicolas

[mail.spam]

Je créé un fichier par lancement du programme.
Mais je peux attendre 2 Mo en moins d'une journée.

[vmolines]

L'utilisation d'un XML implique de tout conserver en mémoire. De plus, le fait que vous chargiez et réécrivez le fichier à chaque écriture dans le log est très lourde.

Un fichier texte traditionnel peut être manipulé par ajout et donc beaucoup plus performant.

Si vous voulez rester sur un format XML, il faudrait peut être envisager de le manipuler comme une fichier texte normal et ne pas passer par les fonctions XML windev qui obligent à charger l'intégralité en mémoire pour réécrire.

[Marco46]

Ya l'option de Nicolas Janneau sinon tu peux toujours écrire à la main ton XML. Avec les fonctions fEcrit et fLit en te positionnant directement sur le bon offset tu boufferas pas de la RAM et ça sera plus rapide que de tout charger en mémoire avec XMLConstruitChaine().
EDIT : C'est la même idée que celle de vmolines.

Sinon pour l'affichage à tes techniciens de maintenance tu as le XSLT qui permet de facilement mettre en forme du XML. En fait tu as un fichier XSLT qu'il faut voir comme un filtre. Tu passes le XML dans le XSLT et en sortie tu obtiens un HTML. Pratique.

[hpascal]

Bonjour

J'utilise ce principe dans plusieurs applis et différemment selon l'application.
En général un fichier LOG par jour quand il y a peu de choses à écrire dedans.

Si le fichier contient beaucoup d'info, dès que le log en cours dépasse une certaine taille je le renomme et j'en ouvre un nouveau

Au niveau épuration j'ai un paramètre pour garder x jours de logs, traitement que je fais en sortie d'application en général.

J'utilise souvent un fichier texte simple (qui suffit à mes besoins) avec pour chaque ligne : date + TAB + heure + TAB + type d'info + TAB + détail de l'info
Avec une ligne d'entête contenant des infos concernant le poste (nom, user, résolution, espace disque ...)

J'y stocke des erreurs , des temps de traitements ...

[mail.spam]

Merci pour vos conseil.
Je vais continuer à générer un fichier XML mais je le traite maintenant comme un fichier texte.

Je ne clos pas ce post pour l'instant car je voudrais savoir quelles sont pour vous les informations typique à mettre dans un log.

Pour moi c'est

Le nom du programme
L'emplacement du programme
la version du programme

Le nom du login du PC
le nom du PC

La date et l'heure de l'ajout du log
le type de message (Information, avertissement, erreur, exception)
la catégorie du log (ce qui me permet de classer mes log)
une sous catégorie (ce qui me permet de classer mes log)
la ligne du code qui génère le log
une description.

[EDM-TAHITI]

Hello,
Je vais vous faire part de mon expérience de terrain. Tous mes logiciels possède un fichier journal que j'alimente avec les triggers de mes principaux fichiers (comptes_tiers, pieces_hestion, mouvements_gestion, etc...)
Ge fichier est constitué de la date, de l'heure, du nom du poste, de son ip, du nom de l'utilisateur, de l'action faites (hraye, hajoute, hasupprime, etc...) et d'un message (ChMessage est une chaine globale) qui est alimenté jusqu'a son enregistrement dans le fichier journal.
J'ai donc un 'bout de programme' caché si on est pas superviseur qui me permet de rechercher selon les critères ci-dessus tout ou parties d'actions, d'enregistrement qui ont été générées.
Ce fichier, au bout d'un mois, dépasse allégrement les 2Go, mais peut importe, puisque je ne fais que des ajouts, donc, jamais de blocage, jamais de ralentissement.
Et j'ai une procedure stockées qui enlève les anciennes lignes du journal (plus vieilles de 45 jours) et le tour est joué, le fichier reste dans des proportions acceptables... Sur un des logiciels, j'ai 7 postes, dont 5 qui font de la facturation/connaissements Navires, environ 1000-1500/jours et en backoffice, à la fin de chaque voyage, ils passent en facturation et en compta sage toutes les lignes.
J'ai mis cela en place afin d'avoir une vue précise des remontées des clients du type
- "Ah, ton logiciel a effacé ma ligne de facturation???????" mais à la lecture du journal, ben, pas de bol, c'est un utilisateur qui a fait une mauvaise manip (il veut pas le dire). mais cela est aussi utile pour vir l'action de nouveaux modules mis en place et ce qu'ils font.

Au niveau programmation, il faut s'astreindre bien évidemment à alimenter cette fameuse chaine afin qu'elle soit écrite par les triggers.

Voilà ce que je peux vous dire à ce sujet... et de mon expérience personnelle qui m'appartient à moi-même (rires)...

[WDKyle]

Personnellement j'utilise des fichiers txt, un pour chaque jour. Mais EDM-TAHITI à l'air d'utiliser une base de données (Hyperfile ?) pour gérer ses logs, n'est pas un peu risqué ? Si tu as un probleme avec ta base de données, tu n'auras pas de logs...

[cflo56]

J'utilise moi de mêmes des fichiers HyperFile pour mes logs...
Je passe par un composant qui es commun à mes projets et qui gère ses propres fichiers de données dont les logs... Tant que on prévoit tous les erreurs possibles lors d'un ajout d'une ligne dans le fichier logs, il ne devrait jamais avoir d'erreur HF lors de l'ajout d'un logs (le comble!).
Même lors de la lecture de l'analyse du programme si celui-ci échoue, l'ajout dans le fichier log se passe bien...

En gros si les deux fichiers (analyse) sont distincts il ne devrait y avoir aucun problème et quand même quel avantage d'avoir les fichiers logs en Hyperfile pour la lecture...

[EDM-TAHITI]

Hello,
Pour rebondir sur les propos de damien.c, oui, j'utilise un fichier hyperfile qui est inclus dans l'analyse (mais on peut le sortir).
Quant à avoir un problème avec la base de données, là, cela ne relève plus du log mais du niveau supérieur (manta planté, serveur planté, etc...) et je fais confiance à mes clients pour ne pas mettre plus d'1 minute pour m'appeler en me disant que tout est planté...
Miantenant, lors de l'initialisation du programme, j'ai un fichier de log qui me permet de savoir si la connexion s'est bien déroulé, si le changement de répertoire fichier s'est bien déroulé, bref, le truc basique. Mais quand il s'agit des log de programme proprement dit, alors, je préfére de loin un fichier HFCS que je peux interroger à distance et apporter, toujours à distance via des patchs, la résolution du problème.
Maintenant, chacun fait en fonction de ses affinités, et de ce qu'il croit être le mieux. Mais je pense honnêtement que toutes les solutions se valent, tout dépend après comment on souhaite l'exploiter.
Et je rejoins les propos de cflo56, c'est quand même sympa de pouvoir interroger les fichiers et les filtrer pour poser le doigt là ou ca fait mal (aie).
Mais comme je suis ouvert à tout, il se peut qu'un jour, je change, mais ce n'est pas d'actualité pour le moment.

[bejibe]

fichier HF pour moi aussi.

et vidage du fichier tous les x jours

[rednight]

Dans mon ancienne boite on stockait également ce qu'on appelait "l'historique utilisateur" en base de données à l'aide de procédures stockées, ça permettait de retracer chaque action de chaque utilisateur et éventuels plantages ou mauvaises manipulation.

Par contre ça a été un boulot monstre (en terme de temps) pour repasser partout dans le code et y ajouter l'appel de la procédure pour chaque "action utilisateur" pertinente ou sensible.

Au bout de quelques mois c'était devenus une usine à gaze, au final on à du restreindre au simple plantage car trop d'accès pour a la base de données Mysql. (environs 40 utilisateurs)

[mail.spam]

C'est aussi pour cela que j'aime bien le xml par programme.
Ainsi pas de surcharge d'accès à une base de donnée.

Ce qui est aussi valable que d'avoir un fichier HF par application.