Compartir a través de

Cómo solucionar problemas relacionados con el agente de Log Analytics para Linux

  • Artículo

En este artículo se proporciona información sobre los errores que se pueden producir con el agente de Log Analytics para Linux en Azure Monitor.

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux con un estado de finalización del servicio (EOL). Tenga en cuenta su uso y planeación en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida de CentOS.

Herramienta de solución de problemas de Log Analytics

La Herramienta de solución de problemas del agente de Log Analytics para Linux es un script diseñado para ayudar a encontrar y diagnosticar incidencias con el agente de Log Analytics. Se incluye automáticamente con el agente en la instalación. La ejecución de la herramienta debe ser el primer paso para diagnosticar un problema.

Uso de la herramienta de solución de problemas

Para ejecutar la herramienta de solución de problemas, pegue el siguiente comando en una ventana de terminal en una máquina con el agente de Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Instalación manual

La herramienta de solución de problemas se incluye automáticamente al instalar el agente de Log Analytics. Si se produce un error de cualquier tipo en la instalación, también puede instalar la herramienta manualmente:

  1. Asegúrese de que el Depurador de proyectos de GNU (GDB) está instalado en la máquina, ya que el solucionador de problemas depende de él.
  2. Copie el paquete del solucionador de problemas en el equipo: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Desempaquete el paquete: tar -xzvf omsagent_tst.tar.gz
  4. Ejecute la instalación manual: sudo ./install_tst

Escenarios descritos

La herramienta de solución de problemas comprueba los siguientes escenarios:

  • El agente tiene un estado incorrecto, el latido no funciona correctamente.
  • El agente no se inicia o no se puede conectar a Log Analytics.
  • El Syslog del agente no funciona.
  • El agente tiene un uso elevado de CPU o de memoria.
  • El agente tiene incidencias de instalación.
  • Los registros personalizados del agente no funcionan.
  • No se pueden recopilar los registros del agente.

Para obtener más información, consulte la documentación de la Herramienta de solución de problemas en GitHub.

Nota

Ejecute la herramienta Recopilador de registros cuando experimente un problema. Disponer inicialmente de los registros ayudará a nuestro equipo de soporte técnico a solucionar la incidencia más rápido.

Purga y reinstalación del agente de Linux

Una reinstalación limpia del agente corrige la mayoría de las incidencias. Esta tarea puede ser la primera sugerencia de nuestro equipo de soporte técnico para llevar al agente a un estado no corrompido. Ejecutar la herramienta de solución de problemas y la herramienta de recopilador de registros e intentar una reinstalación limpia ayuda a resolver incidencias más rápidamente.

  1. Descargue el script de purga:

    $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

  2. Ejecute el script de purga (con permisos sudo):

    $ sudo sh purge_omsagent.sh

Ubicaciones de registro importantes y herramienta de recopilador de registros

Archivo Path
Archivo de registro del agente de Log Analytics para Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Archivo de registro de configuración del agente de Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Se recomienda usar la herramienta Recopilador de registros para recuperar registros importantes para solucionar problemas o antes de enviar una incidencia de GitHub. Para obtener más información sobre la herramienta y cómo ejecutarla, consulte Log Collector de agente para Linux de OMS.

Archivos de configuración importantes

Category Ubicación del archivo
syslog /etc/syslog-ng/syslog-ng.conf, /etc/rsyslog.conf o /etc/rsyslog.d/95-omsagent.conf
Rendimiento, Nagios, Zabbix, salida de Log Analytics y agente general /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Configuraciones adicionales /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Nota

La edición de los archivos de configuración para los contadores de rendimiento y Syslog se sobrescribe si la colección se configura desde la configuración de agente en el Azure Portal para su área de trabajo. Para desactivar la configuración para todos los agentes, deshabilite la recopilación desde la Administración de agentes antiguos. Para un único agente, ejecute el siguiente script:

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

Códigos de error de instalación

Código de error Significado
NOT_DEFINED Dado que las dependencias necesarias no están instaladas, no se instalará el complemento de auoms auditd. Error en la instalación de auoms. Instale el paquete auditd.
2 Opción no válida proporcionada a la agrupación de shell. Ejecute sudo sh ./omsagent-*.universal*.sh --help para el uso.
3 Ninguna opción proporcionada a la agrupación de shell. Ejecute sudo sh ./omsagent-*.universal*.sh --help para el uso.
4 Tipo de paquete no válido o configuración de proxy no válida. Los paquetes omsagent-rpm.sh solo se pueden instalar en sistemas basados en RPM. Los paquetes omsagent-deb.sh solo se pueden instalar en sistemas basados en Debian. Recomendamos que use el instalador universal desde la versión más reciente. Además, revise para comprobar la configuración de proxy.
5 La agrupación de shell se debe ejecutar como raíz or se devolvió un error 403 durante la incorporación. Ejecute el comando mediante sudo.
6 Arquitectura de paquetes no válida o se devolvió un error 200 durante la incorporación. Los paquetes omsagent-*x64.sh solo se pueden instalar en sistemas de 64 bits. Los paquetes omsagent-*x86.sh solo se pueden instalar en sistemas de 32 bits. Descargue el paquete correcto para su arquitectura de la versión más reciente.
17 No se pudo instalar el paquete de OMS. Examine el resultado del comando para conocer el error raíz.
18 Error en la instalación del paquete OMSConfig. Examine el resultado del comando para conocer el error raíz.
19 No se pudo instalar el paquete de OMI. Examine el resultado del comando para conocer el error raíz.
20 No se pudo instalar el paquete de SCX. Examine el resultado del comando para conocer el error raíz.
21 No se pudieron instalar los kits del proveedor. Examine el resultado del comando para conocer el error raíz.
22 No se pudo instalar el paquete integrado. Examine el resultado del comando para conocer el error raíz
23 El paquete de SCX u OMI ya está instalado. Use --upgrade en lugar de --install para instalar la agrupación de shell.
30 Error de agrupación interno. Registre una incidencia de GitHub con los detalles del resultado.
55 Versión de openssl no compatible or no se puede conectar con Azure Monitor or dpkg está bloqueado or falta el programa curl.
61 Falta la biblioteca ctypes de Python. Instale la biblioteca ctypes de Python o el paquete (python-ctypes).
62 Falta el programa tar. Instale tar.
63 Falta el programa sed. Instale sed.
64 Falta el programa curl. Instale curl.
65 Falta el programa gpg. Instale gpg.

Códigos de error de incorporación

Código de error Significado
2 Opción no válida proporcionada al script omsadmin. Ejecute sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h para el uso.
3 Configuración no válida proporcionada al script omsadmin. Ejecute sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h para el uso.
4 Proxy no válido proporcionado al script omsadmin. Compruebe el proxy y consulte nuestra documentación para usar un proxy HTTP.
5 Error HTTP 403 recibido de Azure Monitor. Vea el resultado completo del script omsadmin para obtener más información.
6 Error HTTP distinto de 200 recibido de Azure Monitor. Vea el resultado completo del script omsadmin para obtener más información.
7 No se puede conectar a Azure Monitor. Vea el resultado completo del script omsadmin para obtener más información.
8 Error en la incorporación al área de trabajo de Log Analytics. Vea el resultado completo del script omsadmin para obtener más información.
30 Error interno de script. Registre una incidencia de GitHub con los detalles del resultado.
31 Error al generar identificador de agente. Registre una incidencia de GitHub con los detalles del resultado.
32 Error al generar los certificados. Vea el resultado completo del script omsadmin para obtener más información.
33 Error al generar la metaconfiguración para omsconfig. Registre una incidencia de GitHub con los detalles del resultado.
34 El script de generación de la metaconfiguración no está presente. Vuelva a intentar la incorporación con sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Habilitación del registro de depuración

Depuración del complemento de salida de OMS

FluentD permite niveles de registro específicos de complemento, lo que permite especificar distintos niveles de registro para entradas y salidas. Para especificar un nivel de registro distinto para la salida de OMS, edite la configuración del agente general en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

En el complemento de salida de OMS, antes del final del archivo de configuración, cambie la propiedad log_level de info a debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

El registro de depuración permite ver cargas por lotes a Azure Monitor separadas por tipo, número de elementos de datos y tiempo de envío.

Este es un ejemplo de registro habilitado para depuración:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

Salida detallada

En lugar de usar el complemento de salida de OMS, también puede generar la salida de elementos de datos directamente a stdout, que es visible en el archivo de registro del agente de Log Analytics para Linux.

En el archivo de configuración del agente general de Log Analytics en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, convierta en comentario el complemento de salida de OMS agregando un # al principio de cada línea:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

Debajo del complemento de salida, quite la marca de comentario de la siguiente sección quitando el # delante de cada línea:

<match **>
  type stdout
</match>

Problema: No es posible establecer la conexión a través del proxy a Azure Monitor.

Causas probables

  • El proxy especificado durante la incorporación era incorrecto.
  • Los puntos de conexión de servicio de Azure Monitor y Azure Automation no están en la lista de permitidos en el centro de datos.

Solución

  1. Vuelva a incorporase a Azure Monitor con el agente de Log Analytics para Linux mediante el siguiente comando con la opción -v habilitada. Así se permite una salida detallada del agente que se conecta a través del proxy a Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Revise la sección Actualizar la configuración de proxy para comprobar que ha configurado correctamente el agente para comunicarse a través de un servidor proxy.

  3. Asegúrese de que los puntos de conexión descritos en la lista de requisitos de firewall de red de Azure Monitor se agregan correctamente a una lista de permitidos. Si usa Azure Automation, en el vínculo anterior también se incluyen los pasos de configuración de red necesarios.

Problema: Recibe un error 403 al intentar incorporarse

Causas probables

  • La fecha y la hora son incorrectas en el servidor Linux.
  • El id. del área de trabajo y la clave del área de trabajo no son correctos.

Solución

  1. Compruebe la hora en el servidor Linux con el comando date. Si la hora es +/-15 minutos de la hora actual, se produce un error en la incorporación. Para corregir este problema, actualice la fecha o la zona horaria del servidor Linux.
  2. Compruebe que ha instalado la versión más reciente del agente de Log Analytics para Linux. La versión más reciente notifica ahora si el desfase temporal está causando el error de incorporación.
  3. Vuelva a realizar la incorporación mediante el id. de área de trabajo y la clave de área de trabajo correctos según las instrucciones de instalación de este artículo.

Problema: Ve los errores 404 y 500 en el archivo de registro justo después de la incorporación

Se trata de una incidencia conocida que se produce con la primera carga de datos de Linux en un área de trabajo de Log Analytics. Esto no afecta a los datos que se envían ni a la experiencia del servicio.

Problema: Se indica el proceso omiagent usa el 100 % de la CPU

Causas probables

Una regresión en el paquete nss-pem v1.0.3-5.el7 causaba una incidencia de rendimiento grave. Hemos estado viendo que este problema aparece mucho en las distribuciones de Redhat/CentOS 7.x. Para obtener más información sobre esta incidencia, consulte 1667121 Regresión de rendimiento en libcurl.

Los errores relacionados con el rendimiento no se producen constantemente y son difíciles de reproducir. Si experimenta esta incidencia con omiagent, use el script omiHighCPUDiagnostics.sh, que recopilará el seguimiento de pila del omiagent cuando se supere un umbral determinado.

  1. Descargue el script:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Ejecute el diagnóstico durante 24 horas con un umbral de la CPU del 30 %:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. La pila de llamadas se volcará en el archivo omiagent_trace. Si nota muchas llamadas de función de curl y NSS, siga estas etapas de resolución.

Solución

  1. Actualice el paquete nss-pem a v1.0.3 5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Si nss-pem no está disponible para la actualización, lo que sucede principalmente en CentOS, cambie a una versión anterior de curl, 7.29.0-46. Si por error ejecuta "yum update", curl se actualizará a la versión 7.29.0-51 y volverá a producirse la incidencia:
    sudo yum downgrade curl libcurl

  3. Reinicie OMI:
    sudo scxadmin -restart

Problema: No ve los mensajes de Syslog reenviados

Causas probables

  • La configuración aplicada al servidor Linux no permite la recopilación de las utilidades enviadas ni de los niveles de registro.
  • Syslog no se reenvía correctamente al servidor Linux.
  • El número de mensajes que se reenvía por segundo es demasiado grande para la configuración de base del agente de Log Analytics para Linux.

Solución

  • Compruebe que la configuración de Syslog en el área de trabajo de Log Analytics tenga todas las utilidades y los niveles de registro correctos. Revise Configuración de recopilación de Syslog en Azure Portal.
  • Compruebe que los demonios de mensajería de Syslog nativos (rsyslog, syslog-ng) puedan recibir los mensajes reenviados.
  • Compruebe la configuración del firewall en el servidor de Syslog para asegurarse de que no se estén bloqueando los mensajes.
  • Simule un mensaje de Syslog en Log Analytics mediante un comando logger:
    logger -p local0.err "This is my test message"

Problema: Recibe el error de que la dirección Errno ya en uso en el archivo de registro de omsagent

Se ve [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> en omsagent.log.

Causas probables

Este error indica que la extensión de diagnóstico de Linux (LAD) está instalada en paralelo con la extensión de VM de Linux de Log Analytics. Está usando el mismo puerto para la recopilación de datos de Syslog que omsagent.

Solución

  1. Como raíz, ejecute los siguientes comandos. Tenga en cuenta que 25224 es un ejemplo y es posible que en su entorno vea que LAD usa otro número de puerto.

    /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229

sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf

    A continuación, tiene que editar el archivo de configuración correcto, rsyslogd o syslog_ng, y cambiar la configuración relacionada con LAD para escribir en el puerto 25229.

  2. Si la VM ejecuta rsyslogd, el archivo que debe modificarse es /etc/rsyslog.d/95-omsagent.conf (si existe, de lo contrario, /etc/rsyslog). Si la VM ejecuta syslog_ng, el archivo que debe modificarse es /etc/syslog-ng/syslog-ng.conf.

  3. Reinicie omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Reinicie el servicio de Syslog.

Incidencia: no puede desinstalar omsagent con la opción purgar

Causas probables

  • La extensión de diagnóstico de Linux está instalada.
  • La extensión de diagnóstico de Linux se instaló y desinstaló, pero todavía aparece un error que indica que mdsd esta usando omsagent y que no se puede quitar.

Solución

  1. Desinstale la extensión de diagnóstico de Linux.
  2. Quite los archivos de la extensión de diagnóstico de Linux de la máquina si están presentes en la siguiente ubicación: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ y /var/opt/microsoft/omsagent/LAD/.

Incidencia: no puede ver ningún dato de Nagios

Causas probables

  • El usuario omsagent no tiene permisos para leer desde el archivo de registro de Nagios.
  • No se quitó la marca de comentario del origen y del filtro de Nagios desde el archivo omsagent.conf.

Solución

  1. Agregue el usuario omsagent para leer desde el archivo de Nagios siguiendo estas instrucciones.

  2. En el archivo de configuración general del agente de Log Analytics para Linux en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, asegúrese de que se haya quitado la marca de comentarios tanto del origen como del filtro de Nagios.

    <source>
  type tail
  path /var/log/nagios/nagios.log
  format none
  tag oms.nagios
</source>

<filter oms.nagios>
  type filter_nagios_log
</filter>

Incidencia: no ve ningún dato de Linux

Causas probables

  • Error de incorporación a Azure Monitor.
  • La conexión a Azure Monitor está bloqueada.
  • La máquina virtual se reinició.
  • El paquete de OMI se actualizó manualmente a una versión más reciente en comparación con la que instaló el paquete del agente de Log Analytics para Linux.
  • OMI está congelado, bloqueando al agente de OMS.
  • Error clase no encontrada de los registros de recursos DSC en el archivo de registro omsconfig.log.
  • Se está haciendo la copia de seguridad de los datos del agente de Log Analytics.
  • Registros de DSC La configuración actual no existe. Ejecute el comando Start-DscConfiguration con el parámetro -Path para especificar un archivo de configuración y crear primero la configuración actual. en el archivo de registro omsconfig.log, pero no existe ningún mensaje de registro sobre las operaciones PerformRequiredConfigurationChecks.

Solución

  1. Instale todas las dependencias como el paquete auditd.

  2. Para comprobar si la incorporación a Azure Monitor se realizó correctamente, asegúrese de que existe el archivo siguiente: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Si no fue así, repita la incorporación mediante las instrucciones de línea de comandos de omsadmin.sh.

  3. Si está usando un proxy, compruebe los pasos anteriores para solucionar problemas con un proxy.

  4. En algunos sistemas de distribución de Azure, el demonio de servidor OMI de omid no se inicia después de reiniciar la máquina virtual. Si este es el caso, no verá los datos relacionados con la solución de Audit, ChangeTracking ni UpdateManagement. La solución alternativa consiste en iniciar manualmente el servidor OMI ejecutando sudo /opt/omi/bin/service_control restart.

  5. Después de que el paquete OMI se actualice manualmente a una versión más reciente, debe reiniciarse manualmente para que el agente de Log Analytics siga funcionando. Este paso es necesario para algunas distribuciones donde el servidor OMI no se inicia automáticamente tras su actualización. Ejecute sudo /opt/omi/bin/service_control restart para reiniciar la OMI.

    En algunas situaciones, la OMI puede congelarse. El agente de OMS puede entrar en un estado bloqueado en espera de la OMI, bloqueando toda la recopilación de datos. El proceso del agente de OMS se ejecutará, pero no habrá ninguna actividad, como evidenciará que no haya ninguna nueva línea de registro (como los latidos enviados) presente en omsagent.log. Reinicie la OMI con sudo /opt/omi/bin/service_control restart para recuperar el agente.

  6. Si ve el error clase no encontrada de recurso DSC en omsconfig.log, ejecute sudo /opt/omi/bin/service_control restart.

  7. En algunos casos, cuando el agente de Log Analytics para Linux no puede comunicarse con Azure Monitor, se crea una copia de seguridad de los datos en el agente del tamaño total del búfer de 50 MB. Se debe reiniciar el agente ejecutando el siguiente comando /opt/microsoft/omsagent/bin/service_control restart.

    Nota

    Esta incidencia se ha corregido en la versión 1.1.0-28 y posteriores del agente.

    • Si el archivo de registro omsconfig.log no indica que las operaciones PerformRequiredConfigurationChecks se ejecutan periódicamente en el sistema, podría haber un problema con el servicio/trabajo cron. Asegúrese de que exista el trabajo cron en /etc/cron.d/OMSConsistencyInvoker. De ser necesario, ejecute los siguientes comandos para crear el trabajo cron:

      mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker

    • Además, asegúrese de que el servicio cron se esté ejecutando. Puede usar service cron status con Debian, Ubuntu y SUSE; o service crond status con RHEL, CentOS y Oracle Linux, para comprobar el estado de este servicio. Si el servicio no existe, puede instalar los archivos binarios e iniciar el servicio mediante las siguientes instrucciones:

      Ubuntu/Debian

      # To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start

      SUSE

      # To Install the service binaries
sudo zypper in cron -y
# To start the service
sudo systemctl enable cron
sudo systemctl start cron

      RHEL/CentOS

      # To Install the service binaries
sudo yum install -y crond
# To start the service
sudo service crond start

      Oracle Linux

      # To Install the service binaries
sudo yum install -y cronie
# To start the service
sudo service crond start

Incidencia: al configurar la colección desde el portal para los contadores de rendimiento de Syslog o Linux, la configuración no se aplica

Causas probables

  • El agente de Log Analytics para Linux no ha seleccionado la configuración más reciente.
  • Los cambios de configuración en el portal no se aplicaron.

Solución

Información previa: omsconfig es el agente de configuración del agente de Log Analytics para Linux que cada cinco minutos busca una nueva configuración del portal. Esta configuración se aplica luego en los archivos de configuración del agente de Log Analytics para Linux ubicados en /etc/opt/microsoft/omsagent/conf/omsagent.conf.

En algunos casos, es posible que el agente de configuración del agente de Log Analytics para Linux no pueda comunicarse con el servicio de configuración del portal. Este escenario provoca que no se aplique la configuración más reciente.

  1. Para comprobar que el agente omsconfig está instalado, ejecute dpkg --list omsconfig o rpm -qi omsconfig. Si no está instalado, vuelva a instalar la versión más reciente del agente de Log Analytics para Linux.

  2. Compruebe que el agente omsconfig puede comunicarse con Azure Monitor ejecutando el siguiente comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Este comando devuelve la configuración que el agente recibe del servicio, incluida la configuración de Syslog, los contadores de rendimiento de Linux y los registros personalizados. Si se produce un error en este comando, ejecute el siguiente comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Este comando fuerza al agente omsconfig a comunicarse con Azure Monitor y a recuperar la configuración más reciente.

Incidencia: no está viendo ningún dato de registro personalizado

Causas probables

  • Error de incorporación a Azure Monitor.
  • No se ha seleccionado la opción Aplicar la siguiente configuración a mis servidores Linux.
  • omsconfig no ha elegido la configuración del registro personalizado más reciente desde el servicio.
  • El usuario omsagent del agente de Log Analytics para Linux no puede acceder al registro personalizado debido a permisos o a que no se encuentra. Pueden aparecer los errores siguientes:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Una incidencia conocida con condición de carrera se ha corregido en el agente de Log Analytics para Linux versión 1.1.0-217.

Solución

  1. Para comprobar si la incorporación a Azure Monitor se realizó correctamente, asegúrese de que existe el archivo siguiente: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Si no existe:

    1. Repita la incorporación mediante las instrucciones de la línea de comandos de omsadmin.sh.
    2. En Configuración avanzada en Azure Portal, asegúrese de que la opción Aplicar la configuración que aparece a continuación a mis máquinas con Linux esté habilitada.

  2. Compruebe que el agente omsconfig puede comunicarse con Azure Monitor ejecutando el siguiente comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Este comando devuelve la configuración que el agente recibe del servicio, incluida la configuración de Syslog, los contadores de rendimiento de Linux y los registros personalizados. Si se produce un error en este comando, ejecute el siguiente comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Este comando fuerza al agente omsconfig a comunicarse con Azure Monitor y a recuperar la configuración más reciente.

Información previa: En lugar de que el agente de Log Analytics para Linux se ejecute como usuario con privilegios, root, el agente se ejecuta como el usuario omsagent. En la mayoría de los casos se deben conceder permisos explícitos al usuario para que lea determinados archivos. Para conceder permiso al usuario omsagent, ejecute los siguientes comandos:

  1. Agregue el usuario omsagent a un grupo específico: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Conceda acceso de lectura universal al archivo necesario: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Existe una incidencia conocida con condición de carrera en el agente de Log Analytics para Linux anterior a la versión 1.1.0-217. Después de actualizar al agente más reciente, ejecute el siguiente comando para obtener la versión más reciente del complemento de salida: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Incidencia: está intentando repetir la incorporación a una nueva área de trabajo

Cuando intenta repetir la incorporación de un agente en una nueva área de trabajo, la configuración del agente de Log Analytics debe limpiarse antes de repetir la incorporación. Para limpiar la configuración anterior del agente, ejecute la agrupación de shell con --purge:

sudo sh ./omsagent-*.universal.x64.sh --purge

Or

sudo sh ./onboard_agent.sh --purge

Puede continuar repitiendo la incorporación después de usar la opción --purge.

Incidencia: la extensión del agente de Log Analytics en Azure Portal está marcada con un estado de error: Error de aprovisionamiento

Causas probables

  • Se quitó el agente de Log Analytics del sistema operativo.
  • El servicio del agente de Log Analytics está fuera de servicio, deshabilitado o no está configurado.

Solución

  1. Elimine la extensión desde Azure Portal.
  2. Instale el agente siguiendo las instrucciones.
  3. Ejecute el comando siguiente para reiniciar el agente:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Espere unos minutos hasta que el estado de aprovisionamiento cambia a Aprovisionamiento realizado correctamente.

Problema: Actualización a petición del agente de Log Analytics

Causas probables

Los paquetes de agente de Log Analytics en el host no están desactualizados.

Solución

  1. Busque la versión más reciente en esta página de GitHub.

  2. Descargue el script de instalación (1.4.2-124 es una versión de ejemplo):

    wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh

  3. Para actualizar los paquetes, ejecute sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Incidencia: la instalación produce un error que dice que Python2 no admite ctypes, a pesar de que se está utilizando Python3

Causas probables

Hay una incidencia conocida por el que, si el idioma de la máquina virtual no es inglés, se producirá un error al comprobar qué versión de Python se está utilizando. Esto hace que el agente siempre asuma que se usa Python2 y que se produzca un error si no hay Python2.

Resolución

Cambie el idioma del entorno de la máquina virtual a inglés:

export LANG=en_US.UTF-8