Exploitation des fichiers traces
Heure contenue dans les fichiers
Les heures contenues dans les traces ne correspondent pas à l’heure du serveur. L’heure est exprimée à partir de l’échelle de temps UTC (sans décalage).
Exemple : L’heure du serveur affiche 10h49 (UTC+2) et les traces sont enregistrées à 8h49.
Quels fichiers de traces analyser pour rechercher les causes d’un dysfonctionnement ?
Il est difficile d’apporter une réponse exhaustive à cette question. En fonction du problème, la recherche amène à activer différentes traces pour en comprendre l’origine.
Voici quelques exemples permettant de comprendre dans un premier temps :
Recherche pour une erreur survenue en impression au format état : Au minimum les traces du produit client et du serveur d’impression.
Recherche pour une erreur survenue en impression au format ticket : Au minimum les traces du produit Front-Office avec les traces CPOS.
Recherche pour une erreur survenue dans l’exécution d’une tâche planifiée : Au minimum les traces du TaskScheduler et du CGIMODE correspondant à la tâche planifiée (cgimode_XXXXX.log avec XXXXX correspondant au numéro de la tâche).
Recherche pour une erreur survenue dans l’application EFO ou EBO : Au minimum les traces du Front-Office et Back-Office accompagnées des traces du Serveur IIS Webapp.
Il est important de préciser l'heure exacte du problème à analyser en cas d'erreur reproduite sur la configuration client.
Notez qu'en fonction des premières analyses des traces, il peut s’avérer nécessaire de modifier le niveau des traces (cf. Niveau des traces) et de rejouer le scénario.
Ferme de serveurs IIS, de tâches ou d’impression
Il n’est pas possible de connaître le serveur IIS qui a traité la demande par l’intermédiaire du serveur ARR lorsque l’on recherche l’origine d’un message ou d’un comportement d’une application cliente.
Dans ce cas, il est nécessaire de chercher dans les traces sur chacun des serveurs IIS, les erreurs correspondantes au moment du message.
Pour la ferme de serveurs d’impression et de tâches, vous devez effectuer la même recherche.
Quels historiques de fichier transmettre ?
Il n’est pas nécessaire de transmettre tous les fichiers de traces ayant des jours d’historique. Par exemple, les traces par défaut du Cegidreportservice conservent un historique dans 5 fichiers d’une taille maximum de 20 Mo. Sauf demande expresse, il est préférable de transmettre le fichier dont la période correspond à l’erreur survenue.
Pour transmettre seulement les traces liées au scénario, vous pouvez :
Soit transmettre les fichiers contenant les traces correspondantes au jour et heure du problème rencontré.
Soit copier les fichiers de trace en cours dans un répertoire d’archive et jouer de nouveau le scénario permettant de reproduire le problème. Vous transmettez dans ce cas les derniers fichiers créés.
A l’aide d’un éditeur de texte, vous pouvez rechercher, dans les fichiers, les erreurs contenues à l’aide de la fonction de recherche en tapant : "ERR" (avec un espace avant et après).
Lien trace DELPHI et .NET remontées par la Webapp du serveur IIS
Dans certains cas, l’erreur contenue dans les traces clientes (Front-Office, Back-Office) provient d’une erreur lors du traitement de la demande par le serveur IIS. Dans ce cas, le détail de l’erreur est contenu dans les traces IIS de la Webapp. Le lien entre les traces clientes et les traces serveur se fait grâce à une référence identique entre les deux logs.
Exemple : Ceci est un exemple et vous permet de comprendre le lien entre deux fichiers log.
Message en validation d’une demande de transfert :
Extrait du log des traces de l’application Back-Office (eBOS5_SC.log) au moment du message
En recherchant le terme "ERR" le fichier de log au moment du message contient les informations suivantes :
Le fichier de traces contient notamment :
Ci-dessus, dans la partie encadrée en bleu est affiché le message adressé au client ; en amont de ce message une référence interne du serveur est affichée et contenue dans la partie encadrée en rouge. Grâce à cette référence, le fichier .log du serveur IIS de la Webapp peut contenir plus d’informations.
Extrait du log des traces de l’application Webapp du serveur IIS (WebApplication.Log) au moment du message
En recherchant la référence interne précédente dans ce fichier, nous obtenons les informations suivantes :
Notre cas concernait donc la validation d’un document pour lequel le numéro existait déjà dans la base de données.
Notez que dans les phases de tests d’une version, il est possible de remonter le détail de l’erreur au niveau des traces de l’application cliente.
Attention !
Dans ce cas, vous exposez le détail de l’erreur au poste client qui pourra être utilisée de manière malveillante. C’est pourquoi cette option ne s’active pas via une interface mais en modifiant manuellement le fichier. Il est fortement déconseillé de le faire dans le cas d’un environnement de production.