Host świeci na zielono, a użytkownik nadal nie może się zalogować albo zapłacić? To wcale nie jest rzadki scenariusz. Dobrze zaprojektowany monitoring oraz zbudowana struktura monitoringu i SLA usług biznesowych, idealnie łączy techniczne zdarzenia z widokiem biznesowym.

SLA, SLO i SLI często trafiają do jednego zdania, choć każde z nich opisuje coś innego. Warto je rozdzielić, bo właśnie na porównaniu oczekiwanego poziomu usługi z jej rzeczywistą dostępnością opiera się raport SLA w Zabbix.

• SLI — Jak usługa działała w rzeczywistości? Service Level Indicator, czyli zmierzony poziom dostępności usługi.
• SLO — Jaki wynik chcemy osiągnąć? Service Level Objective, czyli docelowy poziom dostępności, np. 99,9%.
• SLA — Na jakich zasadach rozliczamy usługę? Umowa lub reguła poziomu usług. W Zabbix łączy SLO, harmonogram, planowane przestoje i wybrane usługi, a następnie zestawia cel z wynikiem SLI.

Raport ma odpowiedzieć na jedno pytanie: czy rzeczywista dostępność SLI osiągnęła cel SLO w czasie objętym SLA? Sam procent to jednak za mało. Nie pokaże, co przestało działać i dlaczego. Tę informację daje dopiero model usług.

Wnajprostszym wariancie monitoring strony sprawdza odpowiedź serwera i oczekiwany kod HTTP. cURL uruchamiany co kilka minut potwierdzi, że strona jest osiągalna. Tyle, że logowanie na niej może już nie działać, gdyż baza danych, z której korzysta może być przeciążona, co powoduje, że część użytkowników ma problem z zalogowaniem poprzez długi proces logowania.

Test HTTP daje odpowiedź zero-jedynkową, a usługa biznesowa rzadko jest zero-jedynkowa. Składa się z komponentów o różnym znaczeniu. Niedziałający widget pogodowy nie musi zatrzymać sprzedaży. Awaria logowania albo płatności – już tak. I tę różnicę powinno pokazywać SLA.

Kolejność ma tu większe znaczenie niż sam formularz. Najpierw określ wartość biznesową i zależności usługi. Potem przypisz do nich problemy techniczne. SLA i raport są ostatnim krokiem, nie punktem wyjścia.

Najpierw ustal, co użytkownik ma dzięki tej usłudze zrobić. Stwierdzenie „portal działa” niewiele wyjaśnia. Czy można się zalogować, znaleźć produkt, złożyć zamówienie i zapłacić? Dopiero takie pytania odsłaniają krytyczne procesy. Biznes powinien wskazać, które z nich są najważniejsze i jaki poziom dostępności naprawdę wystarczy.

Od razu wskaż też właściciela usługi, odbiorców raportu, godziny świadczenia i skutki niedostępności. Inaczej można zbudować monitoring bez zarzutu od strony technicznej, który nie odpowiada na żadne ważne pytanie biznesowe.

Funkcja Services w Zabbix łączy techniczne szczegóły z widokiem usługi biznesowej. Portal można rozbić na frontend, API, uwierzytelnianie, wyszukiwarkę, płatności i bazę danych. Gdy pojawi się awaria, zobaczysz więc nie tylko czerwony status całego portalu, lecz także komponent, który ten status zmienił.

Dobrze widać to na przykładzie GitHuba. Actions, Pull Requests i Pages mają własne stany oraz osobne trendy dostępności. Własną usługę warto dzielić do momentu, w którym wpływ każdego elementu na użytkownika jest jasny, a jego stan da się wiarygodnie zmierzyć.

Model usług przypomina drzewo rodzic–dziecko, choć w praktyce częściej staje się siecią zależności. Jedna usługa podrzędna może mieć kilku rodziców, więc ten sam komponent obsłuży kilka procesów biznesowych bez dublowania definicji.

Całe mapowanie opiera się na znacznikach, ale warto rozdzielić dwa różne mechanizmy. Znaczniki problemów opisują zdarzenia techniczne i pomagają przypisać je do właściwej usługi. Znaczniki usług opisują same usługi i służą później do powiadomień oraz dopasowania definicji SLA.

Problem ze znacznikiem → warunek usługi → znacznik usługi → powiadomienie lub warunek SLA

Logika AND i OR 

Przy znacznikach problemów kilka warunków działa jak logika AND: zdarzenie musi spełnić wszystkie warunki, żeby trafiło do danej usługi. Przy znacznikach usług używanych w SLA działa natomiast OR, więc wystarczy jedno dopasowanie. W praktyce znacznik problemu mówi: „ten alert dotyczy płatności”, a znacznik usługi mówi: „ta usługa ma być objęta konkretnym SLA”. Zbyt ogólna wartość, np. service=app, może więc podpiąć pod raport usługę, której wcale nie planowałeś rozliczać. 

Skąd Zabbix bierze znaczniki problemu 

Problem dziedziczy znaczniki z całego łańcucha konfiguracji: szablonów, hostów, itemów, scenariuszy webowych i triggerów. To wygodne, dopóki panujesz nad konwencją. Każdy odziedziczony znacznik trafia do zdarzenia, a więc może zmienić sposób dopasowania usługi. 

Jeśli jeden host obsługuje kilka aplikacji, znaczniki ustawione wyłącznie na poziomie hosta szybko zaczynają się mieszać. Lepiej przypisać je do szablonów konkretnych usług. Taki szablon podłączysz do wielu hostów w klastrze, a znacznik nadal opisuje funkcję, nie pojedynczą maszynę. 

Dobra konwencja znaczników powinna być: 

• jednoznaczna – znacznik wskazuje konkretną usługę lub komponent; 

• spójna – te same nazwy i wartości są używane w szablonach, triggerach, usługach i SLA; 

• odporna na kolizje – identyfikator usługi jest bezpieczniejszy niż ogólna etykieta; 

• oszczędna – każdy dodatkowy znacznik zwiększa objętość danych zdarzeń, więc powinien mieć konkretną rolę.
  

Pomocna może być również wizualizacja map sieci i infrastruktury IT – dowiedz się o niej więcej w naszym artykule. 

Problemy techniczne przypisujesz bezpośrednio tylko do usług na najniższym poziomie. Wyższe poziomy dostają stan wyliczony z usług podrzędnych. Pojedynczy znacznik nie musi więc znać całej biznesowej układanki. 

Podstawowa reguła może przejąć stan najbardziej krytycznej usługi podrzędnej, zareagować dopiero wtedy, gdy problem dotyczy wszystkich dzieci, albo pozostawić status OK. Gdy to nie wystarcza, konfiguracja zaawansowana pozwala uwzględnić liczbę, procent lub łączną wagę usług w określonym stanie. 

Wagi pozwalają odwzorować znaczenie komponentów 

Komponenty nie są równie ważne i wagi pozwalają to pokazać. Chodzi o to, żeby awaria elementu krytycznego ważyła więcej niż awaria elementu pomocniczego. W przykładowym klastrze Kubernetes węzeł control plane może mieć wagę 8, a worker – 1. Przy progu 10 awarię usługi wywoła więc problem control plane połączony z awarią dwóch workerów albo awaria dziesięciu workerów. Konkretne liczby są umowne, ale powinny wynikać z architektury i uzgodnionego wpływu na biznes. 

Propagacja określa, co zobaczy rodzic 

Nie każda awaria ma taki sam wpływ na całą usługę. Czasem problem dotyczy tylko jednego, mniej ważnego elementu i użytkownik nadal może korzystać z usługi. Innym razem psuje się komponent kluczowy albo kilka elementów naraz – wtedy problem powinien być widoczny wyżej, na poziomie całej usługi biznesowej.

Propagacja pozwala ustalić, kiedy lokalna usterka ma pozostać lokalna, a kiedy powinna „podnieść alarm” dla całej usługi. Dzięki temu SLA nie reaguje jednakowo na każdy alert techniczny, tylko pokazuje realny wpływ problemu na działanie usługi z perspektywy użytkownika i biznesu.

Dopiero gdy model usług zachowuje się zgodnie z założeniami, przejdź do Services → SLA. W definicji ustawiasz: 

• nazwę SLA i docelową wartość SLO; 

• okres raportowania: dzienny, tygodniowy, miesięczny, kwartalny lub roczny; 

• strefę czasową i harmonogram dostępności 24/7 albo harmonogram niestandardowy; 

• Effective date, czyli datę, od której raport ma uwzględniać okresy; 

• znaczniki usług, które określają, do jakich usług stosuje się SLA; 

• wyłączone przestoje (Excluded downtimes), jeśli zaplanowanych prac nie należy wliczać do wyniku. 

Ta sama definicja SLA może obejmować wiele usług. Równie dobrze jedna usługa może podlegać kilku SLA. Zabbix liczy wynik osobno dla każdej pary usługa–SLA, co przydaje się wtedy, gdy różni odbiorcy mają inne cele lub harmonogramy. 

Maintenance nie zastępuje Excluded downtimes 

Maintenance pomaga zarządzać monitoringiem podczas prac serwisowych, np. ograniczyć zbieranie danych lub powiadomienia. Nie oznacza jednak automatycznie, że ten czas zostanie pominięty w rozliczeniu SLA. Jeśli planowany przestój nie ma obniżać wyniku SLA, trzeba wskazać go jako Excluded downtime albo wyłączyć w harmonogramie. Dzięki temu w raporcie zostaje jasny, możliwy do sprawdzenia ślad. 

Co z danymi historycznymi 

Pole Effective date wyznacza początek okresu widocznego w raporcie. Nie jest jednak wehikułem czasu. Zabbix policzy wynik tylko z dostępnych zdarzeń i historii stanów usługi. Jeśli wcześniej nie było modelu usługi, ustawienie starszej daty nie odtworzy go z surowych alertów.

Zapisany formularz potwierdza tylko tyle, że konfiguracja jest składniowo poprawna. Prawdziwy test zaczyna się przy kontrolowanym zdarzeniu. Obserwuj cały przepływ: problem → znacznik problemu → usługa najniższego poziomu → stan rodzica → dopasowanie SLA → raport. 

Przed uruchomieniem produkcyjnym sprawdź co najmniej: 

• czy pojedynczy problem trafia tylko do właściwej usługi; 

• czy awaria komponentu redundantnego nie obniża dostępności całej usługi zbyt wcześnie; 

• czy krytyczny komponent zmienia stan wszystkich właściwych usług nadrzędnych; 

• czy znaczniki SLA nie obejmują przypadkowych usług; 

• czy harmonogram, strefa czasowa i wyłączone przestoje odpowiadają ustaleniom; 

• czy odbiorcy widzą właściwe usługi i raporty zgodnie z rolami oraz uprawnieniami. 

• Start od konfiguracji zamiast od usługi. Zespół ustawia SLO i znaczniki, zanim uzgodni, co użytkownik uznaje za działającą usługę. 

• Zbyt szerokie znaczniki. Ogólne wartości dopasowują niepowiązane problemy lub usługi i zniekształcają raport. 

• Tworzenie znaczników wyłącznie na hostach. Przy wielu usługach na jednym hoście zdarzenia dziedziczą kontekst, który do nich nie pasuje. 

• Brak reguł dla redundancji. Awaria jednego węzła od razu obniża stan usługi, mimo że użytkownik nadal może z niej korzystać. 

• Traktowanie każdego problemu technicznego jako niedostępności. SLA powinno odzwierciedlać wpływ na usługę, nie liczbę alertów w infrastrukturze. 

• Wyłączanie prac przez Maintenance zamiast konfiguracji SLA. Raport traci przejrzystość, a sposób rozliczania przestojów staje się zależny od zachowania alertów. 

• Brak testów scenariuszowych. Błędy w logice AND/OR lub propagacji wychodzą dopiero podczas prawdziwego incydentu. 

Dobrze zbudowane SLA szybko przestaje być „procentem dla menedżera”. Łączy perspektywę infrastruktury, zespołu technicznego i biznesu. Jego wartość najlepiej widać wtedy, gdy pojawiają się problemy: pomaga ustalić, które zdarzenia naprawdę uderzają w usługę, co trzeba naprawić najpierw i na jakich danych oprzeć rozmowę z klientem albo dostawcą. 

• dowód ciągłości działania oparty na spójnych regułach; 

• szybsze wskazanie komponentu, który obniża dostępność usługi; 

• porównywanie trendów oraz wykorzystania budżetu błędów; 

• lepsze priorytety dla utrzymania, rozwoju i inwestycji; 

• czytelniejszą komunikację podczas incydentów; 

• możliwość weryfikacji, czy uzgodnione SLO jest realne. 

Jeśli raport regularnie nie osiąga celu, trzeba albo poprawić usługę, albo jeszcze raz porozmawiać o SLO. Sam monitoring niczego nie naprawi. Pozwala jednak nazwać problem na tyle precyzyjnie, żeby decyzja nie opierała się na przeczuciach. 

Nie zaczynaj od całej organizacji. Wybierz jedną usługę z jasno opisaną krytyczną ścieżką użytkownika i przejdź dla niej przez sześć kroków. Pierwszy model nie musi być doskonały. Ma być wspólnym, zrozumiałym prototypem dla biznesu i IT. 

1. Nazwij rezultat, który ma otrzymać użytkownik. 
2. Wskaż komponenty krytyczne oraz redundantne. 
3. Uzgodnij SLO, harmonogram i zasady planowanych przestojów. 
4. Zaprojektuj konwencję znaczników przed masową konfiguracją. 
5. Przetestuj kilka awarii i sprawdź raport razem z właścicielem usługi. 

Najwięcej pracy zwykle kosztuje rozmowa o zależnościach. To ona daje jednak najwięcej wartości. Zespół techniczny przestaje traktować wszystkie alerty tak samo i zaczyna patrzeć na to, co rzeczywiście ma znaczenie dla użytkownika oraz biznesu. 

Jeśli chcesz sprawdzić, czy Twój obecny monitoring rzeczywiście pokazuje stan usług biznesowych, zacznij od jednej krytycznej ścieżki użytkownika. Możemy pomóc przeanalizować obecną konfigurację Zabbix, uporządkować model usług i zaprojektować SLA, które będzie czytelne dla IT oraz biznesu. 

Czym jest SLA w Zabbix? 

To konfiguracja, która przypisuje cel SLO, harmonogram i ewentualne wyłączone przestoje do usług wskazanych znacznikami. Raport porównuje następnie rzeczywistą dostępność SLI z celem. 

Czym różnią się SLA, SLO i SLI? 

SLI jest zmierzonym poziomem dostępności, SLO – oczekiwanym celem, a SLA określa zasady, według których usługa jest rozliczana. W Zabbix wynik spełnienia celu powstaje przez porównanie SLI z SLO. 

Jak działa funkcja Services w Zabbix? 

Services tworzy hierarchię usług i łączy problemy techniczne z usługami najniższego poziomu za pomocą znaczników. Stany są następnie obliczane i propagowane do usług nadrzędnych. 

Czy jedna usługa może mieć kilku rodziców? 

Tak. Ta sama usługa podrzędna może należeć do kilku usług nadrzędnych, jeśli dany komponent wpływa na więcej niż jeden proces biznesowy. 

Jak znaczniki wpływają na SLA? 

W Zabbix działają tu dwa rodzaje znaczników. Znaczniki problemów przypisują zdarzenia techniczne do konkretnych usług. Jeśli usługa ma kilka warunków opartych na znacznikach problemu, problem musi spełnić wszystkie warunki, czyli działa logika AND. 

Znaczniki usług służą natomiast do dopasowania usług do definicji SLA. W tym przypadku wystarczy, że usługa spełni jeden z warunków tagowania, więc działa logika OR. Dlatego znaczniki usług powinny być możliwie precyzyjne, żeby SLA nie objęło przypadkowych usług. 

Czy Maintenance wyłącza czas z SLA? 

Nie należy na tym polegać. Okresy, które mają być formalnie pominięte, trzeba zdefiniować w harmonogramie SLA albo jako Excluded downtimes. 

Czy Zabbix policzy SLA za okres historyczny? 

Raport może obejmować okresy od wskazanego Effective date, ale tylko w granicach dostępnej historii stanów usługi. Zabbix nie odtworzy automatycznie modelu usługi za czas, gdy model jeszcze nie istniał. 

Jak wybrać problemy, które mają wpływać na SLA? 

Zacznij od ścieżki użytkownika i skutku biznesowego, nie od listy triggerów. Do SLA powinny trafiać te problemy, które rzeczywiście obniżają zdolność usługi do realizacji uzgodnionej funkcji. 

Sprawdź jeszcze nasz artykuł Zabbix 8.0 – dlaczego ta wersja może zmienić sposób monitorowania infrastruktury IT?

Recenzent: Mateusz Dampc, Architekt ds. monitoringu infrastruktury IT