Vous êtes sur le site Web historique de la documentation de 4D. Les documentations sont progressivement déplacées vers developer.4d.com

Accueil

 
4D v19
Description des fichiers d'historique

Description des fichiers d'historique  


 

 

Les applications 4D peuvent générer divers fichiers d'historique (logs) utiles pour le débogage ou l'optimisation de l'exécution des bases. Les fichiers d'historique sont généralement démarrés ou stoppés à l'aide des sélecteurs des commandes FIXER PARAMETRE BASE ou WEB FIXER OPTION et sont stockés dans le dossier Logs de la base (cf.section Description des fichiers de 4D).

Il est nécessaire d'analyser les informations enregistrées afin de pouvoir détecter et corriger les problèmes. Cette annexe fournit une description complète des fichiers suivants :

  • 4DRequestsLog.txt
  • 4DRequestsLog_ProcessInfo.txt
  • HTTPDebugLog.txt
  • 4DDebugLog.txt (standard et tabulaire)
  • 4DDiagnosticLog.txt,
  • 4DIMAPLog.txt, 4DPOP3Log.txt, et 4DSMTPLog.txt
  • Fichier d'historique des requêtes ORDA clientes

Note : Lorsqu'un fichier journal peut être généré soit sur 4D Server, soit sur le client distant, le mot "Server" est ajouté au nom du fichier journal côté serveur, par exemple "4DRequestsLogServer.txt".

Certains champs des fichiers sont communs afin de vous permettre de reconstituer la chronologie des événements et d'établir des connexions entre les entrées lors du débogage :

  • sequence_number : ce numéro est unique parmi tous les fichiers d'historique de débogage et est incrémenté à chaque nouvelle entrée, quel que soit le fichier d'historique, de manière à ce que vous puissiez connaître la séquence exacte des opérations.
  • connection_uuid : pour chaque process 4D créé sur un client 4D qui se connecte au serveur, cet UUID de connexion est stocké à la fois côté serveur et client. Il vous permet d'identifier facilement le client distant qui a lancé le process.

Ce fichier d'historique enregistre les requêtes standard effectuées par la machine 4D Server ou la machine 4D distante qui a exécuté la commande (à l'exclusion des requêtes Web).

Comment démarrer ce fichier d'historique :

  • sur le serveur :
     FIXER PARAMETRE BASE(Enreg requêtes 4D Server;1) //côté serveur
  • sur un client :
     FIXER PARAMETRE BASE(Enreg requêtes client;1) //côté distant

Note : Cette instruction génère aussi le fichier d'historique 4DRequestsLog_ProcessInfo.txt (voir ci-dessous).

En-têtes

Ce fichier commence par les en-têtes suivants :

  • Log Session Identifier (Identifiant de session d'historique)
  • Nom du serveur qui héberge l'application
  • User Login Name : Nom de l'utilisateur (défini dans l'OS) qui exécute l'application 4D sur le serveur.

Contenu du fichier

Pour chaque requête, les champs suivants sont enregistrés :

Nom du champDescription
sequence_numberNuméro d'opération séquentiel et unique dans la session d'historique
timeDate et heure au format ISO 8601 : 'YYYY-MM-DDTHH:MM:SS.mmm'
systemidID système
componentSignature du composant (par exemple '4SQLS' ou 'dbmg')
process_info_indexCorrespond au champ "index" dans le fichier d'historique 4DRequestsLog_ProcessInfo.txt, permettant de relier une requête à un process
requestID de requête en mode distant chaîne de message pour les requêtes SQL ou messages ENREGISTRER EVENEMENT
bytes_inNombre d'octets reçus
bytes_outNombre d'octets envoyés
server_duration | exec_duration Dépend de l'endroit où l'historique est généré :
  • server_duration lorsqu'il est généré sur le client --Temps en microsecondes pris par le serveur pour traiter la requête et retourner une réponse. Correspond au chemin B vers F dans l'image ci-dessous,
    OU,
  • exec_duration  lorsqu'il est généré sur le serveur --Temps en microsecondes pris par le serveur pour traiter la requête. Correspond au chemin B vers F dans l'image ci-dessous.
write_durationTemps en microsecondes pour envoyer :
  • La requête (lorsqu'elle est exécutée sur le client). Correspond au chemin A vers B dans l'image ci-dessous.
  • La réponse (lorsqu'elle est exécutée sur le serveur). Correspond au chemin E vers F dans l'image ci-dessous.
task_kindPréemptif ou coopératif (respectivement 'p' ou 'c')
rttTemps en microsecondes pris par  le client pour envoyer la requête et pour qu'elle soit reçue par le serveur. Correspond respectivement aux chemins A vers D et E vers H dans l'image ci-dessous.
  • Mesuré uniquement lorsque la couche réseau ServerNet est utilisée, retourne 0 lorsque l'ancienne couche réseau est utilisée.
  • Dans les versions antérieures à Windows 10 ou à Windows Server 2016, l'appel retournera la valeur 0.

Acheminement de la requête :

Ce fichier d'historique enregistre des informations sur chaque process créé sur la machine de 4D Server ou la machine 4D distante qui a exécuté la commande (à l'exclusion des requêtes Web).

Comment démarrer ce fichier d'historique :

  • sur le serveur :
     FIXER PARAMETRE BASE(Enreg requêtes 4D Server;1) //côté serveur
  • sur un client :
     FIXER PARAMETRE BASE(Enreg requêtes client;1) //côté distant

Note : Cette instruction génère aussi le fichier d'historique 4DRequestsLog.txt (voir ci-dessous).

En-têtes

Ce fichier commence par les en-têtes suivants :

  • Log Session Identifier (Identifiant de session d'historique)
  • Nom du serveur qui héberge l'application
  • User Login Name : Nom de l'utilisateur (défini dans l'OS) qui exécute l'application 4D sur le serveur.

Contenu du fichier

Pour chaque requête, les champs suivants sont enregistrés :

Nom du champDescription
sequence_numberNuméro d'opération séquentiel et unique dans la session d'historique
timeDate et heure au format ISO 8601 : "YYYY-MM-DDTHH:MM:SS.mmm"
process_info_indexNuméro de process séquentiel et unique
CDB4DBaseContextUUID du contexte de base du composant DB4D
systemidID système
server_process_idID du process sur le serveur
remote_process_idID du process sur le client
process_nameNom du process
cIDIdentifiant de la connexion 4D
uIDIdentifiant du client 4D
IPAddresse IPv4/IPv6 du client
host_nameNom d'hôte du client
user_nameNom de connexion utilisateur sur le client
connection_uuidIdentifiant UUID de process de connexion
server_process_unique_idID unique du process sur le serveur

Ce fichier d'historique enregistre chaque requête HTTP et chaque réponse en mode brut (raw). La totalité des requêtes, en-têtes compris, est enregistrée ; optionnellement, le corps (body) des requêtes peut également être enregistré.

Comment démarrer ce fichier d'historique :

 WEB FIXER OPTION(Web debug log;wdl activer sans body//d'autres valeurs sont disponibles

Les champs suivants sont enregistrés pour les requêtes et les réponses :

Nom du champDescription
SocketIDID de la socket utilisée pour la communication
PeerIPAdresse IPv4 de l'hôte (client)
PeerPortPort utilisé par l'hôte (client)
TimeStampHorodatage en millisecondes (depuis le démarrage du système)
ConnectionIDUUID de la connexion (UUID de la VTCPSocket utilisée pour la communication)
SequenceNumberNuméro d'opération séquentiel et unique dans la session d'historique

Ce fichier d'historique enregistre chaque événement généré au niveau du langage de 4D. Le mode standard propose une vue basique des événements.

Comment démarrer ce fichier d'historique :

 FIXER PARAMETRE BASE(Enregévénements debogage;2) //standard, tous les process
 FIXER PARAMETRE BASE(Enreg historique du process courant;2) //standard, process courant uniquement

Les champs suivants sont enregistrés pour chaque événement :  

ColonneDescription
1Numéro d'opération séquentiel et unique dans la session d'historique
2Date et heure au format ISO 8601 (YYYY-MM-DDThh:mm:ss.mmm)
3ID process (p=xx) et ID unique process (puid=xx)
4Niveau de stack
5Peut être Nom de commande / Nom de méthode / Message / Info Start Stop task / Nom, événement ou callback plugin / UUID connexion
6Durée de l'opération de connexion en millisecondes (différent 2e colonne)

Ce fichier d'historique enregistre chaque événement généré au niveau du langage de 4D. Le mode tabulaire est plus compact et contient davantage d'informations que le mode standard.

Comment démarrer ce fichier d'historique :

 FIXER PARAMETRE BASE(Enregévénements debogage;2+4) //format tabulaire étendu, tous les process
 FIXER PARAMETRE BASE(Enreg historique débogage du process courant;2+4) // étendu, process courant uniquement

Les champs suivants sont enregistrés pour chaque événement :  

ColonneNom du champDescription
1sequence_numberNuméro d'opération séquentiel et unique dans la session d'historique
2timeDate et heure au format ISO 8601 (YYYY-MM-DDThh:mm:ss.mmm)
3Process IDID du process
4unique_processIDID unique du process
5stack_levelNiveau de stack
6operation_typeType d'opération d'historique. Il peut s'agir d'une valeur absolue:
1: Commande
2: Méthode (méthode projeet, méthode base, etc.)
3: Message (envoyé par la commande ENREGISTRER EVENEMENT uniquement)
4: PluginMessage
5: PluginEvent
6: PluginCommand
7: PluginCallback
8: Process (Task)
9:Méthode membre (méthode rattachée à une collection ou à un objet)
Lors de la fermeture d'un niveau de pile, les colonnes operation_typeoperation et operation_parameters ont la même valeur que le niveau de pile d'ouverture enregistré dans la colonne stack_opening_sequence_number. Par exemple : 
121  15:16:50:777  5  8  1  2 CallMethod Parameters 0
122  15:16:50:777  5  8  2  1 283  0
123  15:16:50:777  5  8  2  1 283  0 122 3
124  15:16:50:777  5  8  1  2 CallMethod Parameters 0 121 61
Les 1ère et 2ème lignes ouvrent un niveau de pile, les 3ème et 4ème lignes ferment un niveau de pile. Les valeurs des colonnes 6, 7 et 8 sont répétées dans la ligne du niveau de pile de fermeture. La colonne 10 contient les numéros de séquence d'ouverture au niveau de la pile, c'est-à-dire 122 pour la 3ème ligne et 121 pour la 4ème.
7operationPeut représenter (en fonction du type d'opération) :
  • un ID de commande du langage (lorsque type=1)
  • un Nom de méthode (lorsque type=2)
  • une combinaison de pluginIndex;pluginCommand (lorsque type=4, 5, 6 ou 7). Peut contenir des éléments tels que '3;2'
  • un UUID de Task Connection (lorsque type=8)
  • 8operation_parametersParamètres passés aux commandes, méthodes ou aux plugins
    9form_eventEvénement formulaire, le cas échéant ; vide dans les autres cas (par conséquent cette colonne est utilisée lorsque le code est exécuté dans une méthode formulaire ou méthode objet)
    10Durée en micro secondes de l'action enregistrée courante ; uniquement pour les niveaux de femeture de stack (cf. 10e colonne des lignes 123 et 124 dans l'historique ci-dessus)

    Ce fichier journal enregistre de nombreux événements liés au fonctionnement interne de l'application et est lisible par l'homme. Vous pouvez inclure des informations personnalisées dans ce fichier à l'aide de la commande ENREGISTRER EVENEMENT.

    Pour démarrer ce journal :

     FIXER PARAMETRE BASE(Diagnostic log recording;1) //lancer l'enregistrement

    Les champs suivants sont enregistrés pour chaque événement :

    Nom des champsDescription
    sequenceNumberNuméro d'opération unique et séquentiel dans la session de journalisation
    timestampDate et heure au format ISO 8601 (YYYY-MM-DDThh:mm:ss.mmm)
    loggerIDOptionnel
    componentSignatureOptionnel - signature de composant interne
    messageLevelInfo, Attention, Erreur
    messageDescription de la saisie de journal

    En fonction de l'événement, d'autres champs peuvent également être enregistrés, tels que la tâche, la socket, etc.

    Ces fichiers d'historique enregistrent chaque échange entre l'application 4D et le serveur mail (SMTP, POP3, IMAP) initié par les commandes suivantes :


    Les fichiers d'historique peuvent être générés en deux versions : 

    • une version classique :
      • fichiers nommés 4DSMTPLog.txt, 4DPOP3Log.txt, ou 4DIMAPLog.txt
      • sans pièces jointes
      • avec un recyclage automatique tous les 10 MB
      • conçue pour des fonctions de débogage habituelles 

    Pour lancer cet historique :

      •  FIXER PARAMETRE BASE(SMTP Log;1) //lancer SMTP log OU
         FIXER PARAMETRE BASE(POP3 Log;1) //lancer POP3 log OU
         FIXER PARAMETRE BASE(IMAP Log;1) //lancer IMAP log

         
      • 4D Server : Cliquez sur le bouton Démarrer les journaux de requêtes et de débogage dans la Page Maintenance de la fenêtre d'administration de 4D Server. Ce chemin d'accès au journal est retourné par la commande [#cmd id="1418"​​/].
      • une version étendue : 
        • pièce(s) jointe(s) inclue(s)
        • sans recyclage automatique
        • nom personnalisé
        • conçue à des fins spécifiques 

    Pour lancer ce log :

        •  $server:=Creer objet
           ...
            //SMTP
           $server.logFile:="MySMTPAuthLog.txt"
           $transporter:=SMTP Creer transporteur($server)
           
            // POP3
           $server.logFile:="MyPOP3AuthLog.txt" 
           $transporter:=POP3 Creer transporteur($server)
           
            //IMAP
           $server.logFile:="MyIMAPAuthLog.txt"
           $transporter:=IMAP Creer transporteur($server)

    Contenu

    Pour chaque requête, les champs suivants sont enregistrés :

    Colonne #Description
    1Numéro d'opération unique et séquentiel dans la session d'enregistrement
    2Date et heure au format RFC3339 (yyyy-mm-ddThh:mm:ss.ms)
    3ID du Process 4D
    4ID unique du process
    5
    • Informations sur le lancement d'une session SMTP, POP3 ou IMAP, y compris le nom d'hôte du serveur, le numéro de port TCP utilisé pour se connecter au serveur SMTP, POP3 ou IMAP et l'état TLS,
      ou
    • données échangées entre le serveur et le client, en commençant par "S <" (données reçues depuis le serveur SMTP, POP3 ou IMAP) ou "C>" (données envoyées par le client IMAP) : liste des modes d'authentification envoyés par le serveur et mode d'authentification sélectionné, toute erreur signalée par le serveur SMTP, POP3 ou IMAP, les informations sur l'en-tête de l'e-mail envoyé (version standard uniquement) et si l'e-mail est sauvegardé sur le serveur,
      ou
    • les informations sur la clôture de la session IMAP.

    Ce fichier d'historique enregistre toutes les requêtes ORDA envoyées depuis une machine distante. Vous pouvez les envoyer à la mémoire ou à un fichier sur disque. Il vous revient de choisir le nom et l'emplacement de ce fichier d'historique. 

    Comment démarrer ce fichier d'historique :

      //à exécuter sur une machine distante
     ds.startRequestLog(Fichier("/PACKAGE/Logs/ordaLog.txt")) //peut aussi être envoyé à la mémoire

    Note : Si vous souhaitez utiliser une numérotation automatique unique dans le fichier d'historique ORDA, vous devez le lancer :

      //à exécuter sur une machine distante
     FIXER PARAMETRE BASE(Enreg requêtes client;1) //pour activer la numérotation automatique de l'historique
     ds.startRequestLog(Fichier("/PACKAGE/Logs/ordaLog.txt")) //peut aussi être envoyé à la mémoire
     FIXER PARAMETRE BASE(Enreg requêtes client;0) //désactive la numérotation automatique

    Les champs suivants sont enregistrés pour chaque requête :

    Nom du champDescriptionExemple
    sequenceNumberNuméro d'opération séquentiel et unique dans la session d'historique104
    urlURL de la requête ORDA effectuée par le poste client"rest/Persons(30001)"
    startTimeDate et heure de début au format ISO 8601"2019-05-28T08:25:12.346Z"
    endTimeDate et heure de fin au format ISO 8601"2019-05-28T08:25:12.371Z"
    durationDurée de traitement client (ms)25
    responseObjet réponse du serveur{"status":200,"body":{"__entityModel":"Persons",[...]

     
    PROPRIÉTÉS 

    Produit : 4D
    Thème : Fichiers d'historique d'aide au débogage
    Nom intl. : Description of log files

     
    PAGE CONTENTS 
     
    HISTORIQUE 

    New
    Modifié : 4D v17 R5
    Modifié : 4D v17 R6
    Modifié : 4D v18 R2
    Modifié : 4D v18 R3
    Modifié : 4D v19

     
    UTILISATION DE L'ARTICLE

    4D - Mode Développement ( 4D v19)