Dépannage de la journalisation
Utilisez les informations de diagnostic pour identifier et résoudre les problèmes courants qui peuvent survenir lors de l'utilisation du service de journalisation.
Dépannage général de l'agent unifié de surveillance
Exigences relatives au matériel
Selon les exigences de journalisation et la configuration (nombre de journaux, type de mise en mémoire tampon, etc.), les exigences relatives au matériel et la performance de l'agent unifié de surveillance peuvent varier considérablement. En l'absence de pression opérationnelle (moins de 1 000 événements de journal par minute), l'agent ne doit pas consommer plus de 200 Mo de mémoire vive et 20 % d'un coeur de processeur. Les limites codées de façon permanente de l'agent unifié de surveillance sont 5 Go de mémoire vive et 40 % d'un coeur. 1 Go de mémoire vive est également recommandé.
Activation de la surveillance
La surveillance peut vous aider à résoudre les problèmes. Voir Activation de la surveillance pour les instances de calcul pour plus d'informations sur la façon dont vous pouvez activer la surveillance (mesures et journalisation) dans les instances du service Calcul pour Oracle Cloud Infrastructure.
Agent de surveillance unifiée Linux
Unités systemd
L'agent unifié de surveillance est basé sur les unités systemd et se compose des composants suivants :
- unified-monitoring-agent.service : Service principal de l'agent unifié de surveillance.
- unified-monitoring-agent_config_downloader.service : Service du programme de mise à jour automatique de configuration.
- unified-monitoring-agent_config_downloader.timer : Unité de temporisateur qui déclenche le service du programme de téléchargement automatique à des intervalles spécifiés, aléatoires.
- unified-monitoring-agent_restarter.path : Unité de chemin, qui déclenche le rechargement de la configuration par l'agent unifié de surveillance, si une modification est détectée (à cause du téléchargement d'une nouvelle configuration par le service du programme de mise à jour automatique).
La plupart des commandes systemctl ou journalctl doivent être exécutées avec des privilèges de superutilisateur (en tant que
root ou au moyen de sudo).Pour vérifier le bon fonctionnement de ces unités systemd, vous pouvez utiliser la commande systemctl comme suit :
systemctl status <unit_name>
Lorsque <unit_name> doit être remplacé par l'une des valeurs suivantes :
-
unified-monitoring-agent.service -
unified-monitoring-agent_config_downloader.service -
unified-monitoring-agent_config_downloader.timer -
unified-monitoring-agent_restarter.path
En général, ces commandes systemctl affichent une sortie similaire à la suivante :
systemctl status unified-monitoring-agent.service
unified-monitoring-agent.service - unified-monitoring-agent: Fluentd based data collector for Oracle Cloud Infrastructure
Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-09-29 13:54:03 UTC; 1min 37s ago
Docs: https://docs.cloud.oracle.com/
Process: 2337 ExecReload=/bin/kill -USR2 ${MAINPID} (code=exited, status=0/SUCCESS)
Process: 2321 ExecStart=/opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 $EXTRA_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 2327 (fluentd)
Memory: 66.3M (limit: 5.0G)
CGroup: /system.slice/unified-monitoring-agent.service
├─2327 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unif...
└─2330 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.lo...
systemctl status unified-monitoring-agent_config_downloader.service
unified-monitoring-agent_config_downloader.service - unified-monitoring-agent Fluentd configuration downloader.
Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2020-09-29 13:54:38 UTC; 1min 30s ago
Process: 2333 ExecStart=/opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluent_config_updater.rb -c /etc/unified-monitoring-agent/conf.d/ -b 10 (code=exited, status=0/SUCCESS)
Main PID: 2333 (code=exited, status=0/SUCCESS)
systemctl status unified-monitoring-agent_config_downloader.timer
unified-monitoring-agent_config_downloader.timer - Run unified-monitoring-agent configuration automatic updater.
Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 3min 57s ago
systemctl status unified-monitoring-agent_restarter.path
unified-monitoring-agent_restarter.path - "Monitor the /etc/unified-monitoring-agent/conf.d/ directory for changes"
Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_restarter.path; enabled; vendor preset: disabled)
Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 4min 9s ago
Les parties les plus importantes de la sortie de commande systemctl sont les champs Loaded et Active. Le champ Loaded contient la valeur loaded pour toutes les unités de système. Le champ Active contient les valeurs suivantes :
-
active (running)pour l'unité unified-monitoring-agent.service. -
active (waiting)ouactive (running)pour les unités unified-monitoring-agent_restarter.path et unified-monitoring-agent_config_downloader.timer. -
active (running)ouinactive (dead)pour l'unité unified-monitoring-agent_config_downloader.service. Pour cette dernière valeur, le champMain PIDinclut la valeurcode=exited, status=0/SUCCESS).
Vérifier les processus en cours
Une autre façon de vérifier plus en profondeur le bon fonctionnement de l'agent unifié de surveillance consiste à vérifier les processus d'exécution du système. Lorsqu'il fonctionne correctement, l'agent unifié de surveillance exécute deux processus : un processus de superviseur et un processus de travailleur. Vous pouvez vérifier leur existence en exécutant la commande suivante dans un terminal (exemple de sortie inclus) :
ps aux | grep unified-monitoring-agen[t]
root 2327 0.0 2.3 307704 40864 ? Sl 13:54 0:00 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10
root 2330 0.2 2.1 297456 38192 ? S 13:54 0:03 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 --under-supervisor
Comme indiqué dans l'exemple précédent, deux processus s'exécutent, avec les mêmes arguments, à l'exception de la valeur –under-supervisor supplémentaire ajoutée au second. Cela désigne le processus de travailleur, ce qui fait du processus sans ce paramètre le superviseur.
Emplacement du journal de l'agent unifié de surveillance
La plupart des commandes systemctl ou journalctl doivent être exécutées avec des privilèges de superutilisateur (en tant que
root ou au moyen de sudo).Les journaux de l'agent unifié de surveillance sont disponibles à /var/log/unified-monitoring-agent/unified-monitoring-agent.log. Ce fichier inclut les journaux de l'agent unifié de surveillance lui-même.
Outre les journaux de l'agent, qui ne contiennent pas d'événements connexes au système (par exemple, démarrage du service, arrêt du service, etc.), vous pouvez également voir les journaux dans le service de journalisation de système de journald et systemd. Pour voir les journaux de système propres à une unité, vous pouvez utiliser la commande journalctl comme suit :
journalctl -u <unit_name>
Lorsque <unit_name> doit être remplacé par l'une des valeurs suivantes :
-
unified-monitoring-agent.service -
unified-monitoring-agent_config_downloader.service -
unified-monitoring-agent_config_downloader.timer -
unified-monitoring-agent_restarter.path
journald au moyen de journalctl, vous pouvez également définir des intervalles de temps spécifiques : journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"Le format de date utilisé est AAAA-MM-JJ HH:MM:SS. -f : journalctl -f
L'agent unifié de surveillance n'est pas installé
Pour les instances récemment créées, l'installation automatique de l'agent peut prendre jusqu'à 25 minutes. S'il n'est pas installé après cette période, vérifiez les éléments suivants :
- La connectivité réseau de l'instance.
- Si la surveillance est activée dans la console.
Vous pouvez également vérifier le fichier journal /var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.log pour des informations sur l'installation de l'agent unifié de surveillance par Oracle Cloud Agent.
L'agent unifié de surveillance n'est pas exécuté
Si le statut n'est pas chargé ou actif, et que les processus de superviseur et de travailleur ne sont pas en cours d'exécution, redémarrez l'agent de surveillance unifiée et vérifiez les journaux pour connaître les problèmes suivants :
systemctl restart unified-monitoring-agent
Configuration non téléchargée automatiquement
Assurez-vous d'avoir suivi les étapes sous Installation de l'agent et Vérifier l'installation de l'agent. Consultez le journal du service du programme de mise à jour automatique de configuration en exécutant :
journalctl -u unified-monitoring-agent_config_downloader.service
Configuration non rechargée automatiquement
Assurez-vous d'avoir suivi les étapes sous Installation de l'agent et Vérifier l'installation de l'agent. Consultez le journal de toutes les unités :
- L'unité de temporisateur doit avoir été exécutée au moins une fois.
- Le service de téléchargement de configuration automatique doit avoir été exécuté après son déclenchement par l'unité de temporisateur pertinente. Vous pouvez vérifier dans ses journaux que la configuration a été téléchargée et extraite dans le répertoire de configuration de l'agent Unified Monitoring Agent. Vous pouvez également le vérifier en listant les fichiers de ce répertoire : ls -lhatR /etc/unified-monitoring-agent.
- Vérifiez que l'unité de chemin est active en vérifiant son statut : systemctl status unified-monitoring-agent_restarter.path.
- Vérifiez qu'un signal de rechargement a été reçu par l'agent unifié de surveillance en examinant son journal : journalctl -u unified-monitoring-agent_config_downloader.service. "Rechargement de unified-monitoring-agent" apparaît dans la sortie de cette commande.
Tester le modèle d'analyse et forcer l'agent à télécharger immédiatement la configuration
Exécutez la commande suivante :
systemctl restart unified-monitoring-agent_config_downloader
La mise à jour automatique de la configuration côté agent peut prendre jusqu'à 30 minutes.
Créer un journal personnalisé pour voir le contenu d'un journal d'alerte d'un système de base de données à l'aide d'OCI
L'agent de surveillance unifiée ne prend pas en charge le système de base de données.
Collecte des données
Si vous voulez ouvrir un ticket afin qu'un ingénieur puisse vous aider à résoudre le problème ayant trait à l'agent unifié de surveillance, incluez la sortie des commandes suivantes. Des privilèges de superutilisateur peuvent être requis pour certains d'entre elles.
yum info unified-monitoring-agent
rpm -ql unified-monitoring-agent | xargs sha512sum
systemctl status --full unified-monitoring-agent.service
systemctl status --full unified-monitoring-agent_config_downloader.service
systemctl status --full unified-monitoring-agent_config_downloader.timer
systemctl status --full unified-monitoring-agent_restarter.path
journalctl -a --no-pager -u unified-monitoring-agent.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.timer
journalctl -a --no-pager -u unified-monitoring-agent_restarter.path
Pour Ubuntu, utilisez une commande comme suit :
apt show unified-monitoring-agent
dpkg -L unified-monitoring-agent | xargs sha512sum
Incluez également une archive des fichiers sous /var/log/unified-monitoring-agent/ et /var/log/oracle-cloud-agent/. Vous pouvez créer une archive tar et gzip de ces répertoires avec la commande suivante :
tar cvzf agent_logs_$(date +%s).tar.gz /var/log/unified-monitoring-agent/ /var/log/oracle-cloud-agent/
Si l'agent unifié de surveillance est en cours d'exécution, mais qu'il a un comportement erratique, vous pouvez également inclure des informations de profil de suivi arrière et de profil de mémoire, en exécutant la commande suivante et en incluant les fichiers /tmp/sigdump-<integer>.log dans votre rapport (où <integer> est un nombre entier de 1 à 6 chiffres, même si dans de rares cas il peut en avoir plus).
ps aux | grep unified-monitoring-agen[t] | grep ruby | awk '{print $2}' | xargs kill -SIGCONT
Cette commande permet de rechercher les ID de processus de l'agent unifié de surveillance et de leur envoyer le signal SIGCONT, ce qui entraîne la génération d'un vidage dans /tmp/sigdump-<integer>.log.
Désinstaller et réinstaller
Vous pouvez supprimer l'agent unifié de surveillance, sans supprimer la configuration de l'agent, en exécutant la commande suivante :
yum -y remove unified-monitoring-agent
Pour Ubuntu :
apt -y remove unified-monitoring-agent
La configuration de l'agent reste dans le répertoire /etc/unified-monitoring-agent/. Si vous ne voulez pas conserver la configuration pour une (ré)installation future de l'ensemble de l'agent unifié de surveillance, vous devez la supprimer manuellement :
# use the following command to print the contents of the agent's configuration directory
find /etc/unified-monitoring-agent/
# use the following command to remove the directory and all of its contents (this step cannot be undone)
rm -rf /etc/unified-monitoring-agent/
L'agent est automatiquement réinstallé par Oracle Cloud Agent, en 25 minutes au plus. La surveillance de l'instance dans la console doit être activée pour que cela se produise. Voir Oracle Cloud Agent pour plus d'informations.
Agent de surveillance unifiée Windows
Pour vérifier le statut du service
- L'agent s'exécute dans le cadre d'un service Windows, pour voir son statut, ouvrez le menu Démarrer, entrez Services.msc et ouvrez-le. Allez au service Service unifié de surveillance Oracle Cloud pour voir le statut.
- Cliquez avec le bouton droit de la souris sur le service et sélectionnez Propriétés pour plus d'informations. Les actions Démarrer/arrêter/redémarrer sont disponibles ici.
- Dans le menu Démarrer, entrez cmd, cliquez avec le bouton droit de la souris sur Invite de commande et sélectionnez Exécuter en tant qu'administrateur. Exécutez les commandes suivantes :
- Pour voir le statut du service Agent unifié de surveillance :
sc query unified-monitoring-agent - Redémarrez le service Agent unifié de surveillance :
sc stop unified-monitoring-agent sc start unified-monitoring-agent
Les commandes précédentes ne fonctionnent pas dans PowerShell. Vous devez donc utiliser l'invite de commande Windows à la place.
Pour rechercher des erreurs de service Windows
- Dans le menu Démarrer, entrez Observateur d’événements et sélectionnez-le.
- Ouvrez Journaux Windows, puis Système. Chaque fois qu'un service démarre ou s'arrête, échoue dans l'une de ces opérations ou tombe soudainement en panne, l'événement est enregistré ici.Note
Sur la plupart des machines Windows, le nombre d'événements pouvant se trouver dans l'Observateur d’événements est limité. Par conséquent, si un événement s'est produit il y a longtemps, les journaux risquent de ne pas être disponibles.
Pour voir les journaux Fluentd
- Ouvrez explorer.exe (icône de fichier dans la barre des tâches)
- Allez à C:\oracle_unified_agent.
- S'il n'existe qu'un seul fichier, cela signifie qu'il n'y a pas de fichier de configuration valide sur l'ordinateur.
- S'il y a deux fichiers, un journal de superviseur comprend tous les journaux de configuration/démarrage et un journal de travailleur avec tous les journaux d'analyse/sortie. unified-monitoring-agent.conf est le nom du fichier de configuration s'il a été téléchargé correctement.
- Exécutez Fluentd manuellement. Essayez les étapes précédentes pour identifier le problème, mais si nécessaire, vous pouvez déboguer un problème en exécutant Fluentd manuellement.Note
Exécuter Fluentd manuellement l'exécute dans le service Windows, ce qui empêche le service de s'exécuter normalement. Ce comportement diffère du comportement sous Linux. - Utilisez la commande suivante pour exécuter Fluentd manuellement. Elle peut être exécutée dans PowerShell ou dans l'invite de commande, mais doit être exécutée en tant qu'administrateur :
C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv
Étapes du programme de mise à jour automatique de configuration
- Vérifiez que le Planificateur de tâches s'exécute comme prévu.
- Dans le menu Démarrer, entrez Planificateur de tâches.
- Allez à Planificateur de tâches (Local), puis à Bibliothèque du Planificateur de tâches. Recherchez la tâche nommée UnifiedAgentConfigUpdater.
- Vérifiez l' heure de la dernière exécution. Si la date n'était pas valide ou indique non exécutée, l'heure de la prochaine exécution sera celle à laquelle elle doit être exécutée pour la première fois. Pour le débogage, sélectionnez la tâche et sélectionnez Exécuter si vous souhaitez qu'elle s'exécute immédiatement.
- Résultat de la dernière exécution indique le résultat du téléchargement de la configuration à partir du plan de contrôle. S'il y a une erreur, vous devez l'exécuter manuellement pour déterminer ce qui s'est produit. Le Planificateur de tâches ne conserve pas de journaux de sortie.
- Exécutez le programme de mise à jour de configuration manuellement.Note
Exécutez le programme de mise à jour dans PowerShell en tant qu'administrateur pour obtenir la meilleure expérience.C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\ruby.exe C:\oracle_unified_agent\unified-monitoring-agent\embedded\lib\ruby\gems\2.6.0\gems\fluent-public-config-updater*\lib\fluent_config_updater.rb -c C:\oracle_unified_agent -b 10
Vérifier les journaux de l'agent Oracle Cloud
Pour Windows Server 2012r2 ou 2016, les emplacements des fichiers journaux sont les suivants :
-
C:\Users\OCA\AppData\Local\Local\OracleCloudAgent\agent.log -
C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log(journaux d'exécution) -
C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log(journaux d'installation) -
C:\oracle_unified_agent\unified-monitoring-agent-0.log(journal de travailleur de l'agent, qui n'existe peut-être pas selon l'état) -
C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log(journal de superviseur de l'agent, qui n'existe peut-être pas selon l'état)
Emplacement des fichiers journaux pour Windows Server 2019/2022 :
-
C:\Windows\ServiceProfiles\OCA\AppData\Local\OracleCloudAgent\agent.log -
C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log(journaux d'exécution) -
C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log(journaux d'installation) -
C:\oracle_unified_agent\unified-monitoring-agent-0.log(journal de travailleur de l'agent, qui n'existe peut-être pas selon l'état) -
C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log(journal de superviseur de l'agent, qui n'existe peut-être pas selon l'état)
Échec intermittent d'une installation de MSI
L'échec intermittent d'une installation de MSI peut survenir pour l'une des deux raisons suivantes :
- Une installation de MSI a été interrompue (redémarrage du système, arrêt du processus, etc.) et, lors de la deuxième exécution, le processus msiexec.exe conserve toujours un descripteur de fichier pour un dossier qu'il a créé.
- Lors d'une mise à niveau où MSI ne parvient pas à accéder au dossier de l'agent principal, car Ruby.exe ne se termine pas comme il devrait (problème Fluentd). Cela entraîne l'échec de MSI et le nettoyage du système, en supprimant une grande partie de l'agent (et non la position ou les fichiers tampon).
Dans les deux cas, une deuxième installation ou laisser Oracle Cloud Agent s'exécuter lors de l'installation une deuxième fois résout ce problème. Si cet état persiste , procédez de la façon suivante :
- Arrêtez tous les processus msiexec et ruby dans Gestionnaire des tâches, Détails.
- Renommez C:\oracle_unified_agent en C:\oracle_unified_agent_old.
- Installez de nouveau l'agent ou attendez qu'Oracle Cloud Agent l'installe.
Chemins génériques n'utilisant pas la configuration d'agent
Utilisez une barre oblique (/) lors de la configuration des chemins pour la configuration de l'agent Windows. Une barre oblique inverse (\) avec un astérisque (*) ne fonctionne pas sous Windows en raison de limitations internes. Pour éviter cela, n'utilisez pas de chemin comme C:\\path\\to\\*\\foo.log. Utilisez plutôt la méthode de barre oblique suivante :
path C:/path/to/*/foo.log
Les chemins suivants sont les exemples de chemins de travail génériques pris en charge pour Windows :
-
C:/logs/* -
C:/logs/t2*.txt -
C:/logs/a*b.txt -
C:/logs/abc* -
C:/logs/*.txt -
C:/logs/*/abc* -
C:/logs/*/a.txt -
C:/logs/*/a*b.txt -
C:/logs*/*.txt
Toutefois, le chemin générique C:/logs/*log.txt ne fonctionne pas pour Windows.