Documentation Oracle Cloud Infrastructure

Journalisation des problèmes

Utilisez les informations de dépannage pour identifier et résoudre les problèmes courants qui peuvent survenir lors de l'utilisation de Logging.

Dépannage de l'agent de surveillance unifié général

Configuration matérielle

Selon vos exigences de journalisation et votre configuration (nombre de journaux, type de mise en mémoire tampon, etc.), la configuration matérielle et les performances de l'agent de surveillance unifié 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 RAM et 20 % d'un coeur de processeur. Les limites codées en dur du service Agent de surveillance unifié sont de 5 Go de RAM et de 40 % d'un coeur. Il est par ailleurs recommandé d'utiliser 1 Go de RAM.

Activation de la surveillance

La surveillance peut faciliter le dépannage. Pour plus d'informations sur l'activation de la surveillance (mesures et journalisation) dans vos instances Oracle Cloud Infrastructure Compute, reportez-vous à Activation de la surveillance pour les instances de calcul.

Agent de surveillance unifié Linux

Unités systemd

L'agent de surveillance unifié est basé sur des unités systemd et comprend les composants suivants :

  1. unified-monitoring-agent.service : service principal d'agent de surveillance unifié.
  2. unified-monitoring-agent_config_downloader.service : service de mise à jour automatique de la configuration.
  3. unified-monitoring-agent_config_downloader.timer : unité d'horloge, qui déclenche le service de téléchargement automatique à des intervalles spécifiés et définis de façon aléatoire.
  4. unified-monitoring-agent_restarter.path : unité de chemin, qui déclenche le rechargement de la configuration par l'agent de surveillance unifié, si une modification est détectée (en raison du téléchargement d'une nouvelle configuration par le service de mise à jour automatique).
Remarque

La plupart des commandes systemctl ou journalctl doivent être exécutées avec des privilèges de superutilisateur (en tant que root ou via sudo).

Pour vérifier le bon fonctionnement de ces unités systemd, vous pouvez utiliser la commande systemctl comme suit :

systemctl status <unit_name>

Où <unit_name> doit être remplacé par l'une des valeurs suivantes :

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path

Généralement, ces commandes systemctl affichent une sortie semblable à 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 la commande systemctl sont les champs Loaded et Active. Le champ Loaded contient la valeur loaded pour toutes les unités système. Le champ Active a les valeurs suivantes :

  • active (running) pour l'unité unified-monitoring-agent.service.
  • active (waiting) ou active (running) pour les unités unified-monitoring-agent_restarter.path et unified-monitoring-agent_config_downloader.timer.
  • active (running) ou inactive (dead) pour l'unité unified-monitoring-agent_config_downloader.service. Pour cette dernière valeur, le champ Main PID comporte la valeur code=exited, status=0/SUCCESS).

Vérifier les processus en cours

Une autre façon de vérifier le bon fonctionnement de l'agent de surveillance unifié consiste à vérifier les processus en cours d'exécution du système. Lorsqu'il fonctionne correctement, l'agent de surveillance unifié exécute deux processus : un processus superviseur et un processus actif. 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 sont en cours d'exécution, avec les mêmes arguments, à l'exception du paramètre –under-supervisor supplémentaire ajouté au second. Ce paramètre permet de déterminer un processus actif. Le processus auquel n'a pas été attribué ce paramètre correspond ainsi au processus superviseur.

Emplacement du journal d'agent de surveillance unifiée

Remarque

La plupart des commandes systemctl ou journalctl doivent être exécutées avec des privilèges de superutilisateur (en tant que root ou via sudo).

Les journaux d'agent de surveillance unifié sont disponibles sous /var/log/unified-monitoring-agent/unified-monitoring-agent.log. Ce fichier inclut les journaux de l'agent de surveillance unifié lui-même.

Outre les journaux de l'agent, qui ne contiennent pas d'événements liés au système (par exemple, démarrage du service, arrêt du service, etc.), vous pouvez également visualiser les journaux du service de journalisation système journald, systemd. Pour afficher les journaux système propres à une unité, vous pouvez utiliser la commande journalctl comme suit :

journalctl -u <unit_name>

Où <unit_name> doit être remplacé par l'une des valeurs suivantes :

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path
Lors de l'interrogation des journaux journald via journalctl, vous pouvez également définir des périodes spécifiques : 
journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"
Le format de date utilisé est le suivant : YYYY-MM-DD HH:MM:SS.
Vous pouvez également personnaliser les journaux en ajoutant le paramètre -f : 
journalctl -f

L'agent de surveillance unifié n'est pas installé

Pour les nouvelles instances, l'installation automatique de l'agent peut prendre 25 minutes. S'il n'est pas installé après cette période, vérifiez les points suivants :

  1. connectivité réseau de l'instance ;
  2. activation ou non de la surveillance dans la console.

Vous pouvez également consulter le fichier journal /var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.log pour plus d'informations sur l'installation de l'agent de surveillance unifié par l'agent Oracle Cloud.

L'agent de surveillance unifié n'est pas en cours d'exécution

Si le statut n'est pas chargé ou actif et que les processus superviseur et de processus actifs ne sont pas en cours d'exécution, redémarrez l'agent de surveillance unifié et recherchez les problèmes dans les journaux : 

systemctl restart unified-monitoring-agent

Configuration non téléchargée automatiquement

Assurez-vous d'avoir suivi les étapes décrites dans les sections Installing the Agent et Verify Agent Installation. Consultez le journal du service de mise à jour automatique de la configuration en exécutant : 

journalctl -u unified-monitoring-agent_config_downloader.service

Configuration non automatiquement rechargée

Assurez-vous d'avoir suivi les étapes décrites dans les sections Installing the Agent et Verify Agent Installation. Consultez le journal de toutes les unités :

  1. L'unité d'horloge doit avoir été exécutée au moins une fois.
  2. Le service de téléchargement de configuration automatique doit être exécuté après le déclenchement de l'unité de temps appropriée. Dans ses journaux, vous pouvez vérifier que la configuration a été téléchargée et extraite vers le répertoire de configuration de l'agent de surveillance unifié. Vous pouvez également le vérifier en répertoriant les fichiers dans ce répertoire : ls -lhatR /etc/unified-monitoring-agent.
  3. Vérifiez que l'unité de chemin est active en vérifiant son statut : systemctl status unified-monitoring-agent_restarter.path.
  4. Vérifiez que l'agent de surveillance unifié a reçu un signal de rechargement, en examinant son journal : journalctl -u unified-monitoring-agent_config_downloader.service. "Reloading 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
Remarque

La mise à jour automatique de la configuration côté agent peut prendre jusqu'à 30 minutes.

Création d'un journal personnalisé pour afficher le contenu d'un journal d'alertes d'un système de base de données à l'aide d'OCI

L'agent de surveillance unifié ne prend pas en charge le système de base de données.

Collecte de données

Si vous souhaitez ouvrir un ticket pour qu'un ingénieur puisse vous aider à résoudre votre problème concernant l'agent de surveillance unifié, incluez la sortie des commandes suivantes. Certains d'entre eux peuvent avoir besoin de privilèges de superutilisateur.

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 semblable à la suivante :

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.gz de ces répertoires à l'aide de la commande suivante :

tar cvzf agent_logs_$(date +%s).tar.gz /var/log/unified-monitoring-agent/ /var/log/oracle-cloud-agent/

Si l'agent de surveillance unifié est en cours d'exécution mais qu'il présente un comportement irrégulier, vous pouvez également inclure des informations de profil de mémoire et de trace, 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 PID du processus de l'agent de surveillance unifié et de leur envoyer le signal SIGCONT, ce qui entraîne la génération d'un vidage dans /tmp/sigdump-<integer>.log.

Désinstallation et réinstallation

Vous pouvez enlever l'agent de surveillance unifié, sans enlever 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 sous le répertoire /etc/unified-monitoring-agent/. Si vous ne souhaitez pas conserver la configuration pour une future (ré)installation du package de l'agent de surveillance unifié, vous devez l'enlever 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 Oracle Cloud réinstalle automatiquement l'agent au bout de 25 minutes au maximum. Pour ce faire, la surveillance doit être activée pour votre instance dans la console. Pour plus d'informations, reportez-vous à Agent Oracle Cloud.

Agent de surveillance unifié Windows

Pour vérifier le statut du service

  1. L'agent est exécuté dans le cadre d'un service Windows. Pour consulter son statut, ouvrez le menu Démarrer, saisissez Services.msc et ouvrez-le. Accédez au service Oracle Cloud Unified Monitoring pour voir le statut.
  2. Cliquez avec le bouton droit de la souris sur le service et sélectionnez Propriétés pour plus d'informations. Le démarrage/l'arrêt/le redémarrage sont disponibles à cet endroit.
  3. Dans le menu Démarrer, saisissez cmd, cliquez avec le bouton droit de la souris sur Invite de commandes et sélectionnez Exécuter en tant qu'administrateur. Exécutez les commandes suivantes :
  • Pour afficher le statut du service Agent de surveillance unifié, procédez comme suit :
    sc query unified-monitoring-agent
  • Redémarrez le service Agent de surveillance unifié :
    sc stop unified-monitoring-agent
sc start unified-monitoring-agent
Remarque

Les commandes précédentes ne fonctionnent pas dans PowerShell. Vous devez donc utiliser l'invite de commande Windows.

Pour rechercher des erreurs de service Windows

  1. Dans le menu Démarrer, saisissez Observateur d'événements et sélectionnez-le.
  2. Ouvrez Journaux Windows, puis Système. Chaque fois qu'un service démarre ou s'arrête, qu'il échoue ou qu'il tombe soudainement en panne, il est enregistré ici.
    Remarque

    Sur la plupart des ordinateurs Windows, le nombre d'événements pouvant figurer 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 visualiser des journaux Fluentd

  1. Ouvrez explorer.exe (icône de fichier dans la barre des tâches).
  2. Accédez à C:\oracle_unified_agent.
  3. S'il n'y a qu'un seul fichier, cela signifie qu'il n'existe aucun fichier de configuration valide sur l'ordinateur.
  4. S'il existe deux fichiers, un journal de processus superviseur contient tous les journaux de configuration/démarrage et un journal de processus actif avec tous les journaux d'analyse/de sortie. S'il a été téléchargé correctement, le fichier de configuration s'intitule unified-monitoring-agent.conf.
  5. Exécutez Fluentd manuellement. Essayez de suivre 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.
    Remarque

    L'exécution de Fluentd s'effectue manuellement dans le service Windows, ce qui empêche le service de fonctionner normalement. Il s'agit d'un comportement différent de celui observé sur Linux.
  6. Utilisez la commande suivante pour exécuter Fluentd manuellement. Elle peut être exécutée dans PowerShell ou l'invite de commande, mais uniquement en tant qu'administrateur :
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv

Etapes de mise à jour automatique de la configuration

  1. Vérifiez que le planificateur de tâches est exécuté comme prévu.
  2. Dans le menu Démarrer, saisissez Planificateur de tâches.
  3. Accédez à Planificateur de tâches (local), puis à Bibliothèque du Planificateur de tâches. Recherchez la tâche nommée UnifiedAgentConfigUpdater.
  4. Vérifiez l'heure de la dernière exécution. Si la date n'était pas valide ou qu'elle indique non exécuté, l'heure de la prochaine exécution correspond à la première exécution. Pour le débogage, sélectionnez la tâche, puis cliquez sur Exécuter si vous souhaitez l'exécuter immédiatement.
  5. 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. En cas d'erreur, vous devez l'exécuter manuellement pour déterminer ce qu'il s'est passé. Le planificateur de tâches ne conserve pas les journaux de sortie.
  6. Exécutez manuellement le programme de mise à jour de la configuration.
    Remarque

    Pour une expérience optimale, exécutez le programme de mise à jour dans PowerShell en tant qu'administrateur.
    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érification des journaux d'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 du processus actif d'agent, qui peut ne pas exister en fonction de l'état)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (journal de processus superviseur d'agent, qui peut ne pas exister en fonction de l'état)

Emplacement des fichiers journaux 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 du processus actif d'agent, qui peut ne pas exister en fonction de l'état)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (journal de processus superviseur d'agent, qui peut ne pas exister en fonction de l'état)

Echec intermittent de l'installation de MSI

L'installation de MSI peut échouer de manière intermittente pour l'une des deux raisons suivantes :

  1. L'installation de MSI a été interrompue (redémarrage du système, arrêt du processus, etc.), et lors de la deuxième tentative, le processus msiexec.exe conserve toujours un descripteur de fichier dans un dossier qu'il a créé.
  2. Lors d'une mise à niveau où MSI ne parvient pas à accéder au dossier de l'agent principal, car le fichier Ruby.exe ne se termine pas comme il le devrait (problème de Fluentd). Cela entraîne l'échec de MSI, le nettoyage du système et, par conséquent, la suppression d'une grande partie de l'agent. Les fichiers de position ou tampon sont toutefois conservés.

Dans les deux cas, une seconde installation ou l'autorisation de l'exécution de l'agent Oracle Cloud via une seconde installation permet de résoudre le problème. S'il est toujours bloqué dans cet état, procédez comme suit :

  1. Arrêtez tous les processus msiexec et ruby dans les détails du Gestionnaire des tâches.
  2. Renommez C:\oracle_unified_agent en C:\oracle_unified_agent_old.
  3. Installez à nouveau l'agent ou attendez que l'agent Oracle Cloud l'installe.

Chemins génériques ne fonctionnant pas avec 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 tel que C:\\path\\to\\*\\foo.log. Utilisez plutôt la méthode de barre oblique suivante :

path C:/path/to/*/foo.log

Les chemins d'accès génériques pris en charge pour Windows sont les suivants :

  • 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

Cependant, le chemin générique C:/logs/*log.txt ne fonctionne pas pour Windows.