Monitoring dostępności bez cichych awarii

Gdy w jednej grupie przestawały działać kolejne hosty, wykres pokazywał degradację, ale alerting nie odzwierciedlał jej prawidłowo.

Pierwsza hipoteza dotyczyła grupowania powiadomień. Zanim można było zmieniać alerting, trzeba było sprawdzić, co właściwie oblicza metryka, na której opierał się alarm.

Monitoring przebudowałem według czterech zasad:

• Weryfikacja znaczenia metryki — sprawdzenie, na jakie pytanie rzeczywiście odpowiada metryka, zanim zmieni się logikę powiadomień.
• Dostępność liczona dla grup — agregacja oparta na rzeczywistych metadanych, tak aby wynik opisywał dostępność poszczególnych grup funkcjonalnych, a nie całości.
• Zero jako wynik — serie z wartością zero pozostają w obliczeniach, więc całkowita awaria grupy daje wynik 0%, a nie pusty wynik.
• Jawne granice wykrywania — przypadki, których metryka nie może wykryć, takie jak całkowity brak serii po usunięciu hosta z service discovery, są opisane wprost.

Analiza wykazała, że błędna operacja na etykietach metryk agregowała hosty do jednej grupy: system obliczał dostępność globalną zamiast dostępności poszczególnych grup funkcjonalnych. Wynik wyglądał wiarygodnie, choć odpowiadał na inne pytanie.

Logika obliczeń usuwała ponadto niedostępne serie z licznika, więc przy całkowitej awarii grupy, której hosty nadal raportowały status zero, wynik mógł zniknąć zamiast przyjąć wartość 0% — alert mógł zostać utracony w najbardziej krytycznym scenariuszu.

Przebudowałem agregację na podstawie rzeczywistych metadanych i obliczanie dostępności jako średniej wartości binarnych. Rozdzieliłem logikę alarmowania, prezentowania danych i diagnostyki pojedynczych hostów. Degradacja poszczególnych grup jest wykrywana prawidłowo, a całkowita awaria grupy przy zachowanych seriach statusowych daje wynik 0%, a nie ciszę.

Wartość: alarm opiera się na metryce, która odpowiada na właściwe pytanie — o dostępność konkretnej grupy — także w najbardziej krytycznym scenariuszu.