Cześć,

Krótkie Post-Mortem z produkcji.

Incydent: Poniedziałek, 09:15. Po rutynowej rotacji certyfikatów, jeden z głównych mikroserwisów przestał przetwarzać dane.

Monitoring (Spring Boot Actuator + Grafana):

• Status aplikacji: UP (zielono).
• Health Check: UP (zielono).
• Consumer Lag: Stały (brak przyrostu, dashboard zamarzł).

Rzeczywistość: W nocy wystąpiła chwilowa niedostępność serwera uwierzytelniania. Klient Kafki otrzymał serię błędów AuthorizationException. Po wyczerpaniu prób ponownego połączenia, Springowy MessageListenerContainer podjął decyzję o zatrzymaniu się (stop()), aby nie spamować logów błędami krytycznymi.

Aplikacja Spring Boot działała dalej – serwer HTTP odpowiadał na health checki (Liveness Probe w Kubernetes przechodziła). Jednak wątek konsumenta Kafki był martwy i nie próbował się ponownie połączyć. System wszedł w stan "Zombie": żywy z zewnątrz, martwy w środku. Ponieważ konsument nie był podłączony, nie raportował swoich metryk do brokera

Efekt?
System stał przez kilka godzin, aż biznes zauważył, że system nie przetwarza transakcji.

To klasyczna "Awaria po cichu".

Domyślne metryki Spring Boota (Health) często sprawdzają tylko dostępność bazy danych czy dysku, a ignorują fakt, że Twój główny silnik przetwarzania (KafkaListener) właśnie się wyłączył.

Wnioski po tym incydencie i gotowe rozwiązania zebrałem w Kafka Watchtower.

To 10 konkretnych lekcji, a w nich m.in.:

• Jak wykryć "Stalled Consumer" (gdy wątek wisi, ale klient żyje).
• Gotowe snippety dla Springa (Java/Kotlin) do monitorowania Business Latency.
• Checklista Go/No-Go (14 punktów), która eliminuje takie błędy przed wdrożeniem.

Cena: 147 PLN (zamiast 199 PLN). Obowiązuje do piątku (09.01).

Link: Kafka Watchtower

Pozdrawiam,
Łukasz

PS. Po zakupie otrzymasz fakturę VAT i natychmiastowy dostęp do lekcji.