Solución de problemas de SSM Agent - AWS Systems Manager

Solución de problemas de SSM Agent

Si tiene problemas a la hora de ejecutar operaciones en los nodos administrados, es posible que haya algún problema con AWS Systems Manager Agent (SSM Agent). Utilice la siguiente información como ayuda para ver los archivos de registro de SSM Agent y solucionar los problemas del agente.

SSM Agent está desactualizado

Cada vez que se agregan capacidades nuevas a Systems Manager o se actualizan las capacidades existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas capacidades y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulta Automatización de las actualizaciones de SSM Agent. Suscríbase a la página SSM Agent Release Notes en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.

Solucionar problemas con los archivos de registro de SSM Agent

El SSM Agent registra información en los siguientes archivos. La información en estos archivos también puede ayudarlo a solucionar los problemas. Para obtener más información acerca de los archivos de registros de SSM Agent, e incluso acerca de cómo activar el registro de depuración, consulte Visualización de registros de SSM Agent.

nota

Si elige ver estos registros mediante el explorador de archivos de Windows, asegúrese de permitir la visualización de archivos ocultos y archivos del sistema en “Folder Options” (Opciones de carpeta).

En Windows
  • %PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log

  • %PROGRAMDATA%\Amazon\SSM\Logs\errors.log

En Linux y macOS
  • /var/log/amazon/ssm/amazon-ssm-agent.log

  • /var/log/amazon/ssm/errors.log

Para los nodos administrados de Linux, puede encontrar más información en el archivo messages escrito en el siguiente directorio: /var/log.

Para obtener información adicional sobre la solución de problemas con los registros de los agentes, consulte ¿Cómo puedo utilizar los registros de SSM Agent para solucionar los problemas con SSM Agent en mi instancia administrada? en el Centro de conocimientos re:Post de AWS.

Los archivos de registros del agente no rotan (Windows)

Si especifica la rotación del archivo de registro basada en la fecha en el archivo seelog.xml (en los nodos administrados de Windows Server) y los registros no rotan, especifique el parámetro fullname=true. A continuación, se muestra un ejemplo de un archivo de configuración seelog.xml con el parámetro fullname=true especificado.

<seelog type="adaptive" mininterval="2000000" maxinterval="100000000" critmsgcount="500" minlevel="debug"> <exceptions> <exception filepattern="test*" minlevel="error" /> </exceptions> <outputs formatid="fmtinfo"> <console formatid="fmtinfo" /> <rollingfile type="date" datepattern="200601021504" maxrolls="4" filename="C:\ProgramData\Amazon\SSM\Logs\amazon-ssm-agent.log" fullname=true /> <filter levels="error,critical" formatid="fmterror"> <rollingfile type="date" datepattern="200601021504" maxrolls="4" filename="C:\ProgramData\Amazon\SSM\Logs\errors.log" fullname=true /> </filter> </outputs> <formats> <format id="fmterror" format="%Date %Time %LEVEL [%FuncShort @ %File.%Line] %Msg%n" /> <format id="fmtdebug" format="%Date %Time %LEVEL [%FuncShort @ %File.%Line] %Msg%n" /> <format id="fmtinfo" format="%Date %Time %LEVEL %Msg%n" /> </formats> </seelog>

No es posible conectarse a los puntos de enlace de SSM

SSM Agent debe permitir el tráfico saliente HTTPS (puerto 443) a los siguientes puntos de conexión:

  • ssm.region.amazonaws.com

  • ssmmessages.region.amazonaws.com

region representa el identificador de Región de AWS compatible con AWS Systems Manager, como us-east-2 para la región EE. UU. Este (Ohio). Para ver una lista de los valores de regiones admitidos, consulte la columna Región en Puntos de conexión de servicio de Systems Manager en la Referencia general de Amazon Web Services.

nota

Antes de 2024, ec2messages.region.amazonaws.com también era obligatorio. En el caso de las Regiones de AWS lanzadas antes de 2024, sigue siendo obligatorio permitir el tráfico a ssmmessages.region.amazonaws.com, pero a ec2messages.region.amazonaws.com es opcional.

En el caso de las regiones lanzadas a partir de 2024, es obligatorio permitir el tráfico ssmmessages.region.amazonaws.com, pero estas regiones no admiten los puntos de conexión de ec2messages.region.amazonaws.com.

SSM Agent no funcionará si no puede comunicarse con los puntos de conexión anteriores, tal y como se ha descrito, incluso si usa las Amazon Machine Images (AMIs) proporcionadas por AWS, como Amazon Linux 2 o Amazon Linux 2023. La configuración de red debe tener acceso abierto a Internet o debe tener configurados los puntos de enlace personalizados de la nube privada virtual (VPC). Si no tiene previsto crear un punto de enlace de la VPC personalizado, verifique las gateways de Internet o las gateways NAT. Para obtener más información acerca de cómo administrar los puntos de enlace de la VPC, consulte Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager.

Verificación de la configuración VPC

Para administrar las instancias EC2 con Systems Manager, los puntos de conexión de VPC deben estar configurados correctamente para ssm.region.amazonaws.com, ssmmessages.region.amazonaws.com, y en algunos casos explicados anteriormente en este tema en No es posible conectarse a los puntos de enlace de SSM, ec2messages.region.amazonaws.com La configuración de red debe tener acceso abierto a Internet o debe tener configurados los puntos de conexión de nube privada virtual (VPC).

Para solucionar los problemas con los puntos de conexión de VPC, realice lo siguiente:

  • Asegúrese de que los puntos de conexión de VPC estén incluidos en el nivel de VPC. Si el punto de conexión de VPC con un nombre de servicio específico no se encuentra en la VPC, compruebe primero que la compatibilidad con DNS esté habilitada en el nivel de la VPC. A continuación, cree un nuevo punto de conexión de VPC y asócielo con una subred en cada zona de disponibilidad.

  • Asegúrese de que un nombre de DNS privado esté habilitado en el nivel de punto de conexión de VPC. Los nombres de DNS privados están habilitados de forma predeterminada, pero es posible que se hayan deshabilitado manualmente en algún punto.

  • Asegúrese de que los puntos de conexión de VPC existentes estén asociados a la subred adecuada. Además, asegúrese de que VPCE ya esté asociado a una subred en esa zona de disponibilidad.

Para obtener más información, consulte los temas siguientes:

Compruebe los atributos relacionados con el DNS de la VPC

Como parte de la verificación de la configuración de la VPC, asegúrese de que los atributos enableDnsSupport y enableDnsHostnames estén habilitados.

Puede habilitar estos atributos mediante la acción de la API ModifyVpcAttribute de Amazon EC2 o el comando AWS CLI modify-vpc-attribute.

Para obtener más información sobre la habilitación de estos atributos en la consola de Amazon VPC, consulte Ver y actualizar los atributos de DNS de su VPC en la Guía del usuario de Amazon VPC.

Verificación de las reglas de entrada en los grupos de seguridad de punto de conexión

Asegúrese de que todos los puntos de conexión de VPC que haya configurado (ssm, ssmmessages y ec2messages) incluyan una regla de entrada en sus grupos de seguridad para permitir que el tráfico entre por el puerto 443. Si es necesario, puede crear un nuevo grupo de seguridad en la VPC con una regla de entrada para permitir el tráfico en el puerto 443 para el bloque de enrutamiento entre dominios sin clases (CIDR) de la VPC. Después de crear el grupo de seguridad, adjúntelo a cada punto de conexión de VPC.

Para obtener más información, consulte los temas siguientes:

Utilice ssm-cli para solucionar los problemas de disponibilidad de los nodos administrados

A partir de la versión 3.1.501.0 de SSM Agent, se puede utilizar ssm-cli para determinar si un nodo administrado cumple los requisitos principales para que lo administre Systems Manager y para que aparezca en las listas de nodos administrados en Fleet Manager. La ssm-cli es una herramienta de la línea de comandos independiente incluida en la instalación de SSM Agent. Se encuentran incluidos comandos preconfigurados que recopilan información para ayudarlo a diagnosticar por qué una instancia de Amazon EC2 o una máquina que no es de EC2 que ha confirmado que se está ejecutando no se incluye en las listas de nodos administrados de Systems Manager. Estos comandos se ejecutan cuando se especifica la opción get-diagnostics.

Para obtener más información, consulte Solución de problemas de disponibilidad de nodos administrados mediante ssm-cli.