Introduction
Ce document décrit les différents journaux disponibles dans NSO, à quoi ils servent et comment les activer.
Conditions préalables
Exigences
Pour afficher, activer et définir des journaux, vous devez disposer d'un utilisateur ayant accès à l'environnement hôte exécutant le service NSO, ainsi qu'à l'interface de ligne de commande NSO et au port NSO IPC.
Composants utilisés
Cisco Crosswork Network Service Orchestrator (NSO) version 6.4.1
Ce document a été écrit pour les options de journalisation disponibles depuis NSO 6.4. Bien que la plupart des informations de ce document s'appliquent à toutes les versions, certains journaux peuvent avoir été désapprouvés ou ajoutés par rapport à la version que vous utilisez. Ce document ne couvre pas la configuration pour exporter des journaux en dehors du système NSO.
Les commandes fournies dans ce document supposent un NSO d'installation du système utilisant la configuration de répertoire par défaut. Dans votre environnement, l'emplacement de certains fichiers peut varier.
- ncs.conf se trouve dans $NCS_CONFIG_DIR, par défaut /etc/ncs/ncs.conf
- Les journaux se trouvent dans $NCS_LOG_DIR, par défaut /var/log/ncs/
- NSO est installé dans $NCSDIR, par défaut /opt/ncs/
- Le répertoire actif de NSO est $NCS_RUN_DIR, par défaut /var/opt/ncs/
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Consignes générales de consignation
Impact de journalisation
L'activation de journaux à un niveau de détail plus élevé peut entraîner une augmentation de la charge et des besoins en espace disque pour le serveur NSO. Ceci est particulièrement important pour les journaux très actifs tels que devel.log. L'activation du verbosité pendant de courtes périodes au cours du dépannage n'est généralement pas une préoccupation, mais lorsque vous l'activez pendant de plus longues périodes, assurez-vous de prendre en compte les ressources et l'espace disque.
Génération d'un rapport technique
To generate a tech report for NSO, run the script at /opt/ncs/current/bin/ncs-collect-tech-report.
Options:
--install-dir
: Spécifie le répertoire d'installation des fichiers statiques NCS, comme l'option —install-dir du programme d'installation.
--full
: Collecte une sauvegarde ncs du système, ce qui facilite la reproduction des erreurs par l'assistance Cisco.
--num-debug-dumps
: Par défaut 1, génère un instantané debug-dump. Pour les cas de suivi des fuites de ressources, telles que les fuites de mémoire/descripteur de fichier, définissez cette valeur sur 3.
Options recommandées :
/opt/ncs/current/bin/ncs-collect-tech-report --num-debug-dumps 3
Une sauvegarde peut être collectée et fournie séparément pour limiter la taille de fichier de l'offre pour faciliter les téléchargements.
Le rapport technique est généré dans le répertoire courant à partir duquel le script est exécuté.
Remarque : Un rapport technique collecte le contenu du répertoire du journal NSO. Vérifiez que ce répertoire ne contient pas de rapports techniques ou de sauvegardes antérieurs avant de générer votre nouveau rapport technique.
Génération d'une sauvegarde
/opt/ncs/current/bin/ncs-backup
Les sauvegardes sont générées dans /var/opt/ncs/backups/.
Fichiers journaux non générés
Lorsqu'un fichier journal est archivé ou supprimé, NSO doit créer un nouveau fichier. Généralement, cela se produit automatiquement, mais dans le cas contraire, utilisez la commande :
/opt/ncs/current/bin/ncs_cmd -c reopen_logs
.
Remarque : Lorsque vous restreignez l'accès au port IPC, par exemple, en utilisant le paramètre ipc-access dans ncs.conf, assurez-vous de définir les variables nécessaires dans cron ou anacron afin que la rotation hebdomadaire des journaux puisse rouvrir correctement les journaux.
Présentation des journaux
- Journaux internes NSO
- ncs.log : Le journal ncs consigne le processus principal de NSO. Il dispose d'informations limitées mais peut être utilisé pour les problèmes liés à l'arrêt, au démarrage, au chargement des packages et aux mises à niveau.
- audit.log : Le journal d'audit consigne tous les utilisateurs s'authentifiant sur NSO via une API. Il consigne également toute activité sur l'interface de ligne de commande NSO et les interfaces ascendantes à faible niveau de détail.
- audit-log-commit : L'activation de ce paramètre améliore le fichier audit.log. Il ne crée pas son propre journal. Il consigne toutes les modifications non par défaut apportées à NSO CDB pendant les opérations de validation et de synchronisation.
- audit-log-commit-defaults : L'activation de ce paramètre améliore le fichier audit.log. Il ne crée pas son propre journal. Il consigne toutes les modifications par défaut apportées à NSO CDB pendant les opérations de validation et de synchronisation.
- devel.log : Le journal de développement consigne les opérations générales et les workflows de NSO.
- ncs-java-vm.log : Le journal java consigne toutes les opérations liées à java-vm. Plus particulièrement tout pilote d'élément réseau (NED) et des packages de services écrits en Java. Tous les NED CLI sont écrits en java.
- ncs-python-vm.log : Les journaux python consignent l'activité relative aux paquets de service écrits en Python. Un journal python séparé est généré pour chaque service-package écrit en python. Aucun NED n'est écrit en python.
- upgrade.log : Le journal de mise à niveau consigne les modifications apportées aux modèles NSO lors des mises à niveau NSO, y compris les mises à niveau de version NSO et les mises à niveau de package NSO lors du rechargement des packages.
- raft.log : Un journal spécifique aux clusters NSO exploitant les fonctionnalités HA-Raft.
- Sortie de HA-raft EPMD : Ce résultat n'est pas un journal NSO traditionnel, EPMD est utilisé dans HA-raft pour faciliter la découverte de noeuds. Ces instructions expliquent comment obtenir des informations de débogage pour EPMD.
- journalisation epmd : Ajout d'entrées de journalisation supplémentaires pour la fonctionnalité HA-Raft.
- xpath.trace : La trace xpath enregistre toutes les évaluations xpath effectuées par NSO. Cela peut être utile pour comprendre pourquoi une opération de suppression prend beaucoup de temps.
- ncserr.log : ncserr.log sont des journaux binaires qui enregistrent les erreurs des processus internes du démon NCS. Obligatoire pour la plupart des messages d'erreur « interne » et des scénarios de panne.
- transerr.log : Le journal d'erreurs de transaction est un journal destiné à collecter des informations sur les transactions ayant échoué qui entraînent soit une erreur de démarrage CDB, soit un échec de transaction d'exécution.
- progress.trace : Le suivi de progression est utilisé pour suivre les événements de progression émis par les transactions et les actions dans le système. Les données à émettre sont configurées dans /progress/trace.
- ncs-smart-licensing.log : Journaux de la licence smart-agent dans NSO.
- Vers le nord : Arrivée au NSO à partir des éléments en direction du nord
- audit.log : Le journal d'audit consigne les commandes exécutées sur l'interface de ligne de commande NSO.
- localhost:8080.access/localhost:8888.access : Il s'agit d'un journal d'accès pour le serveur Web intégré et collecte l'activité HTTP. Ce fichier respecte le format de fichier journal commun, tel que défini par Apache
- traffic.trace : Ce journal collecte un trafic HTTP très prolixe. Utilisez-le pour déboguer l'API Restconf et json-rpc.
- netconf.log : Journal pour l'API netconf
- netconf-trace.log : Journal de l'API netconf à haut niveau de détail
- json-rpc.log : Journal de l'API json-rpc.log
- Vers le sud : Consignation de la communication entre NSO et le réseau.
- Suivi NED du périphérique : Chaque périphérique génère sa propre trace. Les suivis de périphériques sont nommés en tant que end-<end-id>-<devicename>.trace ou netconf-<devicename>.trace
- audit-network.log : Enregistre les commandes de configuration envoyées par NSO aux périphériques en direction du sud.
- Journaux du système
- Journaux Linux : Généralement trouvé dans /var/log/ et inclut des journaux tels que des messages ou syslog. Elles varient en fonction de l’hôte.
- ncs_crash.dump : Vidage du système NSO généré lorsque NSO se termine en raison de problèmes de mémoire.
- Core dump : Lorsque NSO est terminé pour des raisons non liées à la mémoire, Linux peut générer un vidage de mémoire appelé core.<PID>
Certaines conditions doivent être remplies pour que Linux puisse générer un core dump. La configuration ulimit est le paramètre le plus courant pour empêcher un vidage. Voir la page du manuel Linux pour une liste complète des exigences
Remarque : Les journaux système ne sont pas collectés par le rapport technique NCS, mais ils peuvent être utiles pour les problèmes de performances et de panne.
Activation des journaux et définition du niveau de détail
Remarque : Pour modifier les paramètres de configuration dans le fichier ncs.conf, exécutez la ncs --reload
commande. ncs --reload, it
recharge les valeurs à partir du fichier ncs.conf et met à jour le système en cours d'exécution, puis ferme et rouvre tous les fichiers journaux afin que les modifications de journalisation soient appliquées. Cela n'interrompt pas les services.
Lignes directrices générales
- Lorsque le fichier ncs.conf ne contient pas de configuration spécifique, NSO adopte le comportement par défaut spécifié dans le
/opt/ncs/current/src/ncs/ncs_config/tailf-ncs-config.yang
fichier.
- Lorsqu'un journal est spécifié comme activé par défaut, cela signifie qu'il est activé même si la configuration pour l'activer est manquante.
- Certains journaux sont désactivés par défaut, mais lors de la première installation de NSO, ncs.conf a des instructions spécifiques pour activer le journal.
- Lorsque le fichier ncs.conf ne contient pas de configuration spécifique, vous pouvez l'ajouter comme indiqué sous la
logs container
, c'est-à-dire entre
et
dans le fichier ncs.conf.
Interne
ncs.log
Ce journal est activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <ncs-log>.
true
${NCS_LOG_DIR}/ncs.log
true
Après avoir édité ncs.conf, exécutez ncs —reload.
audit.log
Ce journal est activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <audit-log>.
true
${NCS_LOG_DIR}/audit.log
true
Après avoir édité ncs.conf, exécutez ncs —reload.
audit-log-commit et audit-log-commit-defaults
Ce journal n'est pas activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et ajoutez le contenu après <audit-log>.
true
${NCS_LOG_DIR}/audit.log
true
true
true
Après avoir édité ncs.conf, exécutez ncs —reload.
devel.log
Ce journal est activé par défaut à INFO verbosity. Pour activer et modifier le niveau de détail de ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <developer-log>.
true
${NCS_LOG_DIR}/devel.log
true
trace
Après avoir édité ncs.conf, exécutez ncs —reload.
ncs-java-vm.log
Ce journal est activé par défaut à INFO verbosity. Il est possible de définir le niveau de détail des éléments individuels gérés par java-vm. Le niveau de détail est modifié à partir de l'interface de ligne de commande NSO qui est accessible via SSH ou ncs_cli -C -noaaa
Pour augmenter le niveau de détail de tous les éléments java sous com.tailf :
configuration
java-vm java-logging logger com.tailf level-trace
commit no-networking
Pour augmenter le niveau de détail d'un package NED spécifique :
configuration
java-vm java-logging logger com.tailf.packages.end.<NED-name> level-trace
commit no-networking
Pour augmenter le niveau de détail du client SSHJ utilisé dans les paquets java NED :
configuration
java-vm java-logging logger net.schmizz.sshj level-error
commit no-networking
Remarque : Cisco recommande de définir la journalisation du client SSHJ sur level-error. Elle est désactivée par défaut.
Pour rétablir la journalisation d'un élément Java spécifique :
configuration
no java-vm java-logging logger com.tailf
commit no-networking
Pour afficher les paramètres de journalisation actuels de java-vm :
show running-config java-vm java-logging
ncs-python-vm.log
Ce journal est activé par défaut à INFO verbosity. Le niveau de détail est modifié à partir de l'interface de ligne de commande NSO qui est accessible via SSH ou ncs_cli -C -noaaa.
Pour définir le niveau de détail des journaux de toutes les machines virtuelles Python.
configuration
python-vm logging level-debug
commit no-networking
Pour revenir en arrière :
configuration
no python-vm logging level-debug
commit no-networking
Pour afficher les paramètres de journalisation python-vm actuels :
show running-config python-vm logging
upgrade.log
Ce journal est activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <upgrade-log>.
true
${NCS_LOG_DIR}/upgrade.log
true
Après avoir édité ncs.conf, exécutez ncs —reload.
raft.log
Ce journal est activé par défaut à INFO verbosity. Pour activer et définir le niveau de détail de ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <raft-log>.
true
${NCS_LOG_DIR}/raft.log
true
trace
Après avoir édité ncs.conf, exécutez ncs —reload.
Sortie HA-Raft EPMD
Cette sortie n'est pas activée par défaut et n'écrit pas dans un fichier journal. Au lieu de cela, il écrit dans un terminal.
- Arrêter toutes les instances NSO
systemctl stop ncs.service
- Ouvrez un nouveau terminal, arrêtez EPMD et démarrez EPMD en mode de débogage
epmd -kill
epmd -d
- Démarrer NSO
systemctl start ncs.service
- Reproduisez le problème. Le terminal affiche les données de débogage EPMD.
xpath.trace
Ce journal n'est pas activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <xpath-trace-log>.
true
${NCS_LOG_DIR}/xpath.trace
Après avoir édité ncs.conf, exécutez ncs —reload.
ncserr.log
Ce journal enregistre une quantité limitée d'informations. NSO gère 5 fichiers d'erreur, chacun avec une taille maximale de 1 Mo par défaut. Dans les rares cas où un problème se produit qui crée plus de 5 Mo de données de journal, vous devez augmenter la taille maximale. Ce journal est activé par défaut. Pour modifier la taille maximale de ce journal à 10 Mo par fichier, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <error-log>.
true
${NCS_LOG_DIR}/ncserr.log
S10M
Après avoir édité ncs.conf, exécutez ncs —reload.
journal de transfert
Ce journal n'est pas activé par défaut, mais activé dans ncs.conf lors de la première installation. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <transaction-error-log>.
true
${NCS_LOG_DIR}/transerr.log
Après avoir édité ncs.conf, exécutez ncs —reload.
progr.trace
Ce journal n'est pas activé par défaut, mais activé dans ncs.conf lors de la première installation. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <progress-trace>.
true
${NCS_LOG_DIR}
Après avoir édité ncs.conf, exécutez ncs —reload.
ncs-smart-licensing.log
Ce journal n'est pas activé par défaut. Le journal est activé à partir de l'interface de ligne de commande NSO qui est accessible via SSH ou ncs_cli -C -noaaa. Pour activer ce journal :
configuration
smart-license smart-agent stdout-capture activée
commit no-networking
Pour annuler la modification de journalisation :
configuration
aucune licence smart smart-agent stdout-capture activée
commit no-networking
Vers Le Nord
localhost:xxxx.access
Ce journal est activé par défaut. Le nom de ce journal varie en fonction du port HTTP. Par défaut, 8080 et 8888. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <webui-access-log>.
true
${NCS_LOG_DIR}
Après avoir édité ncs.conf, exécutez ncs —reload.
traffic.trace
Ce journal n'est pas activé par défaut. traffic.trace les journaux sont générés dans un répertoire tel que /var/log/ncs/trace_20240628_010010/. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <webui-access-log>.
true
${NCS_LOG_DIR}
true
Après avoir édité ncs.conf, exécutez ncs —reload.
netconf.log
Ce journal est activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et ajoutez le contenu après <netconf-log>.
true
${NCS_LOG_DIR}/netconf.log
true
Après avoir modifié ncs.conf, exécutez ncs —reload
Option supplémentaire : Insérez true
après
pour que NSO consigne l'état de la réponse rpc « ok » ou « error ».
netconf-trace.log
Ce journal n'est pas activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et modifiez le contenu de <netconf-trace-log>.
true
${NCS_LOG_DIR}/netconf-trace.log
Après avoir édité ncs.conf, exécutez ncs —reload.
json-rpc.log
Ce journal n'est pas activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et ajoutez le contenu après <jsonrpc-log>.
true
${NCS_LOG_DIR}/json-rpc.log
true
Après avoir édité ncs.conf, exécutez ncs —reload.
En Direction Du Sud
Périphérique NED Trace
Ce journal n'est pas activé par défaut. Le journal est activé à partir de l'interface de ligne de commande NSO qui est accessible via SSH ou ncs_cli -C -noaaa.
Pour activer un suivi pour un périphérique :
configuration
périphériques périphérique <nompériphérique> trace raw
périphériques périphérique <nom_périphérique> paramètres_fin <id_fin> niveau de l'enregistreur debug
commit no-networking
Pour afficher tous les paramètres de journalisation appliqués à un périphérique, utilisez show devices device <nompériphérique> active-settings.
Pour effacer le contenu d'un fichier de suivi de périphérique, utilisez devices device <nom du périphérique> clear-trace.
Pour désactiver la trace du périphérique :
configuration
no devices device <nompériphérique> trace
commit no-networking
audit-network.log
Ce journal n'est pas activé par défaut. Pour activer ce journal, ouvrez /etc/ncs/ncs.conf et ajoutez le contenu après <audit-network-log>.
true
${NCS_LOG_DIR}/audit-network.log
true
Après avoir édité ncs.conf, exécutez ncs —reload.