Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

Chapitre 12. Le sous-système de journalisation

12.1. Introduction

12.1.1. Logging (Journalisation)

JBoss EAP 6 fournit des fonctionnalités de journalisation hautement configurables pour son propre usage et pour utilisation par des applications déployées. Le sous-système d'enregistrement est basé sur JBoss LogManager et prend en charge plusieurs frameworks de journalisation d'applications de tierce partie en plus du JBoss Logging.
Le sous-système de journalisation est configuré à l'aide d'un système de catégories de journaux et de gestionnaires de journaux. Les catégories de journalisation définissent quels messages capturer et les gestionnaires de journaux définissent comment procéder avec ces messages (écriture sur disque, envoyer à la console, etc.).
Le profils de journalisation permettent à des configurations de journalisation possédant un nom unique d'être créées et assignées à des applications indépendamment de toute autre configuration de journalisation. La configuration des profils de journalisation est presque identique pour le sous-système de journalisation principal.

12.1.2. Frameworks de journalisations d'applications pris en charge par JBoss LogManager

JBoss LogManager prend en charge les frameworks de journalisation suivants :

12.1.3. Journalisation Bootup

JBoss EAP consigne les entrées du démarrage de l'environnement d'exécution Java et du démarrage de chaque service. Ce journal peut être utile pour les dépannages. Par défaut, toutes les entrées de journal sont écrites dans le fichier server.log, dont l'emplacement dépendra du mode d'exécution.
Mode autonome
EAP_HOME/standalone/log/server.log
Mode de domaine
EAP_HOME/domain/servers/SERVER_NAME/log/server.log
La configuration de la journalisation de Bootup est indiquée dans le fichier de configuration logging.properties, et son emplacement dépend du mode d'exécution.
Mode autonome
EAP_HOME/standalone/configuration/logging.properties
Mode de domaine
En mode de domaine, il y a un fichier logging.properties pour le contrôleur de domaine et pour chaque serveur.
Contrôleur de domaine : EAP_HOME/domain/configuration/logging.properties
Serveur : EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
Le fichier de configuration logging.properties est actif jusqu'à ce que le sous-système de journalisation démarre et prenne la relève.

Avertissement

Il est conseillé de ne pas éditer le fichier logging.properties directement, à moins que vous connaissiez un cas d'utilisation particulier qui le requiert. Avant de procéder, on vous conseille de soumetter un dossier de prise en charge.
Les modifications apportées au fichier logging.properties sont remplacées au démarrage.

12.1.4. Voir les erreurs de démarrage initial (bootup)

Quand on tente de résoudre des problèmes dans JBoss EAP, on doit commencer par vérifier les erreurs survenues au cours du démarrage. Il existe deux méthodes d'affichage des erreurs de démarrage, chacune avec ses avantages. Chaque méthode produit une liste de toutes les erreurs qui se sont produites au cours du démarrage. Utilisez les informations fournies pour diagnostiquer et résoudre leurs causes. Contact Support client de Red Hat pour l'assistance en cas de problème.
  • Examiner le fichier journal server.log.
    Cette méthode vous permet de voir chaque message d'erreur et les messages liés dans certains cas, ce qui vous permet d'obtenir plus d'informations sur la raison pour laquelle une erreur a pu avoir lieu. Cela vous permet également de voir les erreur en format brut.
  • À partir de JBoss EAP 6.4, utiliser la commande d'interface de commande read-boot-errors.
    Cette méthode ne nécessite pas d'accès au système de fichiers du serveur, ce qui est bien utile pour toute personne responsable de contrôler les erreurs et qui n'a pas d'accès au système de fichiers. Comme il s'agit d'une commande d'interface CLI, elle peut être utilisée dans un script. Par exemple, vous pouvez écrire un script qui démarre par des instances multiples de JBoss EAP, puis vérifier les erreurs qui ont lieu au démarrage.

Procédure 12.1. Examiner server.log pour chercher les erreurs

  1. Ouvrir le fichier server.log dans une visionneuse de fichiers.
  2. Déplacez-vous en fin de fichier.
  3. Rechercher l'identifiant du message JBAS015899 rétroactivement, qui indique le début de la dernière séquence de démarrage.
  4. Chercher les instances d'ERROR à partir de cet endroit dans le journal. Chaque instance devra inclure une description de d'erreur et la liste des modules concernés.

Exemple 12.1. Description de l'erreur de server.log

Ce qui suit est un exemple de description d'erreur du fichier journal server.log.
13:23:14,281 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) JBWEB003043: Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080

Procédure 12.2. Lister les erreurs de démarrage par l'interface CLI

  • Exécuter la commande d'interface CLI suivante :
    /core-service=management:read-boot-errors
    Toute erreur qui a lieu lors du démarrage sera listée à cet endroit.
    L'heure de chaque erreur est définie par la méthode currentTimeMillis(), qui correspond à la différence, mesurée en millisecondes, entre l'heure actuelle et minuit le 1er janvier 1970 UTC.

Exemple 12.2. Sortie de la commande read-boot-errors

{
"outcome" => "success",
"result" => [{
    "failed-operation" => {
        "operation" => "add",
        "address" => [
            ("subsystem" => "web"),
            ("connector" => "http")
        ]
    },
    "failure-timestamp" => 1417560953245L,
    "failure-description" => "{\"JBAS014671: Failed services\" => {\"jboss.web.connector.http\" => \"org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed\"}}",
    "failed-services" => {"jboss.web.connector.http" => "org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed"}
}]
}

12.1.5. Journalisation de Garbage collection

La journalisation de Garbage collection consigne toutes les activités de collecte de la poubelle dans les fichiers journaux en texte clair. Ces fichiers journaux peuvent être utiles à des fins de diagnostique. À partir de JBoss EAP 6, la journalisation de la Garbage collection est activée par défaut en mode standalone (autonome) sur toutes les configurations prises en charge sauf JDK d'IBM.
La journalisation correspond à la sortie du fichier $EAP_HOME/standalone/log/gc.log.digit. La rotation de la journalisation est activée, avec un nombre de fichiers de journalisation ne devant pas dépasser cinq, et une taille de trois MiB maximum par fichier.

12.1.6. Dépendances d'API de journalisation implicites

Le sous-système de journalisation de JBoss EAP 6 possède un attribut add-logging-api-dependencies qui contrôle la possibilité pour le conteneur d'ajouter des dépendances d'API de journalisation implicites aux déploiements. Par défaut, cet attribut est défini à true, ce qui signifie que toutes les dépendances d'API de journalisation implicites doivent être ajoutées aux déploiements. Si défini sur false, les dépendances d'API de journalisation se seront pas ajoutées.
L'attribut add-logging-api-dependencies peut être configuré par l'interface CLI. Par exemple :
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

12.1.7. Emplacements de fichiers de journalisation par défaut

Il s'agit des fichiers de journalisation qui ont été créés pour les configurations de journalisation par défaut. La configuration par défaut écrit des fichiers de journalisation du serveur à l'aide de gestionnaires de journaux périodiques.

Tableau 12.1. Fichier de journalisation par défaut d'un serveur autonome

Fichier journal Description
EAP_HOME/standalone/log/server.log
Journal du serveur. Contient les messages de journalisation de serveur, dont les messages de démarrage de serveur.
EAP_HOME/standalone/log/gc.log
Journalisation de Garbage collection. Contient des informations sur tous les nettoyages de mémoire.

Tableau 12.2. Fichiers de journalisation par défaut d'un domaine géré

Fichier journal Description
EAP_HOME/domain/log/host-controller.log
Journal d'amorçage du contrôleur hôte. Contient les messages de journalisation liés au démarrage du contrôleur hôte.
EAP_HOME/domain/log/process-controller.log
Journal d'amorçage du contrôleur de processus. Contient les messages de journalisation liés au démarrage du contrôleur de processus.
EAP_HOME/domain/servers/SERVERNAME/log/server.log
Le journal du serveur pour le serveur nommé. Contient les messages de journalisation de ce serveur, dont les messages de démarrage de serveur.

12.1.8. Filtre les expressions de journalisation

Les expressions de filtrage sont utilisées pour enregistrer les messages de journalisation sur la base d'un certain nombre de critères. Le contrôle de filtrage est toujours effectué sur un message brut non formaté. Vous pouvez inclure un filtre de logger ou de gestionnaire, mais le filtre du logger aura la priorité sur le filtre du gestionnaire.

Note

Un filter-spec spécifié pour le root logger n'est pas hérité par les autres loggers. Au lieu de cela, un filter-spec devra être spécifié pour chaque gestionnaire.

Tableau 12.3. Filtre les expressions de journalisation

Type de filtre
expression
Description Paramètres
Accepter
accept
Accepter tous les messages de journalisation
accept
Refuser
deny
Refuser tous les messages de journalisation
deny
Not
not[filter expression]
Renvoie la valeur inversée de l'expression du filtre
Prend une expression de filtre unique comme paramètre
not(match("JBAS"))
Tout
all[filter expression]
Renvoie la valeur concaténée à partir de multiples expressions de filtre.
Prends plusieurs expressions de filtre séparées par des virgules
all(match("JBAS"),match("WELD"))
Tous
any[filter expression]
Renvoie une valeur à partir de multiples expressions de filtre.
Prends plusieurs expressions de filtre séparées par des virgules
any(match("JBAS"),match("WELD"))
Changement de niveau
levelChange[level]
Modifie l'enregistrement de journalisation avec le niveau indiqué
Prend un niveau basé chaîne unique comme argument
levelChange("WARN")
Niveaux
levels[levels]
Filtre les messages de journalisation avec un niveau apparaissant sur la liste des niveaux
Prend plusieurs niveaux basés chaînes séparées par des virgules en tant qu'arguments
levels("DEBUG","INFO","WARN","ERROR")
Gamme de niveaux
levelRange[minLevel,maxLevel]
Filtre les messages de journalisation dans la gamme de niveaux spécifiée.
L'expression de filtre utilise [ pour indiquer un niveau inclusif minimum et ] pour indiquer un niveau inclusif maximum. Sinon, vous pouvez utiliser ( ou ) respectivement pour indiquer une exclusivité. Le premier argument de l'expression est le niveau minimum autorisé, le deuxième argument est le niveau maximum autorisé.
Voici des exemples ci-dessous.
  • levelRange("DEBUG","ERROR")
    Le niveau minimum doit être supérieur à DEBUG et le niveau maximum doit être inférieur à ERROR.
  • levelRange["DEBUG","ERROR")
    Le niveau minimum doit être supérieur ou égal à DEBUG et le niveau maximum doit être inférieur à ERROR.
  • levelRange["INFO","ERROR"]
    Le niveau minimum doit être supérieur ou égal à INFO et le niveau maximum doit être inférieur ou égal à ERROR.
Match (match["pattern"]) Filtre basé sur une expression régulière. Le message non formaté est utilisé à l'encontre du modèle spécifié dans l'expression.
Prend une expression régulière comme argument
match("JBAS\d+")
Substitute (substitute["pattern","replacement value"]) Filtre qui remplace la première correspondance au modèle par une valeur de remplacement
Le premier argument de l'expression est le modèle, le deuxième est le texte de remplacement.
substitute("JBAS","EAP")
Remplacer tout (substituteAll["pattern","replacement value"]) Un filtre qui remplace toutes les correspondances du modèle avec la valeur de remplacement.
Le premier argument de l'expression est le modèle, le deuxième est le texte de remplacement.
substituteAll("JBAS","EAP")

12.1.9. Niveaux de journalisation

Les niveaux de journalisation sont des ensembles ordonnés de valeurs énumérées qui indiquent la nature et la sévérité d'un message de journalisation. Le niveau d'un message de journalisation donné est indiqué par le développeur par des méthodes qui conviennent dans un framework de journalisation particulier pour envoyer le message.
JBoss EAP 6 accepte tous les niveaux de journalisation utilisés par les frameworks de journalisation de l'application prise en charge. Les six niveaux de journalisation les plus utilisés sont (dans l'ordre croissant) : TRACE, DEBOG, INFO, ATTENTION, ERREUR et FATAL.
Les niveaux de journalisation sont utilisés par des catégories et des gestionnaires de journalisation pour limiter les messages dont ils sont responsables. Chaque niveau de journalisation possède une valeur numérique qui indique son ordre par rapport à d'autres niveaux de journalisation. Les catégories et gestionnaires de journalisation correspondent à un certain niveau de journalisation, et ils traitent les messages de journalisation du même niveau ou d'un niveau supérieur uniquement. Par exemple, un gestionnaire de journalisation du niveau ATTENTION enregistrera uniquement les messages des niveaux ATTENTION, ERREUR et FATAL.

12.1.10. Niveaux de journalisation pris en charge

Tableau 12.4. Niveaux de journalisation pris en charge

Niveau de journalisation Valeur Description
FINESSE MAX 300
-
PLUS FIN 400
-
TRACE 400
Utilisé pour des messages qui fournissent des informations détaillées sur l'état d'exécution d'une application. Les messages de journalisation TRACE sont habituellement capturés uniquement lors du débogage d'une application.
DEBOG 500
Utilisé pour des messages qui indiquent des demandes individuelles de progrès ou des activités d'une application. Les messages de journalisation DEBUG ne sont habituellement capturés que lors du débogage d'une application.
FINESSE 500
-
CONFIG 700
-
INFO 800
Utilisé pour des messages qui indiquent la progression globale de l'application. Souvent utilisé pour le démarrage de l'application, la fermeture et autres événements majeurs de cycle de vie.
AVERTISSEMENT 900
Utilisé pour indiquer une situation qui n'est pas en erreur, mais n'est pas considérée comme idéale. Peut indiquer des circonstances qui peuvent entraîner des erreurs dans le futur.
ATTENTION 900
-
ERREUR 1000
Utiliser pour indiquer une erreur qui s'est produite et qui puisse empêcher l'activité actuelle ou la demande de se remplir, mais qui n'empêchera pas l'application d'exécuter.
SÉVÈRE 1000
-
FATALE 1100
Utiliser pour indiquer les événements qui pourraient entraîner des défaillances de services critiques ou la fermeture de l'application, ou qui pourraient entraîner la fermeture de la plateforme JBoss EAP 6.

12.1.11. Catégories de journalisation

Les catégories de journalisation définissent les messages de journalisation à acquérir et un ou plusieurs gestionnaires de journalisation qui traitent les messages.
Les messages de journalisation à capturer sont définis par leur package Java d'origine et leur niveau de journalisation. Les messages de classes de ce package et de niveau de journalisation ou niveau inférieur sont capturés par la catégorie de journalisation et envoyés aux gestionnaires de journal spécifiés.
Les catégories ont la possibilité d'utiliser les gestionnaires de journalisation du root logger au lieu de leurs propres gestionnaires.

12.1.12. Root Logger

Le root logger capture tous les messages de journalisation qui sont envoyés au serveur (à un niveau indiqué) et qui ne sont pas capturés par une catégorie de journalisation particulière. Ces messages sont alors envoyés à un ou à plusieurs gestionnaires de journalisation.
Par défaut, le root logger est configuré pour utiliser une console et un gestionnaire de journalisation périodique. Le gestionnaire de journalisation périodique est configuré pour écrire sur le ficher server.log. On prénomme parfois ce fichier : journal du serveur (server log).

12.1.13. Gestionnaires de journaux

Les gestionnaires de journaux définissent la façon dont les messages de journalisation sont enregistrés dans JBoss EAP. Voici la liste des gestionnaires de journalisation : Console, File, Periodic, Size, Async, syslog, Periodic Size et Custom.

Note

Un gestionnaire de journaux doit être ajouté à un logger au moins pour être actif.

12.1.14. Types de gestionnaires de journalisation

Console
Les gestionnaires de journaux de console écrivent des messages de journalisation soit dans le système d'exploitation hôte (stdout) ou dans le flux d'erreurs standard (stderr). Ces messages sont affichés lorsque JBoss EAP 6 est exécuté à partir d'une invite de ligne de commande. Les messages d'un gestionnaire de journal de Console ne sont pas enregistrés à moins que le système d'exploitation ne soit spécifiquement configuré pour capturer stdout ou stderr.
Fichier
Les gestionnaires de journaux de fichiers inscrivent des messages de journalisation dans un fichier spécifique.
Périodique
Les gestionnaires de journaux périodiques écrivent des messages de journalisation dans un fichier nommé jusqu'à ce qu'une certaine durée se soit écoulée. Une fois que cette période a expiré, le fichier est nommé à nouveau en rajoutant l'horodatage et le gestionnaire continue d'écrire dans un fichier de journalisation nouvellement créé avec le nom d'origine.
Taille
Les gestionnaires de journaux de Taille écrivent les messages de journalisation dans un fichier jusqu'à ce que le fichier atteigne une taille spécifiée. Lorsque le fichier atteint une taille donnée, il est renommé avec un suffixe numérique et le gestionnaire continue d'écrire dans un fichier journal récemment créé avec le nom d'origine. Chaque gestionnaire de journaux de Taille doit spécifier le nombre maximal de fichiers contenus de cette façon.
Taille périodique
Disponible à partir de JBoss EAP 6.4. Correspond à une combinaison de gestionnaires Périodiques et de Taille, et prend en charge leurs attributs combinés.
Une fois que le fichier de journalisation a attteint une taille donnée, ou que la période donné a expiré, le fichier est nommé à nouveau en rajoutant l'horodatage et le gestionnaire continue d'écrire dans un fichier de journalisation nouvellement créé avec le nom d'origine.
Async
Les gestionnaires de journaux async sont des gestionnaires de journaux wrapper qui fournissent un comportement asynchrone pour un ou plusieurs autres gestionnaires de journaux. Ils sont utiles pour les gestionnaires de journaux qui pourraient avoir une latence élevée ou autres problèmes de performances comme l'écriture d'un fichier journal à un système de fichiers réseau.
Personnalisé
Les gestionnaires d'informations personnalisées vous permettent de configurer de nouveaux types de gestionnaires de journaux mis en place. Un gestionnaire personnalisé doit être implémenté comme classe Java qui s'étend java.util.logging.Handler et doit être contenu dans un module.
syslog
Les gestionnaires de syslog peuvent être utilisés pour envoyer des messages à un serveur de journalisation à distance. Cela permet à plusieurs applications d'envoyer leurs messages de journalisation au même serveur, où ils peuvent être analysés en même temps.

12.1.15. Log Formatters

Un formateur de journalisation (log formatter) est une propriété de configuration d'un gestionnaire de journalisation qui détermine l'apparence des messages de journalisation. Il s'agit d'un string qui utilise une syntaxe basée sur la classe java.util.Formatter.
Ainsi, le string du formateur de journalisation de la configuration par défaut, %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n, crée des messages de journalisation qui ressemblent à ceci :
15:53:26,546 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990

12.1.16. Syntaxe de Formateur de journaux

Tableau 12.5. Syntaxe de Formateur de journaux

Symbole Description
%c La catégorie de l'événement de journalisation
%p Le niveau de saisie de la journalisation (info/déboggage/etc)
%P Le niveau localisé de la saisie de journalisation
%d Les date/heure (yyyy-MM-dd HH:mm:ss,SSS form)
%r L'heure relative (en millisecondes depuis l'initialisation de la journalisation)
%z Le réseau horaire
%k Une clé de ressource de journalisation (utilisée pour la localisation de messages de journalisation)
%m Le message de journalisation (avec trace d'exception)
%s Le simple message de journalisation (sans trace d'exception)
%e Suivi de la pile d'exceptions (sans informations sur les modules étendus)
%E Suivi de la pile d'exceptions (avec informations sur les modules étendus)
%t Le nom du thread en cours
%n Un caractère de nouvelle ligne
%C La classe du code appelant la méthode de journalisation (lente)
%F Le nom de fichier de la classe appelant la méthode de journalisation (lente)
%l L'emplacement d'origine du code appelant la méthode de journalisation (lente)
%L Le numéro de ligne du code appelant la méthode de journalisation (lente)
%M La méthode du code appelant la méthode de journalisation (lente)
%x Contexte de diagnostique intégré
%X Contexte de diagnostique du message
%% Un pourcentage (caractère d'échappement)