Solución de problemas de registro

Utilice la información de resolución de problemas para identificar y abordar problemas comunes que se pueden producir al trabajar con Logging.

Solución de problemas general de Unified Monitoring Agent

Requisitos de hardware

Según los requisitos de registro y la configuración (número de logs, tipo de almacenamiento en buffer, etc.), los requisitos de hardware y el rendimiento de Unified Monitoring Agent pueden variar mucho. Cuando no hay presión operativa (menos de 1000 eventos de log por minuto), el agente no debe consumir más de 200 MB de RAM y el 20 % de un núcleo de CPU. Los límites de codificación fija del servicio Unified Monitoring Agent son de 5 GB de RAM y el 40 % de un núcleo. También se recomienda 1 GB de RAM.

Activación de supervisión

La supervisión puede ayudar con la solución de problemas. Consulte Activación de la supervisión para instancias de Compute para obtener más información sobre cómo activar la supervisión (métricas y registro) en las instancias de Oracle Cloud Infrastructure Compute.

Unified Monitoring Agent de Linux

Unidades systemd

Unified Monitoring Agent se basa en unidades systemd y se compone de los siguientes componentes:

  1. unified-monitoring-agent.service: servicio principal de Unified Monitoring Agent.
  2. unified-monitoring-agent_config_downloader.service: Servicio de actualizador automático de configuración.
  3. unified-monitoring-agent_config_downloader.timer: Unidad de temporizador que dispara el servicio de descargador automático en intervalos aleatorios especificados.
  4. unified-monitoring-agent_restarter.path: unidad de ruta, que dispara la recarga de la configuración por parte de Unified Monitoring Agent si se detecta un cambio (debido a una nueva configuración que se esté descargando el servicio de actualizador automático).
Nota

La mayoría de los comandos systemctl o journalctl se deben ejecutar con privilegios de superusuario (como root o mediante sudo).

Para verificar el funcionamiento correcto de estas unidades systemd, puede utilizar el comando systemctl como el siguiente:

systemctl status <unit_name>

Donde <unit_name> debe sustituirse por uno de los siguientes valores:

  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

Normalmente, estos comandos systemctl muestran una salida similar a la siguiente:

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 

Las partes más importantes de la salida del comando systemctl son los campos Loaded y Active. El campo Loaded tiene el valor loaded para todas las unidades del sistema. El campo Active tiene los siguientes valores:

  • active (running) para la unidad unified-monitoring-agent.service.
  • active (waiting) o active (running) para las unidades unified-monitoring-agent_restarter.path y unified-monitoring-agent_config_downloader.timer.
  • active (running) o inactive (dead) para la unidad unified-monitoring-agent_config_downloader.service. Para este último valor, el campo Main PID incluye el valor code=exited, status=0/SUCCESS).

Comprobar procesos en ejecución

Otra forma de verificar aún más el funcionamiento correcto de Unified Monitoring Agent es comprobar los procesos en ejecución del sistema. Cuando funciona correctamente, el Unified Monitoring Agent ejecuta dos procesos: un proceso de supervisor y un proceso de trabajador. Puede verificar su existencia ejecutando el siguiente comando en un terminal (ejemplo de salida incluido):

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

Como se muestra en el ejemplo anterior, hay dos procesos en ejecución, con los mismos argumentos, excepto el –under-supervisor adicional agregado al segundo. Esto indica el proceso de trabajador, lo que convierte el proceso sin este parámetro en el supervisor.

Ubicación del log de Unified Monitoring Agent

Nota

La mayoría de los comandos systemctl o journalctl se deben ejecutar con privilegios de superusuario (como root o mediante sudo).

Los logs de Unified Monitoring Agent están disponibles en /var/log/unified-monitoring-agent/unified-monitoring-agent.log. Este archivo incluye logs del propio Unified Monitoring Agent.

Además de los logs del agente, que no contienen eventos relacionados con el sistema (por ejemplo, inicio del servicio, parada del servicio, etc.), también puede ver los logs de journald, el servicio de registro del sistema de systemd. Para ver los logs del sistema específicos de una unidad, puede utilizar el comando journalctl como el siguiente:

journalctl -u <unit_name>

Donde <unit_name> debe sustituirse por uno de los siguientes valores:

  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
Al consultar los logs de journald mediante journalctl, también puede definir rangos de tiempo específicos:
journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"
El formato de fecha utilizado es AAAA-MM-DD HH:MM:SS.
También puede adaptar los logs de registro agregando el parámetro -f:
journalctl -f

El Unified Monitoring Agent no está instalado

Para las instancias recién creadas, la instalación automática del agente puede tardar hasta 25 minutos. Si no se instala después de este período de tiempo, compruebe lo siguiente:

  1. La conectividad de red de la instancia.
  2. Si la supervisión está activada en la consola.

También puede consultar el archivo log /var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.log para obtener información sobre la instalación de Unified Monitoring Agent por parte del Oracle Cloud Agent.

Unified Monitoring Agent no se está ejecutando

Si el estado no está cargado ni activo, ni se están ejecutando los procesos de supervisor y trabajador, reinicie Unified Monitoring Agent y compruebe si hay problemas en los logs:

systemctl restart unified-monitoring-agent

Configuración no descargada automáticamente

Asegúrese de que ha seguido los pasos descritos en Installing the Agent y Verify Agent Installation. Consulte el registro del servicio de actualizador automático de configuración ejecutando:

journalctl -u unified-monitoring-agent_config_downloader.service

Configuración no recargada automáticamente

Asegúrese de que ha seguido los pasos descritos en Installing the Agent y Verify Agent Installation. Consulte el registro de todas las unidades:

  1. La unidad de temporizador debe haberse ejecutado al menos una vez.
  2. El servicio de descarga de configuración automática debe haberse ejecutado después de que la unidad de tiempo correspondiente lo haya disparado. Puede verificar en sus logs que la configuración se ha descargado y extraído en el directorio de configuración de Unified Monitoring Agent. También puede verificarlo mostrando los archivos de ese directorio: ls -lhatR /etc/unified-monitoring-agent.
  3. Verifique que la unidad de la ruta esté activa comprobando su estado: systemctl status unified-monitoring-agent_restarter.path.
  4. Verifique que Unified Monitoring Agent haya recibido una señal de recarga mediante la inspección de su registro: journalctl -u unified-monitoring-agent_config_downloader.service. "Reloading unified-monitoring-agent" aparece en la salida de este comando.

Probar patrón de análisis y forzar al agente a descargar inmediatamente la configuración

Ejecute el siguiente comando:

systemctl restart unified-monitoring-agent_config_downloader
Nota

La actualización automática de la configuración en el agente puede tardar hasta 30 minutos.

Fallo en la configuración del agente para la instancia de Linux

Se puede producir un fallo si la configuración que utiliza el punto final de Windows aparece en una instancia de Linux, ya que Fluentd en Linux no soporta el plugin de Windows y fallará tras la inicialización. La causa de esto suele ser que el cliente ha configurado una configuración de agente de Windows y la ha asignado al mismo grupo dinámico que también tiene una configuración de instancia de Linux. Esta configuración no está soportada. Las instancias de Linux y Windows necesitan sus propios grupos dinámicos.

Creación de un log personalizado para ver el contenido de un log de alertas de un sistema de base de datos mediante OCI

Unified Monitoring Agent no soporta el sistema de base de datos.

Recopilación de datos

Si desea abrir un ticket para que un ingeniero pueda ayudarle con su problema relacionado con Unified Monitoring Agent, incluya la salida de los siguientes comandos. Es posible que se necesiten privilegios de superusuario para algunos de ellos.

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

Para Ubuntu, utilice un comando como el siguiente:

apt show unified-monitoring-agent
dpkg -L unified-monitoring-agent | xargs sha512sum

Incluya también un archivo de los archivos ubicados en /var/log/unified-monitoring-agent/ y /var/log/oracle-cloud-agent/. Puede crear un archivo tar gzip de estos directorios con el comando:

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

Si Unified Monitoring Agent se está ejecutando pero tiene un comportamiento errático, también puede incluir información de rastreo inverso y de perfil de memoria ejecutando el siguiente comando e incluyendo los archivos /tmp/sigdump-<integer>.log en el informe (donde <integer> es un entero con 1-6 dígitos, aunque en raras ocasiones puede tener más).

ps aux | grep unified-monitoring-agen[t] | grep ruby | awk '{print $2}' | xargs kill -SIGCONT

Lo que hace este comando es buscar los PID de proceso de Unified Monitoring Agent y enviarlos a la señal SIGCONT, lo que provoca que se genere un volcado en /tmp/sigdump-<integer>.log.

Desinstalación y reinstalación

Puede eliminar Unified Monitoring Agent sin eliminar la configuración de agente mediante la ejecución del siguiente comando:

yum -y remove unified-monitoring-agent

Para Ubuntu:

apt -y remove unified-monitoring-agent

La configuración del agente permanece en el directorio /etc/unified-monitoring-agent/. Si no desea mantener la configuración para una futura reinstalación del paquete Unified Monitoring Agent, debe eliminarla manualmente:

# 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/

Oracle Cloud vuelve a instalar automáticamente el agente como máximo en 25 minutos. Para que esto ocurra, debe tener activada la supervisión para su instancia en la consola. Consulte Oracle Cloud Agent para obtener más información.

Unified Monitoring Agent de Windows

Para comprobar el estado del servicio

  1. El agente se ejecuta como parte de un servicio de Windows. Para ver su estado, abra el menú de inicio, escriba Services.msc y ábralo. Vaya al servicio Oracle Cloud Unified Monitoring Service para ver el estado.
  2. Haga clic con el botón derecho en el servicio y seleccione Propiedades para obtener más información. Las opciones Iniciar/Parar/Reiniciar están disponibles aquí.
  3. En el menú Inicio, escriba cmd, haga clic con el botón derecho en Símbolo del sistema y seleccione Ejecutar como administrador. Ejecute los siguientes comandos:
  • Para ver el estado del servicio Unified Monitoring Agent:
    sc query unified-monitoring-agent
  • Reinicie el servicio Unified Monitoring Agent:
    sc stop unified-monitoring-agent
    sc start unified-monitoring-agent
Nota

Los comandos anteriores no funcionan en PowerShell, por lo que debe usar el símbolo del sistema de Windows.

Para buscar errores del servicio de Windows

  1. En el menú Inicio, escriba Visor de eventos y selecciónelo.
  2. Abra Registros de Windows y, a continuación, Sistema. Cada vez que un servicio se inicia o se detiene, falla al realizar alguna de estas acciones o se bloquea de forma repentina , queda registrado aquí.
    Nota

    En la mayoría de las máquinas Windows, hay un límite en cuanto al número de eventos que pueden estar en el visor de eventos. Por ello, si un evento ocurrió mucho tiempo, es posible que los logs no estén disponibles.

Para ver logs de Fluentd

  1. Abra explorer.exe (icono de archivo en la barra de tareas)
  2. Vaya a C:\oracle_unified_agent.
  3. Si solo hay un archivo, significa que no hay un archivo de configuración válido en la máquina.
  4. Si hay dos archivos, hay un log de supervisor que tendrá todos los logs de configuración/inicio y un log worker con todos los logs de análisis/salida. unified-monitoring-agent.conf es el nombre del archivo de configuración si se ha descargado correctamente.
  5. Ejecute Fluentd de forma manual. Pruebe los pasos anteriores para identificar la incidencia, pero si es necesario, puede depurar una incidencia ejecutando Fluentd de forma manual.
    Nota

    La ejecución manual de Fluentd lo ejecuta en el servicio de Windows, lo cual impide que el servicio se ejecute de forma normal. Este comportamiento es diferente en Linux.
  6. Utilice el siguiente comando para ejecutar Fluentd manualmente. Se puede ejecutar en PowerShell o en el símbolo del sistema, pero se debe ejecutar como administrador:
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv

Pasos del Actualizador de Configuración Automática

  1. Verifique que el programador de tareas se está ejecutando de la forma esperada.
  2. En el menú Inicio, escriba Programador de tareas.
  3. Vaya a Programador de tareas (locales) y, a continuación, a Biblioteca del programador de tareas. Busque la tarea denominada UnifiedAgentConfigUpdater.
  4. Verifique el Hora de última ejecución. Si es una fecha no válida o indica No realizada, la hora de siguiente ejecución será cuando se ejecute por primera vez. Para la depuración, seleccione la tarea y seleccione Ejecutar si necesita que se ejecute se inmediato.
  5. Resultado de última ejecución especifica el resultado de la descarga de la configuración desde el plano de control. Si hay un resultado de error, debe ejecutarla manualmente para determinar lo que ha sucedido. El programador de tareas no conserva los logs de salida.
  6. Ejecute el actualizador de configuración manualmente.
    Nota

    Ejecute el actualizador en PowerShell como administrador para obtener la mejor experiencia.
    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

Comprobar logs de Oracle Cloud Agent

Para Windows Server 2012r2 o 2016, las ubicaciones de los archivos log son:

  • C:\Users\OCA\AppData\Local\Local\OracleCloudAgent\agent.log
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (logs de tiempo de ejecución)
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (logs de instalación)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (log de trabajador de agente, que puede que no exista según el estado)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (registro de supervisor de agente, que puede que no exista según el estado)

Ubicaciones de archivos log de Windows Server 2019:

  • C:\Windows\ServiceProfiles\OCA\AppData\Local\OracleCloudAgent\agent.log
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (logs de tiempo de ejecución)
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (logs de instalación)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (log de trabajador de agente, que puede que no exista según el estado)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (log de supervisor de agente, que puede que no exista según el estado)

Instalación de MSI con fallos intermitente

Una instalación de MSI con fallos intermitente puede producirse por uno de estos dos motivos:

  1. Se ha interrumpido una instalación MSI (reinicio del sistema, parada del proceso, etc.) y, en la segunda ejecución, el proceso msiexec.exe sigue manteniendo un manejador de archivos en una carpeta que ha creado.
  2. Durante un cambio de versión en el que el MSI no puede acceder a la carpeta del agente principal, porque Ruby.exe no termina como debería (incidencia de Fluentd). Esto hace que el MSI falle y limpie el sistema, eliminando gran parte del agente (excepto los archivos de posición y de buffer).

En ambas instancias, una segunda instalación o dejar que Oracle Cloud Agent ejecute la instalación por segunda vez resolverá esta incidencia. Si sigue atascado en este estado, realice lo siguiente:

  1. Detenga todos los procesos msiexec y ruby en Administrador de tareas, Detalles.
  2. Cambie el nombre de C:\oracle_unified_agent a C:\oracle_unified_agent_old.
  3. Vuelva a instalar el agente o espere a que Oracle Cloud Agent lo instale.

Rutas genéricas que no funcionan con la configuración de agente

Utilice una barra inclinada (/) al configurar rutas para la configuración del agente de Windows. Una barra invertida (\) con un asterisco (*) no funciona en Windows debido a limitaciones internas. Para evitarlo, no utilice una ruta de acceso como C:\\path\\to\\*\\foo.log. En su lugar, utilice el siguiente método de barra inclinada:

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

Las siguientes rutas son los ejemplos de rutas de trabajo genéricas soportadas para 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

Sin embargo, la ruta genérica C:/logs/*log.txt no funciona para Windows.