Aller au contenu principal
Version: 20

Description des fichiers d'historique

Les applications 4D peuvent générer divers fichiers journaux (ou "logs") qui sont utiles pour le débogage ou l'optimisation de leur exécution. Logs are usually started or stopped using selectors of the SET DATABASE PARAMETER, WEB SET OPTION, or HTTP SET OPTION commands and are stored in the Logs folder of the project.

Les informations stockées dans les journaux doivent être analysées pour détecter et corriger les problèmes. Cette section fournit une description complète des fichiers journaux suivants :

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 côté serveur, par exemple "4DRequestsLogServer.txt"

Les fichiers journaux partagent certains champs, ce qui vous permet d'établir une chronologie et de faire des connexions entre les entrées lors du débogage :

  • sequence_number : ce numéro est unique parmi tous les fichiers journaux de débogage et est incrémenté à chaque nouvelle entrée, quel que soit le fichier journal, 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.

4DRequestsLog.txt

Ce fichier de log enregistre les requêtes standard envoyées par la machine du 4D Server, ou la machine à distance qui a exécuté la commande (hors requêtes web).

Pour lancer ce journal :

  • sur le serveur :
SET DATABASE PARAMETER(4D Server log recording;1)
//côté serveur
  • sur le client :
SET DATABASE PARAMETER(Client Log Recording;1)
//côté distant

Cette instruction démarre également le fichier 4DRequestsLog_ProcessInfo.txt.

En-têtes

Ce fichier commence avec 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 a exécuté l'application 4D sur le serveur.

Contenu

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

Noms des champsDescription
sequence_numberNuméro d'opération séquentiel et unique dans la session de log
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" du journal 4DRequestsLog_ProcessInfo.txt, et permet de relier une demande à un process.
requestID de la requête C/S ou ORDA ou message pour les requêtes SQL ou messages LOG EVENT
bytes_inNombre d'octets reçus
bytes_outNombre d'octets envoyés
server_duration | exec_durationDé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.
  • extraInformations supplémentaires relatives au contexte, par exemple le nom de la dataclass et/ou le nom de l'attribut dans le cas d'une requête ORDA

    Acheminement de la requête :

    4DRequestsLog_ProcessInfo.txt

    Ce fichier de log enregistre des informations sur chaque process créé sur la machine du 4D Server, ou la machine à distance qui a exécuté la commande (requêtes web exclues).

    Pour lancer ce journal :

    • sur le serveur :
    SET DATABASE PARAMETER(4D Server log recording;1) //côté serveur
    • sur le client :
    SET DATABASE PARAMETER(Client Log Recording;1) //côté distant

    Cette déclaration démarre également l'historique du fichier 4DRequestsLog.txt.

    En-têtes

    Ce fichier commence avec 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 a exécuté l'application 4D sur le serveur.

    Contenu

    Pour chaque process, les champs suivants sont enregistrés :

    Noms des champsDescription
    sequence_numberNuméro d'opération séquentiel et unique dans la session de log
    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
    IP ClientAddresse 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

    HTTPDebugLog.txt

    Ce fichier journal enregistre chaque requête HTTP et chaque réponse en mode brut (raw). Les requêtes sont enregistrées dans leur totalité (en-têtes compris). Les parties body peuvent également être enregistrées.

    Pour lancer ce journal :




    WEB SET OPTION(Web debug log;wdl enable without body)
    //d'autres valeurs sont disponibles

    Les champs suivants sont enregistrés pour Requête et Réponse :

    Noms des champsDescription
    SocketIDID du socket utilisé 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)
    ConnectionIDConnexion UUID (UUID du VTCPSocket utilisé pour la communication)
    SequenceNumberNuméro d'opération séquentiel et unique dans la session de log

    4DHTTPClientLog.txt

    Ce fichier journal enregistre le trafic HTTP qui passe par le client HTTP 4D. Les requêtes sont enregistrées dans leur totalité (en-têtes compris). Les parties body peuvent optionnellement être enregistrées.

    Pour lancer ce journal :


    HTTP SET OPTION(HTTP client log; HTTP enable log with all body parts)
    //other values are available

    Les champs suivants sont enregistrés pour Requête et Réponse :

    Noms des champsDescription
    SequenceIDNuméro d'opération séquentiel et unique dans la session de log
    ConnectionIDIdentifiant UUID de process de connexion
    LocalIPAdresse IP du Client
    PeerIPAdresse IP du serveur
    TimeStampHorodatage (ms) de l'envoi de la requête ou de la réception entière de la réponse
    ElapsedTimeInMs(réponse uniquement) Différence avec l'horodatage de la requête

    En fonction des options de journalisation, d'autres champs peuvent également être enregistrés.

    • Pour la requête : ligne de requête, en-têtes, body de la requête
    • Pour la réponse : ligne de statut, en-têtes, body de réponse (décompressé), le cas échéant

    4DDebugLog.txt (standard)

    Ce fichier journal enregistre chaque évènement qui a lieu au niveau de la programmation 4D. Le mode standard offre une vue d'ensemble des évènements.

    Pour lancer ce journal :

    SET DATABASE PARAMETER(Debug Log Recording;2)  
    //standard, tous les process

    SET DATABASE PARAMETER(Current process debug log recording;2)
    //standard, process courant uniquement

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

    Colonne #Description
    1Numéro d'opération séquentiel et unique dans la session de log
    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 (pile)
    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)

    4DDebugLog.txt (tabulé)

    Ce fichier de logs enregistre chaque évènement au niveau de la programmation 4D sous un format compact avec des tabulations, qui inclut des informations supplémentaires par rapport au format standard.

    Pour lancer ce journal :

    SET DATABASE PARAMETER(Debug Log Recording;2+4)  
    //format tabulé étendu, tous les process

    SET DATABASE PARAMETER(Current process debug log recording;2+4)
    //étendu, process courant uniquement

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

    Colonne #Noms des champsDescription
    1sequence_numberNuméro d'opération séquentiel et unique dans la session de log
    2timeDate et heure au format ISO 8601 (YYYY-MM-DDThh:mm:ss.mmm)
    3ProcessIDID du process
    4unique_processIDID unique du process
    5stack_levelNiveau de stack (pile)
    6operation_typeType d'opération enregistrée. Il peut s'agir d'une valeur absolue :

    1. Command
    2. Méthode (méthode projet, méthode base, etc.)
    3. Message (envoyé par la commande LOG EVENT uniquement)
    4. PluginMessage
    5. PluginEvent
    6. PluginCommand
    7. PluginCallback
    8. Task (Process)
    9. Méthode membre (méthode attachée à une collection ou un objet)

    Lors de la fermeture d'un niveau de stack, les colonnes operation_type, operation et operation_parameters ont la même valeur que le niveau de stack d'ouverture enregistré dans la colonne stack_opening_sequence_number. Par exemple :

    1. 121 15:16:50:777 5 8 1 2 CallMethod Parameters 0
    2. 122 15:16:50:777 5 8 2 1 283 0
    3. 123 15:16:50:777 5 8 2 1 283 0 122 3
    4. 124 15:16:50:777 5 8 1 2 CallMethod Parameters 0 121 61

    Les 1re et 2e lignes ouvrent un niveau de stack, les 3e et 4e lignes ferment un niveau de stack. Les valeurs des colonnes 6, 7 et 8 sont répétées dans la ligne du niveau de stack de fermeture. La colonne 10 contient les numéros de séquence d'ouverture du niveau de stack, c'est-à-dire 122 pour la 3e ligne et 121 pour la 4e.
    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 connexion de process (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)
    10stack_opening_sequence_numberNiveaux de fermeture de stacks uniquement : numéro de séquence du niveau d'ouverture de stack correspondant
    11stack_level_execution_timeNiveaux de fermeture de stacks uniquement : Durée en micro secondes de l'action enregistrée courante (cf. 10e colonne des lignes 123 et 124 dans l'historique ci-dessus)

    4DDiagnosticLog.txt

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

    Pour lancer ce journal :

     SET DATABASE PARAMETER(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 séquentiel et unique dans la session de log
    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 task, socket, etc.

    Niveaux du journal de diagnostic

    Le fichier 4DDiagnosticLog.txt peut enregistrer différents niveaux de messages, de ERROR (le plus important) à TRACE (le moins important). Par défaut, le niveau INFO est défini, ce qui signifie que le fichier n'enregistre que les événements importants, y compris les erreurs et les résultats inattendus (voir ci-dessous).

    Vous pouvez sélectionner le niveau des messages à l'aide du sélecteur Diagnostic log level de la commande SET DATABASE PARAMETER, en fonction de vos besoins. Lorsque vous sélectionnez un niveau, les niveaux supérieurs (qui sont plus importants) sont implicitement sélectionnés également. Les niveaux suivants sont disponibles :

    ConstanteDescriptionLorsque sélectionné, inclut
    Log errorNuméro d'opération séquentiel et unique dans la session d'historiqueLog error
    Log warnDate et heure au format RFC3339 (yyyy-mm-ddThh:mm:ss.ms)Log error, Log warn
    Log infoID du Process 4DLog error, Log warn, Log info
    Log debugID unique du processLog error, Log warn, Log info, Log debug
    Log traceAutres informations internes (pour les services techniques de 4D)Log error, Log warn, Log info, Log debug, Log trace

    Voici un exemple :

    SET DATABASE PARAMETER (Diagnostic log recording; 1)
    SET DATABASE PARAMETER (Diagnostic log level; Log trace)

    4DSMTPLog.txt, 4DPOP3Log.txt, et 4DIMAPLog.txt

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

    Les fichiers 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 démarrer ce journal :

    SET DATABASE PARAMETER(SMTP Log;1) //start SMTP log
    SET DATABASE PARAMETER(POP3 Log;1) //start POP3 log
    SET DATABASE PARAMETER(IMAP Log;1) //start 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 Get 4D file.

    • une version étendue :
      • pièce(s) jointe(s) inclue(s) pas de recyclage automatique
      • nom personnalisé
      • réservée à des fins spécifiques

    Pour démarrer ce journal :

    $server:=New object
    ...
    //SMTP
    $server.logFile:="MySMTPAuthLog.txt"
    $transporter:=SMTP New transporter($server)

    // POP3
    $server.logFile:="MyPOP3AuthLog.txt"
    $transporter:=POP3 New transporter($server)

    //IMAP
    $server.logFile:="MyIMAPAuthLog.txt"
    $transporter:=IMAP New transporter($server)

    Contenu

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

    Colonne #Description
    1Numéro d'opération séquentiel et unique dans la session de log
    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.

    Requêtes ORDA

    Les journaux des requêtes ORDA peuvent enregistrer chaque requête ORDA et chaque réponse du serveur. Deux journaux de requêtes ORDA sont disponibles :

    • un journal des requêtes ORDA côté client, au format .txt
    • un journal des requêtes ORDA côté serveur, au format .jsonl

    Côté client

    Le journal ORDA côté client enregistre chaque requête ORDA envoyée depuis une machine distante. Vous pouvez diriger les informations du journal vers la mémoire ou vers un fichier .txt sur le disque de la machine distante. Vous pouvez choisir le nom et l'emplacement de ce fichier journal.

    Pour lancer ce journal :

        //on a remote machine
    SET DATABASE PARAMETER(Client Log Recording;1)
    ds.startRequestLog(File("/PACKAGE/Logs/ordaLog.txt"))
    //can be also sent to memory
    SET DATABASE PARAMETER(Client Log Recording;0)
    note

    Il n'est pas obligatoire de démarrer le fichier 4DRequestsLog.txt côté client à l'aide de SET DATABASE PARAMETER. Il est toutefois nécessaire si vous souhaitez enregistrer le champ unique sequenceNumber.

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

    Noms des champsDescriptionExemple
    sequenceNumberNuméro d'opération séquentiel et unique dans la session de log104
    urlURI de la requête"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 du traitement du client en millisecondes (ms)25
    responseObjet réponse du serveur{"status":200,"body":{"__entityModel":"Persons",[...]}}

    Exemple

    Voici un exemple d'enregistrement d'un fichier journal ORDA côté client :

        {
    "sequenceNumber": 7880,
    "url": "rest/Employees/$entityset/F910C2E4A2EE6B43BBEE74A0A4F68E5A/Salary?$compute='sum'&$progress4Dinfo='D0706F1E77D4F24985BE4DDE9FFA1739'",
    "startTime": "2023-05-15T10:43:39.400Z",
    "endTime": "2023-05-15T10:43:39.419Z",
    "duration": 19,
    "response": {
    "status": 200,
    "body": 75651
    }
    }

    Côté serveur

    Le journal ORDA côté serveur enregistre chaque requête ORDA traitée par le serveur, ainsi que la réponse du serveur (facultatif). Les informations du journal sont enregistrées dans un fichier .jsonl sur le disque de la machine serveur (par défaut, ordaRequests.jsonl).

    Pour lancer ce journal :

        //on the server
    SET DATABASE PARAMETER(4D Server log recording;1)
    ds.startRequestLog(File("/PACKAGE/Logs/ordaRequests.jsonl");srl log response without body)
    //srl... parameter is optional
    SET DATABASE PARAMETER(4D Server log recording;0)
    note

    Il n'est pas obligatoire de démarrer le fichier 4DRequestsLog.txt côté serveur à l'aide de SET DATABASE PARAMETER. Toutefois, il est nécessaire si vous souhaitez enregistrer les champs uniques sequenceNumber et duration.

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

    Noms des champsDescriptionExemple
    sequenceNumberNuméro d'opération séquentiel et unique dans la session de log104
    urlURI de la requête"rest/Persons(30001)"
    startTimeDate et heure de début au format ISO 8601"2019-05-28T08:25:12.346Z"
    durationDurée de traitement du serveur en microsecondes (µ)2500
    responseObjet de réponse du serveur, peut être configuré dans .startRequestLog(){"status":200,"body":{"__entityModel":"Persons",[...]}}
    ipAddressAdresse IP utilisateur"192.168.1.5"
    userNameNom de l'utilisateur 4D"henry"
    systemUserNameLogin de l'utilisateur sur la machine"hsmith"
    machineNameNom de la machine de l'utilisateur"PC de Henry Smith

    Exemple

    Voici un exemple d'enregistrement ORDA côté serveur :

       {
    "url": "rest/Employees/$entityset/F910C2E4A2EE6B43BBEE74A0A4F68E5A/Salary?$compute='sum'&$progress4Dinfo='D0706F1E77D4F24985BE4DDE9FFA1739'",
    "systemUserName": "Admin",
    "userName": "Designer",
    "machineName": "DESKTOP-QSK9738",
    "taskID": 5,
    "taskName": "P_1",
    "startTime": "2023-05-15T11:43:39.401",
    "response": {
    "status": 200,
    "body": 75651
    },
    "sequenceNumber": 7008,
    "duration": 240
    }

    Utilisation d'un fichier de configuration de log

    Vous pouvez utiliser un fichier de configuration de log pour gérer facilement l'enregistrement des journaux dans un environnement de production. Ce fichier est préconfiguré par le développeur. En général, il peut être envoyé aux clients pour qu'ils n'aient qu'à le sélectionner ou à le copier dans un dossier local. Une fois activé, le fichier de configuration de log déclenche l'enregistrement de journaux spécifiques.

    Activation du fichier

    Il existe plusieurs façons d'activer le fichier de configuration du journal, en fonction de votre configuration :

    • 4D Server avec interface : vous pouvez ouvrir la page Maintenance et cliquer sur le bouton Load logs configuration file, puis sélectionner le fichier. Dans ce cas, vous pouvez utiliser n'importe quel nom pour le fichier de configuration. Il est immédiatement activé sur le serveur.
    • un projet interprété ou compilé : le fichier doit être nommé logConfig.json et copié dans le dossier Settings du projet (situé au même niveau que le dossier Project). Il est activé au démarrage du projet (uniquement sur le serveur en client/serveur).
    • une application générée : le fichier doit être nommé logConfig.json et copié dans le dossier suivant :
      • Windows : Users\[userName]\AppData\Roaming\[application]
      • macOS : /Users/[userName]/Library/ApplicationSupport/[application]
    • tous projets avec un 4D monoposte ou distant : le fichier doit être nommé logConfig.json et copié dans le dossier suivant :
      • Windows: Users\[userName]\AppData\Roaming\4D
      • macOS: /Users/[userName]/Library/ApplicationSupport/4D
    • tous projets avec 4D Server : le fichier doit être nommé logConfig.json et copié dans le dossier suivant :
      • Windows: Users\[userName]\AppData\Roaming\4D Server
      • macOS: /Users/[userName]/Library/ApplicationSupport/4D Server
    note

    Si un fichier logConfig.json est installé à la fois dans les dossiers Settings et AppData/Library, le fichier du dossier Settings aura la priorité.

    Description du fichier JSON

    Le fichier de configuration du journal est un fichier .json qui doit respecter le schéma json suivant :

    {
    "$schema": "http://json-schema.org/draft-07/schema",
    "title": "Logs Configuration File",
    "description": "A file that controls the state of different types of logs in 4D clients and servers",
    "type": "object",
    "properties": {
    "forceConfiguration": {
    "description": "Forcing the logs configuration described in the file ingoring changes coming from code or user interface",
    "type": "boolean",
    "default": true
    },
    "requestLogs": {
    "description": "Configuration for request logs",
    "type": "object",
    "properties": {
    "clientState": {
    "description": "Enable/Disable client request logs (from 0 to N)",
    "type": "integer",
    "minimum": 0
    },
    "serverState": {
    "description": "Enable/Disable server request logs (from 0 to N)",
    "type": "integer",
    "minimum": 0
    }
    }
    },
    "debugLogs": {
    "description": "Configuration for debug logs",
    "type": "object",
    "properties": {
    "commandList": {
    "description": "Commands to log or not log",
    "type": "array",
    "items": {
    "type": "string"
    },
    "minItems": 1,
    "uniqueItems": true
    },
    "state": {
    "description": "integer to specify type of debuglog and options",

    "type": "integer",
    "minimum": 0
    }
    }
    },
    "diagnosticLogs":{
    "description": "Configuration for debug logs",
    "type": "object",
    "properties": {
    "state":{
    "description": "Enable/Disable diagnostic logs 0 or 1 (0 = do not record, 1 = record)",
    "type": "integer",
    "minimum": 0
    },
    "level": {
    "description": "Configure diagnostic logs",
    "type": "integer",
    "minimum": 2,
    "maximum": 6
    }
    }
    },
    "httpDebugLogs": {
    "description": "Configuration for http debug logs",
    "type": "object",
    "properties": {
    "level": {
    "description": "Configure http request logs",
    "type": "integer",
    "minimum": 0,
    "maximum": 7
    },
    "state": {
    "description": "Enable/Disable recording of web requests",
    "type": "integer",
    "minimum": 0,
    "maximum": 4
    }
    }
    },
    "POP3Logs": {
    "description": "Configuration for POP3 logs",
    "type": "object",
    "properties": {
    "state": {
    "description": "Enable/Disable POP3 logs (from 0 to N)",
    "type": "integer",
    "minimum": 0
    }
    }
    },
    "SMTPLogs": {
    "description": "Configuration for SMTP logs",
    "type": "object",
    "properties": {
    "state": {
    "description": "Enable/Disable SMTP log recording (form 0 to N)",
    "type": "integer",
    "minimum": 0
    }
    }
    },
    "IMAPLogs": {
    "description": "Configuration for IMAP logs",
    "type": "object",
    "properties": {
    "state": {
    "description": "Enable/Disable IMAP log recording (form 0 to N)",
    "type": "integer"
    }
    }
    },
    "ORDALogs": {
    "description": "Configuration for ORDA logs",
    "type": "object",
    "properties": {
    "state": {
    "description": "Enable/Disable ORDA logs (0 or 1)",
    "type": "integer"
    },
    "filename": {
    "type": "string"
    }
    }
    }
    }
    }

    Exemple

    Voici un exemple de fichier de configuration de log :

    {
    "forceLoggingConfiguration": false,
    "requestLogs": {
    "clientState": 1,
    "serverState": 1
    },
    "debugLogs": {
    "commandList":["322","311","112"],
    "state": 4
    },
    "diagnosticLogs":{
    "state" : 1
    },
    "httpDebugLogs": {
    "level": 5,
    "state" : 1
    },
    "POP3Logs": {
    "state" : 1
    },
    "SMTPLogs": {
    "state" : 1
    },
    "IMAPLogs": {
    "state" : 1
    },
    "ORDALogs": {
    "state" : 1,
    "filename": "ORDALog.txt"
    }
    }