Vue d’ensemble de la journalisation système
SUMMARY Cette section décrit les messages du journal système qui identifient le processus Junos OS responsable de la génération du message et fournit une brève description de l’opération ou de l’erreur qui s’est produite.
Vue d’ensemble du journal système
Junos OS génère des messages de journal système (également appelés messages syslog) pour enregistrer les événements qui se produisent sur le périphérique, notamment les suivants :
-
Opérations de routine, telles que la création d’une adjacence de protocole Open Shortest Path First (OSPF) ou une connexion utilisateur à la base de données de configuration.
-
Conditions de défaillance et d’erreur, telles que l’échec d’accès à un fichier de configuration ou la fermeture inattendue d’une connexion à un processus homologue.
-
Conditions d’urgence ou critiques, telles que la mise hors tension de l’appareil en raison d’une température excessive.
Chaque message du journal système identifie le processus Junos OS responsable de la génération du message et fournit une brève description de l’opération ou de l’erreur qui s’est produite. Pour plus d’informations sur des messages de journal système spécifiques, reportez-vous à l’Explorateur de journaux système.
Pour configurer l’appareil afin qu’il consigne les messages système, configurez l’instruction syslog au niveau hiérarchique [modifier le système].
Dans Junos OS version 17.3R1, le démon syslog-event gère le fxp0 dans l’instance de routage de gestion dédiée pour l’hôte distant adressé IPv4. Dans Junos OS version 18.1R1, le démon syslog-event prend en charge la configuration IPv6 lors de la connexion à un hôte distant ou à un site d’archivage et fxp0 est déplacé vers une instance de gestion dédiée. Dans Junos OS version 18.4R1, le client syslog peut envoyer des messages via n’importe quelle instance de routage que vous définissez au niveau des hiérarchies appropriées. Voir routing-instance (Syslog).
Cette rubrique décrit les messages de journal système pour les processus et bibliothèques Junos OS et non les services de journalisation système sur une carte d’interface physique (PIC) telle que le PIC Adaptive Services.
Dans Junos OS Evolved, chaque nud dispose de l’outil standard journalctl
, qui est une interface permettant de récupérer et de filtrer le journal système. Les messages du journal système sont extraits du journal système. Le relay-eventd
processus s’exécute sur tous les noeuds et récupère les événements (en fonction de la configuration syslog) du journal système ainsi que les messages d’erreur des différentes applications et les transmet au master-eventd
processus. Le master-eventd
processus s’exécute sur le moteur de routage principal et écrit les messages de journal et les erreurs sur le disque.
Utilisez l’application Explorateur de journaux système pour afficher ou comparer les messages de journaux système dans différentes versions.
Dans Junos OS Evolved, il n’y a pas messages
de fichier sur le moteur de routage de sauvegarde. Tous les journaux de sauvegarde du moteur de routage se trouvent dans le fichier sur le messages
nœud principal du moteur de routage.
Par défaut, Junos OS Evolved ajoute le nom de nœud au nom d’hôte dans les messages du journal système. Ce n’est pas le cas de Junos OS. Cette action permet de maintenir Junos OS messages du journal système Evolved conformes à RFC5424. Toutefois, certains systèmes de surveillance peuvent ne pas identifier correctement un nom d’hôte Junos OS Evolved, car la combinaison nom d’hôte-nom de nœud ne correspond à aucun nom d’hôte dans l’inventaire des noms d’hôte.
À partir de Junos OS Evolved version 20.4R2, pour garantir une identification précise des noms d’hôte Junos OS Evolved dans votre système de surveillance, utilisez la set system syslog alternate-format
commande configuration mode. Cette commande modifie le format des messages du journal système de Junos OS Evolved. Le nom du nœud est ajouté au nom du processus dans le message plutôt que d’être ajouté au nom d’hôte, ce qui permet au système de surveillance d’identifier correctement le nom d’hôte.
Par exemple, les messages du journal système de Junos OS n’impriment pas le processus d’origine dans les messages du journal système provenant d’un FPC :
user@mxhost> show log messages Dec 19 13:22:41.959 mxhost chassisd[5290]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(0) Dec 19 13:23:22.900 mxhost fpc2 Ukern event counter Sock_tx init delayed
Toutefois, les messages Junos OS Evolved ajoutent le nom de nœud au nom d’hôte et impriment le processus d’origine des messages provenant d’un nud, y compris les FPC :
user@ptxhost-re0> show log messages May 25 18:41:05.375 ptxhost-re0 mgd[16201]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dot1xd', PID 21322, status 0 May 25 18:42:34.632 ptxhost-fpc0 evo-cda-bt[14299]: Register bt.igp_misc.debug.hdr_length_cnt not found May 25 18:42:34.753 ptxhost-fpc1 evo-cda-bt[14427]: HBM: hbm_gf_register_inst May 25 18:47:14.498 ptxhost-re0 ehmd[5598]: SYSTEM_APP_READY: App is ready re0-ehmd
Si vous avez configuré le format alternatif pour les messages de journal système de Junos OS Evolved, le même ensemble de messages de journal système ressemblera à ceci à la place, avec le nom d’hôte seul :
user@ptxhost-re0> show log messages May 25 18:41:05.375 ptxhost re0- mgd[16201]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dot1xd', PID 21322, status 0 May 25 18:42:34.632 ptxhost fpc0- evo-cda-bt[14299]: Register bt.igp_misc.debug.hdr_length_cnt not found May 25 18:42:34.753 ptxhost fpc1- evo-cda-bt[14427]: HBM: hbm_gf_register_inst May 25 18:47:14.498 ptxhost re0- ehmd[5598]: SYSTEM_APP_READY: App is ready re0-ehmd
À partir de Junos OS version 22.1R1 sur les appareils SRX Series et NFX Series et Junos OS version 22.2R1 d’Evolved sur les appareils QFX5130, QFX5200, QFX5220 et QFX5700, nous avons ajouté plusieurs événements à l’intérieur de la balise d’événement en utilisant le <event>UI_LOGIN_EVENT|UI_LOGOUT_EVENT</event>
format, qui dispose d’une option (|
) pour séparer les événements et générer des messages de journal système. Antérieurement à ces versions, la balise d’événement utilisait le <event>UI_LOGIN_EVENT UI_LOGOUT_EVENT</event>
format et pour diverses combinaisons de <get-syslog-events> rpc
filtres, elle n’était pas enregistrée.
Fonctions de journalisation système et niveaux de gravité des messages
Tableau 1 répertorie les fonctions de journalisation système de Junos OS que vous pouvez spécifier dans les instructions de configuration au niveau hiérarchique [edit system syslog]
.
Facilité (nombre) |
Type d’événement ou d’erreur |
---|---|
|
Le noyau Junos OS effectue des actions et rencontre des erreurs. |
|
Espace utilisateur effectuer des actions ou rencontrer des erreurs. |
|
Le système effectue des actions ou rencontre des erreurs. |
|
Tentatives d’authentification et d’autorisation. |
|
FTP effectue des actions ou rencontre des erreurs. |
|
Network Time Protocol effectue des actions ou rencontre des erreurs. |
|
Événements ou erreurs liés à la sécurité. |
|
Événements liés à la capture de flux dynamique. |
|
Les applications externes locales effectuent des actions ou rencontrent des erreurs. |
|
Le filtre de pare-feu effectue des actions de filtrage de paquets. |
|
Le moteur de transfert de paquets effectue des actions ou rencontre des erreurs. |
|
La configuration spécifiée n’est pas valide sur le type de routeur. |
|
Modifications apportées à la configuration de Junos OS. |
|
Une application cliente, telle qu’un protocole Junos XML ou un client XML NETCONF, émet des commandes à l’invite de l’interface de ligne de commande (CLI) de Junos OS. |
Tableau 2 Répertorie les niveaux de gravité que vous pouvez spécifier dans les instructions de configuration au niveau de la [edit system syslog]
hiérarchie. Les niveaux de à travers sont dans l’ordre de la gravité la plus élevée (effet le plus important sur le emergency
fonctionnement) à info
la plus faible.
Contrairement aux autres niveaux de gravité, le niveau désactive la journalisation d’une ressource au lieu d’indiquer la none
gravité de l’impact d’un événement déclencheur sur les fonctions de routage. Pour plus d’informations, reportez-vous à la section Désactivation de la journalisation système d’une installation.
Valeur |
Niveau de gravité |
Description |
---|---|---|
N/A |
|
Désactive la journalisation de la ressource associée vers une destination. |
0 |
|
Panique du système ou autre condition entraînant l’arrêt du routeur de fonctionner. |
1 |
|
Conditions nécessitant une correction immédiate, par exemple une base de données système corrompue. |
2 |
|
Les conditions critiques, telles que les erreurs matérielles. |
3 |
|
Conditions d’erreur qui ont généralement des conséquences moins graves que les erreurs aux niveaux d’urgence, d’alerte et critique. |
4 |
|
Des conditions qui justifient une surveillance. |
5 |
|
Des conditions qui ne sont pas des erreurs mais qui peuvent justifier un traitement particulier. |
6 |
|
Événements ou conditions de non-erreur d’intérêt. |
7 |
|
Inclut tous les niveaux de gravité. |
Paramètres du journal système par défaut
Tableau 3 résume les paramètres de journal système par défaut qui s’appliquent à tous les routeurs exécutant Junos OS et spécifie l’instruction à inclure dans la configuration pour remplacer la valeur par défaut.
Réglage |
Par défaut |
Déclaration prioritaire |
Instructions |
---|---|---|---|
Autre fonction pour le transfert du message vers une machine distante |
Pour Pour Pour Pour Pour Pour |
[edit system syslog] host hostname { facility-override facility; } |
|
Format des messages consignés dans un fichier |
Format Junos OS standard, basé sur le format UNIX |
[edit system syslog] file filename { structured-data; } |
|
Nombre maximal de fichiers dans l’ensemble archivé |
10 |
[edit system syslog] archive { files number; } file filename { archive { files number; } } |
Spécification de la taille, du nombre et des propriétés d’archivage du fichier journal |
Taille maximale du fichier journal |
M Series, MX Series et T Series : 1 mégaoctet (Mo) Matrice TX : 10 Mo |
[edit system syslog] archive { size size; } file filename { archive { size size; } } |
Spécification de la taille, du nombre et des propriétés d’archivage du fichier journal |
Format d’horodatage |
Mois, date, heure, minute, seconde Par exemple : |
[edit system syslog] time-format format; |
|
Utilisateurs capables de lire les fichiers journaux |
|
[edit system syslog] archive { world-readable; } file filename { archive { world-readable; } } |
Spécification de la taille, du nombre et des propriétés d’archivage du fichier journal |
Messages de journal système par défaut spécifiques à la plate-forme
Les messages suivants sont générés par défaut sur des routeurs spécifiques. Pour afficher ces types de messages, vous devez configurer au moins une destination pour les messages, comme décrit dans Configuration minimale de journalisation système de Junos OS.
Pour consigner le message du processus du noyau sur un routeur M Series, MX Series ou T Series, incluez l’instruction
kernel info
au niveau hiérarchique approprié :[edit system syslog] (console | file filename | host destination | user username) { kernel info; }
Sur une matrice de routage composée d’un routeur TX Matrix et de routeurs T640, le moteur de routage principal de chaque routeur T640 transfère tous les messages dont la gravité est égale
info
ou supérieure au moteur de routage principal sur le routeur TX Matrix. Ceci est équivalent à l’instruction de configuration suivante incluse sur le routeur TX Matrix :[edit system syslog] host scc-master { any info; }
À partir de Junos OS version 15.1X49-D10 et Junos OS version 17.3R1, de même, sur une matrice de routage composée d’un routeur TX Matrix Plus avec des routeurs T1600 ou T4000 connectés, le moteur de routage principal de chaque T1600 ou T4000 LCC transfère au moteur de routage principal du routeur TX Matrix Plus tous les messages dont la gravité est supérieure ou égale
info
. Ceci est équivalent à l’instruction de configuration suivante incluse sur le routeur TX Matrix Plus :REMARQUE :Du point de vue de l’interface utilisateur, la matrice de routage apparaît comme un routeur unique. Le routeur TX Matrix Plus contrôle tous les routeurs T1600 ou T4000 qui lui sont connectés dans la matrice de routage.
[edit system syslog] host sfc0-master { any info; }
Interpréter les messages générés dans un format standard
La syntaxe d’un message au format standard généré par un processus ou une bibliothèque de sous-programmes Junos OS varie selon qu’il inclut ou non les informations de priorité ci-dessous :
Lorsque l’instruction est incluse au niveau hiérarchique [] ou [filenamehostname], la syntaxe d’un
explicit-priority
message du journal système est la suivante :timestamp message-source: %facility–severity–TAG: message-text
Lorsqu’il est dirigé vers la console ou les utilisateurs, ou lorsque l’instruction n’est pas incluse pour les
explicit-priority
fichiers ou les hôtes distants, un message de journal système a la syntaxe suivante :timestamp message-source: TAG: message-text
Tableau 4 Décrit les champs de message.
Champ | Description |
---|---|
timestamp |
Heure à laquelle le message a été enregistré. |
message-source |
Identificateur du processus ou du composant qui génère le message et de la plate-forme de routage sur laquelle le message a été enregistré. Pour Junos OS, ce champ comprend au moins deux sous-champs : nom d’hôte, processus et ID de processus (PID). Pour Junos OS Evolved, ce champ inclut un nom d’hôte auquel sont ajoutés un nom de nud, un nom de processus et un PID. Si l’instruction est configurée au niveau hiérarchique [edit system syslog] sur un périphérique Junos OS Evolved, le nom du noeud n’est pas ajouté au nom d’hôte hostname process[process-ID] |
facility |
Code qui spécifie la fonction à laquelle appartient le message du journal système. Pour obtenir un mappage des codes aux noms d’installations, voir Tableau : Codes d’installation déclarés dans Informations de priorité dans Inclure les informations de priorité dans les messages de journal système. |
severity |
Code numérique représentant le niveau de gravité attribué au message du journal système. Pour obtenir un mappage des codes aux noms de gravité, reportez-vous à la section Tableau : Codes numériques pour les niveaux de gravité indiqués dans Informations de priorité dans Inclusion des informations de priorité dans les messages de journal système. |
TAG |
Chaîne de texte qui identifie le message de manière unique, en majuscules et en utilisant le trait de soulignement (_) pour séparer les mots. Le nom de la balise commence par un préfixe qui indique le processus ou la bibliothèque logicielle génératrice. Les entrées de cette référence sont classées par ordre alphabétique de ce préfixe. Tous les processus d’une plateforme de routage n’utilisent pas de balises, ce champ n’apparaît donc pas toujours. |
message-text |
Texte du message. |
Gérer les fichiers journaux et principaux du système d’exploitation hôte
Sur les commutateurs Junos OS dotés d’un système d’exploitation hôte, Junos OS peut générer des messages de journal système (également appelés messages syslog) pour enregistrer les événements qui se produisent sur le commutateur, notamment les suivants :
Opérations de routine, telles que la connexion d’un utilisateur à la base de données de configuration.
Conditions de défaillance et d’erreur.
Conditions d’urgence ou critiques, telles que la mise hors tension du commutateur en raison d’une température excessive.
Sur les commutateurs OCX Series :
Les messages du journal système sont consignés dans le /var/log/dcpfe.log fichier du système d’exploitation hôte dans les scénarios suivants :
Lorsque le démon de transfert est initialisé.
Les messages sont marqués comme étant d’urgence (LOG_EMERG). Une copie du message est également envoyée au /var/log répertoire du commutateur.
Les messages des processus sont disponibles sur le système hôte dans l’annuaire /var/log . Les messages du journal système du processus de gestion du châssis hôte sont enregistrés dans le lcmd.log fichier du /var/log répertoire.
Sur les commutateurs QFX dotés d’un système d’exploitation hôte :
Junos OS et le système d’exploitation hôte enregistrent les messages du journal des événements système et de processus et génèrent des fichiers de base en cas de défaillance du système.
Ces fichiers sont stockés dans des répertoires tels que /var/log pour les messages de journal, et /var/tmp ou /var/crash pour les fichiers de base, selon le type de système d’exploitation hôte exécuté sur le commutateur.
À des fins de diagnostic, vous pouvez accéder aux fichiers journaux, principaux et journaux du système d’exploitation hôte à partir de l’interface de ligne de commande Junos OS du commutateur. Vous pouvez également nettoyer les répertoires dans lesquels le système d’exploitation hôte stocke les journaux temporaires et d’autres fichiers.
Cette rubrique comprend les sections suivantes :
- Afficher les fichiers journaux sur le système d’exploitation hôte
- Copier les fichiers journaux du système hôte vers le commutateur
- Afficher les fichiers principaux sur le système d’exploitation hôte
- Copier les fichiers principaux du système hôte vers le commutateur
- Nettoyer les fichiers temporaires sur le système d’exploitation hôte
Afficher les fichiers journaux sur le système d’exploitation hôte
Pour afficher la liste des fichiers journaux créés sur le système d’exploitation hôte, entrez la commande suivante :
user@switch> show app-engine logs
Copier les fichiers journaux du système hôte vers le commutateur
Pour copier les fichiers journaux du système d’exploitation hôte vers le commutateur, entrez la commande suivante :
user@switch> request app-engine file-copy log from-jhost source to-vjunos destination
Par exemple, pour copier le fichier journal sur le lcmd commutateur, entrez la commande suivante :
user@switch> request app-engine file-copy log from-jhost lcmd.log to-vjunos /var/tmp
Afficher les fichiers principaux sur le système d’exploitation hôte
Pour afficher la liste des fichiers principaux générés et stockés sur le système d’exploitation hôte, entrez la commande suivante :
user@switch> show app-engine crash
La liste peut ressembler à cet exemple de sortie :
Compute cluster: default-cluster Compute node: default-node Crash Info ========== total 13480 -rw-r--r-- 1 root root 178046 Feb 14 23:08 localhost.lcmd.26653.1455520135.core.tgz -rw-r--r-- 1 root root 4330343 Feb 15 00:45 localhost.dcpfe.7155.1455525926.core.tgz -rw-r--r-- 1 root root 4285901 Feb 15 01:49 localhost.dcpfe.25876.1455529782.core.tgz -rw-r--r-- 1 root root 4288508 Feb 15 02:39 localhost.dcpfe.713.1455532774.core.tgz -rw-r--r-- 1 root root 264079 Feb 15 17:02 localhost.lcmd.1144.1455584540.core.tgz
Copier les fichiers principaux du système hôte vers le commutateur
Pour copier les fichiers principaux du système d’exploitation hôte vers le commutateur, entrez la commande suivante :
user@switch> request app-engine file-copy crash from-jhost source to-vjunos destination-dir-or-file-path
Lorsque le chemin d’accès Junos OS de destination est un répertoire, le nom de fichier source est utilisé par défaut. Pour renommer le fichier à la destination, entrez l’argument de destination sous la forme d’un chemin d’accès complet, y compris le nom de fichier souhaité.
Par exemple, pour copier le fichier d’archive principal sur le localhost.lcmd.26653.1455520135.core.tgz commutateur, entrez la commande suivante :
user@switch> request app-engine file-copy crash from-jhost localhost.lcmd.26653.1455520135.core.tgz to-vjunos /var/tmp
Pour afficher les résultats sur le commutateur, entrez la commande suivante :
user@switch> show system core-dumps re0: -------------------------------------------------------------------------- -rw-r--r-- 1 root field 178046 Feb 15 17:15 /var/tmp/localhost.lcmd.26653.1455520135.core.tgz total files: 1
Nettoyer les fichiers temporaires sur le système d’exploitation hôte
Pour supprimer les fichiers temporaires créés sur le système d’exploitation hôte, entrez la commande suivante :
user@switch> request app-engine cleanup
Par exemple, l’exemple de sortie suivant sur un commutateur doté d’un système d’exploitation hôte Linux montre le nettoyage des fichiers temporaires stockés dans /var/tmp :
Compute cluster: default-cluster Compute node: default-node Cleanup (/var/tmp) =======
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
info
.