Monitoring dostępności serwera: kontrole, narzędzia i alerty

Aby monitorować dostępność serwera, uruchamiaj automatyczne kontrole spoza serwera (ping, port TCP lub żądania HTTP z kilku lokalizacji), zbieraj sygnały o kondycji samego serwera za pomocą agenta i alertuj tylko wtedy, gdy kilka lokalizacji zawiedzie z rzędu. Następnie rejestruj każdą awarię, aby co miesiąc obliczać dostępność względem SLA.

Najważniejsze wnioski

• Zewnętrzne kontrole syntetyczne odpowiadają na pytanie „czy użytkownicy mogą się połączyć?”, a agenci wewnętrzni na pytanie „dlaczego nie działa?”. Potrzebujesz obu.
• Sprawdzaj z co najmniej trzech lokalizacji i alertuj po kolejnych niepowodzeniach, aby uniknąć fałszywych alarmów z jednej wadliwej ścieżki sieciowej. Microsoft zaleca co najmniej pięć lokalizacji testowych dla testów dostępności Azure.
• Testuj to, z czego korzystają użytkownicy: żądanie HTTPS sprawdzające kod statusu i zawartość strony jest lepsze niż ping.
• Dostępność 99,9% nadal dopuszcza około 43,8 minuty przestoju miesięcznie. Wiedz, na co pozwala Twój cel, zanim ustawisz progi alertów.
• Konsekwentnie wyłączaj uzgodnione okna serwisowe i co miesiąc raportuj dostępność z tych samych danych.

Czym jest monitorowanie dostępności serwera?

Monitorowanie dostępności serwera to ciągłe sprawdzanie, czy serwer i działające na nim usługi są osiągalne i odpowiadają poprawnie. Daje dwie rzeczy: alerty, gdy coś przestaje działać, oraz historię, którą można zamienić na procent dostępności.

Czas pracy (uptime) i dostępność są powiązane, ale nie tożsame. Serwer może być włączony (wysoki uptime), a jego usługa webowa zwracać błędy (niska dostępność). Dla większości firm liczy się dostępność usługi widziana oczami użytkowników.

Ile przestoju dopuszcza każdy cel dostępności?

Dostępność to (całkowity czas − przestój) ÷ całkowity czas. Tabela przelicza popularne cele na dopuszczalny przestój, przyjmując średni miesiąc 730 godzin.

Ostry cel zmienia sposób monitorowania. Przy 99,99% pięciominutowy odstęp między kontrolami nie wykryje nawet każdego naruszenia, więc potrzebujesz kontroli co minutę lub częściej oraz reakcji dyżurnej liczonej w minutach. Rozdział książki Google SRE o akceptowaniu ryzyka wyjaśnia, dlaczego każda kolejna dziewiątka kosztuje więcej i dlaczego cel powinien wynikać z potrzeb biznesu.

Jakie kontrole uruchomić?

Kontrole zewnętrzne (syntetyczne)

• ICMP ping: pokazuje, że host odpowiada w sieci. Tani, ale wiele zapór go blokuje, a host może odpowiadać na ping, gdy jego aplikacje nie działają.
• Kontrole portów TCP: potwierdzają, że usługa nasłuchuje, na przykład port 443 dla HTTPS, 3389 dla RDP lub 5432 dla PostgreSQL.
• Kontrole HTTP(S): żądanie adresu URL, sprawdzenie kodu statusu, czasu odpowiedzi i fragmentu oczekiwanej zawartości. Użyj dedykowanego punktu kontroli stanu, który testuje także połączenie z bazą danych.
• Kontrole certyfikatów TLS: ostrzegają przed wygaśnięciem certyfikatu. Wygasły certyfikat to dla użytkowników awaria, nawet gdy serwer jest zdrowy.
• Kontrole DNS: potwierdzają, że nazwa rozwiązuje się na właściwy adres.

Sygnały wewnętrzne (z agentów)

• Heartbeat: agent zgłasza się co minutę; brak sygnału oznacza, że host lub agent nie działa.
• Licznik czasu pracy systemu: pokazuje nieplanowane restarty. W Linuksie użyj uptime lub last reboot; w Windows zdarzenie o ID 6008 w dzienniku System rejestruje nieoczekiwane zamknięcie.
• Metryki zasobów: CPU, pamięć, miejsce na dysku i opóźnienie dysku. Pełne dyski i wyczerpanie pamięci to częste przyczyny stanu „działa, ale nie pracuje”.
• Stan usług i procesów: czy działa serwer WWW, baza danych lub zaplanowane zadanie?

Dla hostów z Windows nasz przewodnik jak monitorować wydajność Windows Server wymienia liczniki warte zbierania.

Jakie narzędzia monitorują dostępność serwera?

Wybór ma mniejsze znaczenie niż konfiguracja. Narzędzie hostowane samodzielnie również wymaga monitorowania: jeśli Twój jedyny serwer monitorujący stoi w tej samej szafie co serwery, które obserwuje, awaria zasilania wyłączy oba. Uruchom co najmniej jedną kontrolę zewnętrzną z innej sieci lub z usługi chmurowej.

Jak ustawić alerty dostępności bez fałszywych alarmów

1. Użyj kilku lokalizacji. Microsoft zaleca co najmniej pięć lokalizacji testowych dla testów dostępności Azure i próg alertu równy liczbie lokalizacji minus dwie, na przykład trzy niepowodzenia z pięciu.
2. Wymagaj kolejnych niepowodzeń. Opcja ponawiania w Azure zgłasza awarię dopiero po niepowodzeniu trzech kolejnych prób; Microsoft zauważa, że około 80% awarii znika po ponowieniu.
3. Ustal wagę według wpływu. Produkcyjny portal klienta wywołuje dyżurnego inżyniera; serwer testowy wysyła zgłoszenie.
4. Kieruj alerty do osób, które mogą zareagować, z eskalacją, jeśli nikt nie potwierdzi w ustalonym czasie.
5. Wyciszaj planowane prace serwisowe w narzędziu monitorującym, zamiast ignorować alerty z przyzwyczajenia.
6. Alertuj także o powrocie do normy, aby zespół wiedział, kiedy incydent się skończył.

Wskazówki Google SRE dotyczące monitorowania systemów rozproszonych dodają użyteczną regułę: każde wywołanie dyżurnego powinno być pilne, wymagać działania i człowieka. Wszystko inne należy do zgłoszenia lub pulpitu.

Jak raportować dostępność względem SLA

• Zdefiniuj, co oznacza awarię, na przykład „punkt kontroli stanu zawodzi z trzech z pięciu lokalizacji przy dwóch kolejnych kontrolach”.
• Uzgodnij, które okna serwisowe są wyłączone, i zapisz je w narzędziu.
• Obliczaj miesięczną dostępność z wyników kontroli, a nie z pamięci czy notatek ze zgłoszeń.
• Prowadź dziennik awarii z początkiem, końcem, przyczyną i naprawą. Wzorce, takie jak awarie po każdej nocy z poprawkami, pokazują, gdzie warto inwestować.
• Porównaj swoją liczbę z tym, do czego zobowiązuje się dostawca chmury. Na przykład Amazon Compute SLA gwarantuje 99,99% miesięcznej dostępności dla EC2 wdrożonych w wielu strefach dostępności w regionie, ale tylko 99,5% dla pojedynczej instancji EC2. Dostępność Twojej aplikacji nigdy nie przekroczy tego, co zapewnia jej najsłabsza zależność.

Monitoring informuje o awariach, a redundancja im zapobiega. Uruchamiaj krytyczne obciążenia na więcej niż jednym serwerze lub w więcej niż jednej strefie dostępności za load balancerem, aby pojedyncza awaria nie wyłączyła usługi. WorkBuster, platforma rekrutacyjna SaaS, działa na EC2 za Application Load Balancer, z wielostrefowym MySQL RDS, grupą autoskalowania oraz pulpitami i alarmami CloudWatch; case study WorkBuster pokazuje pełną konfigurację.

Jak pomaga Opsio

Opsio prowadzi monitoring i reagowanie na incydenty 24/7 dla serwerów i obciążeń chmurowych w AWS, Azure i Google Cloud. Konfigurujemy kontrole, routing alertów i miesięczne raporty dostępności, a nasi inżynierowie reagują na alerty. Zobacz nasze strony: usługi monitoringu i wsparcia chmury, zdalny monitoring infrastruktury oraz observability z Prometheus i Grafana.

Najczęściej zadawane pytania

Jak sprawdzić, od jak dawna działa serwer?

W Linuksie uruchom uptime lub last reboot. W Windows otwórz kartę Wydajność w Menedżerze zadań, uruchom systeminfo i odczytaj „System Boot Time” lub sprawdź dziennik zdarzeń System. Pokazują one czas od ostatniego uruchomienia, a nie to, czy usługi były dostępne.

Jak często uruchamiać kontrole dostępności?

Co jedną do pięciu minut dla większości usług produkcyjnych. Dopasuj odstęp do swojego celu: przy 99,99% masz tylko około 4,4 minuty przestoju miesięcznie, więc pięciominutowy odstęp jest zbyt wolny, by to zmierzyć.

Czy ping wystarczy do monitorowania dostępności serwera?

Nie. Ping dowodzi tylko, że stos sieciowy odpowiada. Dodaj kontrolę TCP lub HTTPS usługi, od której zależą użytkownicy, najlepiej z dopasowaniem zawartości, oraz kontrole oparte na agencie na samym serwerze.

Jaki procent dostępności jest dobry dla serwera?

Dla aplikacji biznesowych częstym celem jest 99,9%; usługi dla klientów często celują w 99,95% lub więcej. Wyższe cele wymagają redundancji: AWS na przykład gwarantuje tylko 99,5% dla pojedynczej instancji EC2, ale 99,99% dla EC2 rozłożonych na strefy dostępności.

Czy mogę monitorować dostępność za darmo?

Tak. Narzędzia open source, takie jak Prometheus z blackbox_exporter, Zabbix czy Nagios, nie wymagają opłat licencyjnych, choć płacisz hostingiem i czasem utrzymania. Natywne kontrole dostawców chmury są tanie przy niewielkiej liczbie punktów końcowych.

Powiązane artykuły

• Czym jest monitoring chmury
• Co to jest monitorowanie w czasie rzeczywistym serwerów i aplikacji?
• Jak monitorować wydajność Windows Server? Narzędzia i metryki