Por que a verificação de status do Amazon EC2 é bem-sucedida para a instância que não responde?

Question

DANGER!

Do not run this command to 'test' it unless you are prepared for a crash and/or force-rebooting your system.

Os passos que eu dei:

• Eu criei uma instância t1.micro no EC2 executando o Ubuntu 14.01 LTS.
• verifiquei que ambas as verificações de status foram aprovadas.
• Eu usei o SSH na instância.
• Eu rodei a bifurcação documentada em Por que esse comando atrasou tanto o meu sistema que tive que reinicializar? .
  • Minha sessão SSH é mostrada abaixo.
• Como você pode ver, a instância (rapidamente) ficou sem memória e minha sessão terminou após um tempo limite.

Eu esperava que a verificação do status da instância falhasse . No entanto, as duas verificações de status continuam a passar mais de 20 minutos depois. A instância não responde ao SSH e ao ping, embora o nmap relate que a porta 22 está aberta.

Eu esperava usar a verificação de status para determinar se a instância era responsiva e ter seu grupo de escalonamento automático finalizado e substituí-la, mas não parece que poderei fazer isso.

Eu tenho duas perguntas:

1. Por que a instância está passando pelas verificações de status?
2. Existe outra solução (além de pagar US $ 18 / mês para um balanceador de carga que não está sendo usado para equilibrar a carga) para encerrar instâncias que não respondem? Existe algo que eu possa fazer com os alarmes do cloudwatch?
   • Idealmente, gostaria de poder fazer com que a instância relatasse sua integridade periodicamente e, se não conseguir fazê-lo por um determinado período de tempo, termine-a (e deixe que meu grupo de autoescala cuide do resto).

Minha sessão SSH:

Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-57-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Jul  9 18:50:39 UTC 2015

  System load: 0.0               Memory usage: 7%   Processes:       47
  Usage of /:  16.8% of 7.75GB   Swap usage:   0%   Users logged in: 0

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud


Last login: [[redacted]]
ubuntu@ip-172-31-18-225:~$ :(){ :|: & };:
[1] 1218
ubuntu@ip-172-31-18-225:~$ -bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
Connection to 52.2.62.141 closed.

Editar: Portanto, meu objetivo real é fechar a lacuna entre o que as verificações de status verificam e verificar se meu aplicativo está sendo executado. Se as verificações de status realmente verificarem se o kernel está funcionando corretamente, parece-me que eu poderia usar um watchdog de software de kernel (como o módulo kernel do softdog) para fechar essa lacuna.

• As verificações de status realmente verificam se o kernel está funcionando como deveria?
• Se as verificações de status dizem que o kernel está rodando, isso significa necessariamente que todos os módulos do kernel que carreguei estão rodando corretamente?

Answer 1

Como as verificações de status já garantem que o kernel esteja ativo, é suficiente usar o módulo do kernel softdog . Embora este seja um temporizador de watchdog de software, o fato de ser um módulo de kernel significa que qualquer instância na qual o watchdog se torne indiferente também seria detectada pelo Verificação de status da instância executada pela AWS, que, por sua vez, encerraria a instância do EC2.

Aqui está o que eu fiz no meu script de configuração (este foi um AMI do Ubuntu):

cat >>/etc/modules <<EOF
softdog
EOF

apt-get install watchdog

cat >>/etc/watchdog.conf <<EOF
interval = 10
logtick = 60
max-load-1 = 24
max-load-5 = 18
max-load-15 = 12
min-memory = 65536
watchdog-device = /dev/watchdog0
ping = 8.8.8.8
interface = eth0
test-binary = /path/to/my/health/check/script.sh
test-timeout = 30
realtime = yes
priority = 1
EOF

...other setup stuff...

reboot

# If you don't want to reboot, you can instead do:
modprobe softdog
service watchdog restart

    

Answer 2

Não responde! = sem pulsação. O kernel ainda está em execução. A AWS não tem como saber que você consumiu toda a sua memória.

O monitoramento do AWS Cloudwatch é realmente o mínimo que você deve fazer. Se você precisar de um monitoramento mais detalhado, precisará fazer o seu próprio plano.