¿Por qué mi instancia de EC2 de Linux no es accesible y no supera sus comprobaciones de estado?

Descripción corta

Amazon EC2 utiliza tres comprobaciones de estado para supervisar el estado de las instancias de EC2:

Comprobación de estado del sistema

La comprobación de estado del sistema detecta problemas con el hardware subyacente de una instancia. Si el hardware subyacente no responde o es inaccesible debido a problemas de red, hardware o software, entonces la comprobación de estado del sistema da error.

Comprobación de estado de la instancia

Un error en la comprobación de estado de la instancia indica que la instancia es inaccesible. Los siguientes problemas pueden provocar un error en la comprobación de estado de la instancia:

• Error al arrancar el sistema operativo (SO).
• Error al montar correctamente los volúmenes.
• CPU y memoria agotadas.
• Pánico en el núcleo.
• Error de red.

Advertencia: Algunas de las siguientes resoluciones requieren que la instancia se detenga e inicie. Antes de detener e iniciar la instancia, tenga en cuenta esta información:

• Los datos almacenados en los volúmenes del almacén de instancias se pierden cuando se detiene la instancia. No olvide realizar una copia de seguridad de los datos antes de detener la instancia. A diferencia de los volúmenes respaldados por Amazon Elastic Block Store (Amazon EBS), los volúmenes de almacén de instancias no admiten la persistencia de datos.
• La dirección IPv4 pública estática que Amazon EC2 asignó automáticamente a la instancia en el momento del inicio cambia después de la detención y el inicio. Para conservar una dirección IPv4 pública que no cambie si se detiene la instancia, use una dirección IP elástica.

Para obtener más información, consulte Detención e inicio de una instancia de Amazon EC2.

Comprobaciones de estado de EBS adjuntas

Las comprobaciones de estado de EBS adjuntas supervisan que los volúmenes de Amazon EBS adjuntos a una instancia sean accesibles y puedan completar las operaciones de E/S. Para obtener más información, consulte Comprobaciones de estado de EBS adjuntas.

Resolución

Para ver si la comprobación de estado de la instancia o del sistema han dado error, consulte las métricas de comprobación de estado de la instancia.

Si la comprobación de estado del sistema ha dado error, consulte ¿Por qué mi instancia de EC2 de Linux no supera la comprobación de estado del sistema?

Si la comprobación de estado de la instancia ha dado error, compruebe los registros del sistema de la instancia para ver la causa del error. Después, utilice una de las siguientes posibles soluciones para resolver el problema.

Error al arrancar el sistema operativo

Si los registros del sistema contienen errores de arranque, consulte Mi instancia de EC2 Linux no pasó la comprobación del estado de la instancia debido a problemas con el sistema operativo. ¿Cómo puedo solucionar este problema?

Error al montar correctamente los volúmenes

Un error en el punto de montaje puede provocar que la instancia no supere la comprobación de estado. Ejemplo de comando de error en el punto de montaje:

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

Para obtener más información, consulte los siguientes artículos del Centro de conocimientos de AWS:

• Errores de «Ha fallado la dependencia»: ¿Por qué mi instancia EC2 de Linux entra en modo de emergencia cuando intento arrancarla?
• Errores de «No se pudo montar» o «Ha fallado la dependencia»: Mi instancia de EC2 Linux no pasó la comprobación de estado de la instancia debido a problemas con el sistema operativo. ¿Cómo puedo solucionar este problema?

Cuando cambia un tipo de instancia Xen a una instancia basada en Nitro, el montaje del volumen puede fallar. El error de montaje se produce porque los volúmenes de Amazon EBS se exponen como dispositivos de bloques NVMe en instancias basadas en Nitro. Por ejemplo, los nombres de los dispositivos son /dev/nvme0n1 y /dev/nvme1n1. Los nombres de dispositivos que se hayan especificado en una asignación de dispositivos de bloques se cambian a nombres de dispositivos NVMe (/dev/nvme[0-26]n1).

Nota: El controlador de dispositivos de bloques puede asignar los nombres de los dispositivos NVMe en un orden diferente al orden que haya especificado en la asignación de dispositivos de bloques. Para evitar errores de montaje en las instancias basadas en Nitro, se recomienda utilizar una etiqueta o un UUID para los nombres de los dispositivos. Para obtener más información, consulte Hacer que un volumen de Amazon EBS esté disponible para su uso.

CPU y memoria agotadas

Uso alto de la CPU

Si la métrica CPUUtilization es igual o cercana al 100 %, la instancia no tiene suficiente capacidad de procesamiento para ejecutar el núcleo.

En el caso de las instancias T2 o T3, revise las métricas de crédito de CPU de Amazon CloudWatch para ver si los créditos UPC son iguales o cercanos a cero. Si los créditos de la CPU están en cero, la métrica CPUUtilization muestra un nivel de saturación en el rendimiento de referencia de la instancia. Por ejemplo, el rendimiento de referencia puede ser del 20 o el 40 %. Una utilización de la CPU igual o cercana al 100 % indica que la comprobación de estado falló debido a un uso excesivo de los recursos. Las instancias T2 o T3 que han alcanzado un nivel de saturación muestran que la comprobación de estado falló debido a una utilización excesiva.

Para solucionar este problema, consulte Mi instancia de Linux de EC2 no ha superado la comprobación de estado de la instancia debido a la sobreutilización de sus recursos. ¿Cómo puedo solucionar este problema?

Los fallos en dispositivos de bloques, los errores de software o el pánico en el núcleo pueden provocar un pico inusual en el uso de la CPU. Si el uso de la CPU es del 100 %, primero compruebe los registros del sistema para ver si hay fallos de dispositivos de bloques o problemas en la memoria u otros errores inusuales del sistema. A continuación, reinicie o detenga e inicie la instancia.

Sin memoria

La alta presión de memoria puede provocar un error en la comprobación de estado de la instancia. En el siguiente ejemplo de extracción de registro, el sistema operativo se ha quedado sin memoria y se ha iniciado el oom-killer. Para resolver este error, detenga el proceso que consume más memoria.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

De forma predeterminada, las métricas de memoria y disco de la instancia de EC2 no se envían a Amazon CloudWatch. Para obtener más información, consulte Recopilación de métricas, registros y seguimientos con el agente de CloudWatch.

Para resolver el problema de falta de memoria, actualice la instancia a un tipo de instancia más grande. O bien, añada almacenamiento de intercambio a la instancia para aliviar la presión de memoria. Para obtener más información, consulte los siguientes artículos del Centro de conocimientos de AWS:

• ¿Cómo puedo asignar la memoria para que funcione como un archivo de intercambio en una instancia de Amazon EC2?
• ¿Cómo puedo asignar memoria para que funcione como espacio de intercambio en una instancia de Amazon EC2 mediante una partición de mi disco duro?

Errores de disco lleno

Si los registros del sistema contienen errores de disco lleno, la instancia está en modo de emergencia debido a que el dispositivo raíz está lleno.

Ejemplo de registro del sistema:

$: sudo service apache2 restart
Error: No space left on device

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.serviceError: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

Para obtener instrucciones detalladas sobre cómo resolver los errores de disco lleno, consulte los siguientes artículos del Centro de conocimientos:

• ¿Cómo puedo solucionar los problemas con una instancia de EC2 de Linux que no supera una comprobación de estado por una utilización excesiva de los recursos?
• ¿Cómo puedo aumentar el tamaño de mi volumen de EBS si recibo un mensaje de error que indica que no queda espacio en mi sistema de archivos?

Pánico en el núcleo

El pánico en el núcleo se produce cuando el núcleo detecta un error interno grave durante la operación. Si el error se produce durante el arranque del sistema operativo, significa que el núcleo no se cargó correctamente. Este error al cargar el núcleo provoca un error de arranque de la instancia.

Ejemplo de mensaje de error de pánico en el núcleo:

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Para obtener información sobre cómo solucionar un error de pánico en el núcleo, consulte los siguientes artículos del Centro de conocimientos:

• ¿Cómo puedo solucionar un error de «pánico en el núcleo: no se sincroniza» en las instancias de EC2?
• ¿Cómo puedo volver a un núcleo estable conocido después de que una actualización impida que mi instancia de Amazon EC2 se reinicie correctamente?

Error de red

La red puede fallar por los siguientes motivos:

• El paquete cloud-init no está instalado en la instancia.
• El paquete cloud-init se usa para actualizar las configuraciones de red en el momento del inicio.

Para corregir este error e instalar el paquete cloud-init en su instancia, ejecute el siguiente comando:

Para los sistemas operativos Amazon, Amazon Linux 2, Amazon Linux 2023 o RedHat:

$ sudo yum install cloud-init -y

Para los sistemas operativos Ubuntu o Debian:

$ sudo apt install cloud-init -y

La dirección MAC está codificada de forma fija en un archivo de configuración

Las direcciones MAC codificadas se encuentran en los archivos de configuración de Linux y en los archivos de configuración udev. Puede encontrar estos archivos en las siguientes ubicaciones:

• /etc/udev/rules.d/
• /etc/udev/rules.d/70-persistent-net.rules
• /etc/udev/rules.d/80-net-name-slot.rules

Para resolver los problemas de red causados por una dirección MAC codificada, elimine las entradas o los archivos de configuración y, a continuación, ejecute el siguiente comando:

$ sudo mv /etc/udev/rules.d/70-persistent-net.rules /root/

Después de mover el archivo de configuración, reinicie el servicio de red para asegurarse de que se recibe una nueva dirección MAC.

La dirección IP está codificada de forma fija en un archivo de configuración de red

Al crear una imagen de máquina de Amazon (AMI) a partir de una instancia con una dirección IP configurada de forma estática, el archivo de configuración contiene una dirección IP codificada de forma fija. Para corregir este error, configure la interfaz de red para que utilice DHCP.

Nota: No puede actualizar las AMI que ya existen. Debe configurar la interfaz de red para que utilice DHCP antes de crear una nueva AMI.

Faltan los controladores de red ENA o mejorados por Intel

Para obtener más información sobre los adaptadores Elastic Network Adapter (ENA) o los controladores de red mejorados por Intel que faltan, consulte Redes mejoradas en instancias de Amazon EC2.

El nombre de la interfaz de red se cambia automáticamente al inicio

Para desactivar el cambio de nombre predecible de la interfaz de red, añada net.ifnames=0 a la línea de comandos del núcleo. Para usar el marcador de posición, debe activar las redes mejoradas con ENA y reconstruir o actualizar el archivo de configuración de grub.

Información relacionada

Solución de problemas de las instancias de Amazon EC2 para Linux con comprobaciones de estado no superadas

¿Por qué mi instancia de EC2 de Windows está inactiva con un error en la comprobación de estado del sistema o en la comprobación de estado 0/2?

¿Por qué mi instancia EC2 de Windows está inactiva con un error en la comprobación de estado de la instancia?

Tipos de comprobaciones de estado