Od około dwóch lat prowadzimy kilka stron internetowych przy infrastrukturze Amazons AWS i od około dwóch dni serwer przestał działać raz lub dwa razy dziennie z jedynym błędem, jaki mogę znaleźć:
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch nie uruchamia żadnych alarmów (CPU / Disk IO / DB Conn). Próbowałem wejść na stronę za pomocą elastycznego adresu IP, aby pominąć ELB i otrzymałem:
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Nie widzę nic niezwykłego w dziennikach apache i zweryfikowałem, że były one odpowiednio obracane. Nie mam problemów z dostępem do komputera, gdy jest on „wyłączony” przez SSH i patrząc na listę procesów widzę 151 procesów apache2, które wydają mi się normalne. Ponowne uruchomienie apache tymczasowo rozwiązuje problem. Ta maszyna działa jak serwer sieciowy za ELB. Wszelkie sugestie będą mile widziane.
Średnie wykorzystanie procesora: 7,45%, minimum: 0,00%, maksimum: 25,82%
Średnia wykorzystanie pamięci: 11,04%, minimum: 8,76%, maksimum: 13,84%
Średnia wykorzystania wymiany: nie dotyczy, minimum: nie dotyczy, maksimum: nie dotyczy
Wykorzystanie miejsca na dysku dla / dev / xvda1 zamontowane na / Średnia: 62,18%, Minimalna: 53,39%, Maksymalna: 65,49%
Pozwól mi wyjaśnić, że myślę, że problem dotyczy indywidualnej instancji EC2, a nie ELB. Po prostu nie chciałem tego wykluczyć, mimo że nie byłem w stanie osiągnąć elastycznego adresu IP. Podejrzewam, że ELB zwraca wyniki trafienia w rzeczywistą instancję EC2.
Aktualizacja: 2014-08-26 Powinienem był to zaktualizować wcześniej, ale „poprawka” polegała na zrobieniu migawki „złej” instancji i uruchomieniu wynikowego AMI. Od tego czasu nie spadł. Patrzyłem na sprawdzanie kondycji, kiedy wciąż miałem problemy i mogłem przejść do strony sprawdzania kondycji ( curl http://localhost/page.html), nawet gdy otrzymywałem problemy z pojemnością z modułu równoważenia obciążenia. Nie jestem przekonany, że to był problem z kontrolą zdrowia, ale ponieważ nikt, w tym Amazon, nie może udzielić lepszej odpowiedzi, zaznaczam to jako odpowiedź. Dziękuję Ci.
Aktualizacja: 2015-05-06 Myślałem, że wrócę tutaj i powiem, że częścią problemu, który teraz mocno wierzę, były ustawienia kontroli zdrowia. Nie chcę wykluczyć, że są problemem z AMI, ponieważ zdecydowanie poprawiło się po uruchomieniu zastępczego AMI, ale dowiedziałem się, że nasze testy kondycji były różne dla każdego modułu równoważenia obciążenia i że ten, który miał najwięcej problemów miał naprawdę agresywny niezdrowy próg i limit czasu reakcji. Nasz ruch ma tendencję do gwałtownego wzrostu i myślę, że między agresywnymi ustawieniami kontroli zdrowia a skokami ruchu był to idealny sztorm.