Perché la verifica di stato Amazon EC2 ha successo per l'istanza non rispondente?

PERICOLO!

Non eseguire questo command per "provare" se non sei pronto per un crash e / o il riavvio forzato del sistema.

I passi che ho preso:

  • Ho creato un'istanza t1.micro su EC2 che gestisce Ubuntu 14.01 LTS.
  • Ho verificato che entrambi i controlli di stato sono passati.
  • Ho scritto SSH nell'istanza.
  • Ho eseguito la bomba a fork documentato in Perché questo command ha reso il mio sistema di ritardo così male che ho dovuto riavviare? .
    • La mia session SSH è mostrata di seguito.
  • Come potete vedere, l'istanza (in fretta) è uscito dalla memory e la mia session è terminata dopo un timeout.

Ho pensato che il controllo di stato di istanza non fosse riuscito. Tuttavia, entrambi i controlli di stato continuano a passare più di 20 minuti più tardi. L'istanza non risponde a SSH e ping, anche se nmap riferisce che la port 22 è aperta.

Speravo di utilizzare il controllo di stato per determinare se l'istanza fosse in grado di rispondere e avere il suo gruppo di autoscalazione terminato e sostituirlo, ma non sembra che sarò in grado di farlo.

Ho due domande:

  1. Perché l'istanza passa entrambi i controlli di stato?
  2. C'è un'altra soluzione (oltre a pagare $ 18 / mese per un bilanciatore di carico che non viene utilizzato per bilanciare il carico) per terminare istanze che non rispondono? C'è qualcosa che posso fare con gli allarmi cloudwatch?
    • Idealmente, vorrei avere l'istanza di riportre la sua salute periodicamente, e se non lo farà per un certo tempo, terminare (e lasciare che il mio gruppo di autoscalati si prenda cura del resto).

La mia session 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. 

Modifica: Quindi, il mio vero objective è quello di chiudere il divario tra ciò che controlli di stato controllano e verificare che la mia applicazione sia in esecuzione. Se i controlli di stato veramente verificano se il kernel funziona correttamente, mi sembra che potrei utilizzare un watchdog software del kernel (come il module kernel softdog) per chiudere tale gap.

  • Verificare effettivamente i controlli di stato che il kernel funziona come dovrebbe?
  • Se i controlli di stato indicano che il kernel è in esecuzione, significa necessariamente che tutti i moduli del kernel che ho caricato siano in esecuzione correttamente?

  • Come assicuro che il mio piano AWS gratuito non abbia superato il limite di utilizzo gratuito?
  • Amazon EFS Mount da OSX
  • Quali servizi AWS utilizzo?
  • Come get l'output dei container_command dopo la distribuzione?
  • Considerazioni di latenza e velocità tra 2 server su Amazon EC2
  • Colbind il database RDS dal lato esterno di VPC
  • Qualsiasi problema con backup di filesystem su PostgreSQL?
  • Creazione di un AMI da un'istanza EC2 con volumi montati
  • 2 Solutions collect form web for “Perché la verifica di stato Amazon EC2 ha successo per l'istanza non rispondente?”

    Non risponde! = Nessun battito cardiaco. Il kernel è ancora in esecuzione. AWS non ha modo di sapere che hai consumato tutta la tua memory.

    Il monitoraggio di AWS Cloudwatch è davvero il minimo che dovresti fare. Se hai bisogno di un monitoraggio più dettagliato, dovrai lanciare il tuo.

    Poiché i controlli di stato già prendono cura di assicurarsi che il kernel sia in su, è sufficiente utilizzare il module kernel softdog . Anche se questo è un timer di watchdog software, il fatto che si tratta di un module kernel significa che qualsiasi istanza in cui il watchdog stesso non risponde verrebbe rilevato anche dall'istanza di controllo di istanza eseguita da AWS, che a sua volta interromperebbe l'istanza EC2.

    Ecco cosa ho fatto nel mio script di installazione (questo era un Ubuntu AMI):

     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 
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.