Prometheus – co to jest i jak działa? Monitorowanie infrastruktury IT od podstaw

Czym jest Prometheus i do czego służy w monitoringu

Prometheus to otwartoźródłowy system monitorowania i alarmowania oparty na metrykach, czyli liczbowych pomiarach stanu infrastruktury oraz działania aplikacji. Pozwala sprawdzić między innymi, jak mocno obciążone są serwery, ile żądań obsługuje usługa, jak długo trwa ich przetwarzanie i jak często pojawiają się błędy. Dzięki temu pomaga ocenić nie tylko dostępność systemu, lecz także jego wydajność i kondycję.

Projekt powstał w SoundCloud, a obecnie jest rozwijany w ramach Cloud Native Computing Foundation (CNCF). Jest szeroko wykorzystywany w środowiskach kontenerowych i Kubernetes, ale jego zastosowanie nie ogranicza się do chmury. Może również monitorować aplikacje i usługi działające na maszynach wirtualnych oraz serwerach fizycznych.

Jakie pytania pomaga rozstrzygnąć?

Podstawowy test dostępności odpowiada na pytanie: „Czy usługa działa?”. Prometheus pozwala spojrzeć głębiej: „Czy działa prawidłowo i czy jej stan się pogarsza?”. Aplikacja może nadal odpowiadać na żądania, mimo że czas odpowiedzi rośnie, a baza danych zbliża się do limitu dostępnych połączeń. Obserwowanie takich zmian ułatwia wykrycie problemu, zanim przerodzi się on w awarię odczuwalną przez użytkowników.

W codziennej pracy zespołów administracyjnych, DevOps i SRE Prometheus służy przede wszystkim do:

• kontroli zasobów infrastruktury — obserwowania wykorzystania procesora, pamięci, przestrzeni dyskowej i sieci;
• oceny jakości działania usług — śledzenia ruchu, opóźnień oraz udziału błędnych żądań;
• wykrywania niepożądanych stanów — definiowania warunków alarmowych, na przykład dla utrzymującego się wzrostu liczby błędów;
• weryfikowania skutków zmian — porównywania zachowania systemu przed wdrożeniem nowej wersji aplikacji i po nim.

Metryki zamiast logów i śladów żądań

Prometheus nie jest systemem do gromadzenia logów ani narzędziem do śledzenia przebiegu pojedynczych żądań. Metryki pokazują skalę i zmiany zjawiska, na przykład wzrost odsetka błędów. Logi mogą zawierać komunikat konkretnego wyjątku, a ślady rozproszone (distributed traces) pomagają ustalić, przez które usługi przeszło żądanie i gdzie spędziło najwięcej czasu. Te źródła informacji uzupełniają się, zamiast wzajemnie zastępować.

Rola Prometheusa polega więc na dostarczaniu mierzalnego obrazu działania systemu oraz wykrywaniu sytuacji wymagających uwagi. Sam wzrost opóźnień nie wyjaśnia jeszcze przyczyny problemu, ale wskazuje, kiedy wystąpił i których usług dotyczy. To konkretny punkt wyjścia do diagnostyki, zamiast polegania wyłącznie na zgłoszeniach użytkowników.

Model danych: metryki jako szeregi czasowe (time series) i typy metryk

Prometheus opisuje stan systemu za pomocą metryk, czyli liczbowych pomiarów takich jak zużycie pamięci, liczba obsłużonych żądań czy czas odpowiedzi aplikacji. Kolejne pomiary tej samej wielkości tworzą szereg czasowy (ang. time series). Dzięki temu można sprawdzić nie tylko aktualny stan infrastruktury, lecz także tempo zmian, trendy i momenty wystąpienia nieprawidłowości.

W najprostszym przypadku każdy punkt szeregu zawiera wartość oraz znacznik czasu. Przykładowo pomiary liczby aktywnych połączeń mogą wynosić kolejno 40, 65 i 48. Dopiero ich umiejscowienie w czasie pozwala ocenić, czy wzrost był krótkotrwały, czy utrzymywał się przez dłuższy okres. Szereg jest identyfikowany przez nazwę metryki i zestaw etykiet — dlatego pomiary tej samej wielkości dla dwóch różnych instancji aplikacji mogą tworzyć odrębne szeregi.

Cztery podstawowe typy metryk

Typ metryki określa sposób interpretacji pomiarów i to, jakie obliczenia mają dla nich sens. W Cognity często słyszymy pytania, jak praktycznie podejść do doboru metryk — odpowiadamy na nie także na blogu. W instrumentacji aplikacji dla Prometheusa stosuje się cztery podstawowe typy:

• Counter — licznik. Zlicza zdarzenia, np. obsłużone żądania, błędy lub przetworzone zadania. Jego wartość rośnie albo pozostaje bez zmian; może jednak zostać wyzerowana, np. po restarcie procesu. W monitoringu często ważniejsze od łącznej wartości jest tempo przyrostu, czyli choćby liczba żądań na sekundę.
• Gauge — wartość bieżąca. Może zarówno rosnąć, jak i maleć. Służy do opisywania aktualnego stanu: zajętej pamięci, temperatury procesora, długości kolejki czy liczby aktywnych połączeń. Pozwala ocenić poziom danej wielkości i jego zmiany.
• Histogram — rozkład obserwacji. Grupuje pomiary w przedziałach, co przydaje się m.in. do analizy czasu odpowiedzi i rozmiaru żądań. Umożliwia obliczanie średniej oraz szacowanie percentyli. Odpowiednio skonfigurowane histogramy można agregować, aby analizować wyniki wielu instancji aplikacji łącznie.
• Summary — podsumowanie obserwacji. Rejestruje liczbę i sumę pomiarów, a zależnie od konfiguracji wylicza również kwantyle po stronie aplikacji. W odróżnieniu od histogramu gotowych kwantyli z różnych instancji nie można bezpośrednio połączyć w poprawny kwantyl dla całej usługi.

Dobór typu metryki powinien wynikać z pytania, na które monitoring ma odpowiedzieć. Licznik pokaże, ile zdarzeń wystąpiło, gauge — jaki jest bieżący stan, a histogram lub summary — jak kształtują się obserwowane wartości. To istotne zwłaszcza przy analizie opóźnień: niska średnia czasu odpowiedzi może ukrywać niewielką grupę bardzo wolnych żądań, którą łatwiej zauważyć dzięki percentylom.

Scraping i endpoint /metrics: jak Prometheus zbiera dane

Prometheus zbiera metryki przede wszystkim w modelu pull: to serwer monitoringu inicjuje połączenie i w określonych odstępach pobiera dane z monitorowanych usług. Pojedynczy taki odczyt nazywa się scrape, a cykliczne odpytywanie — scrapingiem. Aplikacja nie musi więc samodzielnie wysyłać każdej zmiany do Prometheusa. Musi natomiast udostępniać metryki pod adresem, do którego serwer monitoringu ma dostęp.

Do czego służy endpoint /metrics?

Endpoint /metrics to adres HTTP lub HTTPS udostępniający metryki w formacie obsługiwanym przez Prometheusa, na przykład w tekstowym formacie ekspozycji Prometheus lub OpenMetrics. Nie jest to panel z wykresami ani strona opisująca kondycję usługi. Odpowiedź zawiera nazwy metryk, ich wartości oraz opcjonalne informacje pomocnicze, które system monitoringu potrafi automatycznie odczytać.

Ścieżka /metrics jest domyślna, ale nie obowiązkowa — w konfiguracji można wskazać inną. Samo istnienie takiego adresu również nie wystarczy: zwykła odpowiedź JSON z danymi diagnostycznymi nie staje się automatycznie źródłem metryk dla Prometheusa. Znaczenie ma zarówno dostępność endpointu, jak i zgodność formatu odpowiedzi.

Jak przebiega pojedynczy scrape?

Prometheus ustala listę celów odpytywania, czyli targetów, na podstawie konfiguracji lub mechanizmu wykrywania usług (service discovery). Następnie zgodnie z harmonogramem wysyła żądanie do każdego celu, odczytuje odpowiedź i zapisuje poprawnie pobrane próbki. Cele są odpytywane niezależnie: niedostępność jednej usługi nie zatrzymuje zbierania danych z pozostałych.

O częstotliwości pobierania decyduje scrape_interval, a maksymalny czas oczekiwania na zakończenie odczytu określa scrape_timeout. Timeout nie może być dłuższy od interwału. Krótszy interwał daje dokładniejszy obraz zmian, ale zwiększa liczbę żądań oraz ilość zbieranych danych.

Minimalny przykład konfiguracji pojedynczego celu wygląda tak:

scrape_configs:
  - job_name: 'aplikacja'
    scrape_interval: 15s
    scrape_timeout: 5s
    metrics_path: /metrics
    static_configs:
      - targets: ['localhost:8080']

W tym przykładzie Prometheus co 15 sekund odpytuje http://localhost:8080/metrics i przeznacza na odczyt maksymalnie 5 sekund. Adres localhost odnosi się do środowiska, w którym działa sam Prometheus — w kontenerze nie oznacza automatycznie hosta ani sąsiedniego kontenera.

Co oznacza nieudane pobranie metryk?

Dla odpytywanych celów Prometheus automatycznie tworzy metrykę up: wartość 1 oznacza udany scrape, a 0 — nieudany. Przyczyną błędu może być niedostępność usługi, problem sieciowy, przekroczenie timeoutu lub niepoprawna odpowiedź. Udany scrape potwierdza możliwość pobrania metryk, nie pełną sprawność aplikacji — endpoint może odpowiadać nawet wtedy, gdy użytkownicy napotykają błędy.

W odróżnieniu od modelu push, w którym źródło inicjuje wysyłkę danych, scraping wymaga dostępu sieciowego od Prometheusa do monitorowanego endpointu. Nie oznacza to konieczności wystawiania go publicznie. Dostęp warto ograniczyć do infrastruktury monitoringu, a tam, gdzie jest to potrzebne, zastosować HTTPS i uwierzytelnianie.

Eksportery i instrumentacja aplikacji: node_exporter i inne źródła metryk

Prometheus potrzebuje źródeł, które udostępniają informacje o stanie monitorowanych systemów w obsługiwanym przez niego formacie. Można je przygotować na dwa podstawowe sposoby: wykorzystać eksporter lub dodać instrumentację bezpośrednio do aplikacji. Eksporter pozwala monitorować istniejące oprogramowanie bez zmieniania jego kodu. Instrumentacja umożliwia natomiast pomiar tego, co dzieje się wewnątrz własnej aplikacji — od obsługi żądań po realizację procesów biznesowych.

Eksporter — pośrednik między systemem a Prometheusem

Eksporter to komponent, który odczytuje dane z określonego źródła, na przykład systemu operacyjnego, bazy danych lub urządzenia sieciowego, i udostępnia je jako metryki zgodne z Prometheusem. Zwykle działa jako osobny proces lub kontener. Dzięki niemu nie trzeba samodzielnie pisać integracji z każdym monitorowanym rozwiązaniem.

Nie każdy system wymaga jednak dodatkowego eksportera. Część aplikacji i usług ma już wbudowaną obsługę metryk Prometheusa. Przed wdrożeniem kolejnego komponentu warto więc sprawdzić, co udostępnia samo oprogramowanie.

node_exporter — podstawowe metryki serwera

node_exporter służy do monitorowania sprzętu i systemów operacyjnych z rodziny Unix, przede wszystkim Linuksa. Udostępnia między innymi dane o czasie pracy CPU, pamięci RAM, dostępnej przestrzeni w systemach plików, operacjach dyskowych i ruchu sieciowym. Zazwyczaj uruchamia się go na każdym hoście, który ma zostać objęty takim monitoringiem. Dla systemów Windows podobną rolę pełni windows_exporter.

Te pomiary pomagają ustalić, czy serwerowi brakuje zasobów, ale nie wyjaśniają samodzielnie wszystkich problemów aplikacji. Wysokie wykorzystanie procesora nie mówi jeszcze, która operacja je powoduje. Z kolei poprawne parametry hosta nie gwarantują, że użytkownicy mogą się zalogować lub złożyć zamówienie. Do takiej oceny potrzebne są dodatkowe źródła danych.

Inne eksportery i źródła metryk

Dobór integracji zależy od monitorowanego środowiska. W Cognity omawiamy dobór źródeł metryk zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników szkoleń. Najczęściej spotykane przykłady takich źródeł to:

• postgres_exporter i mysqld_exporter — udostępniają statystyki baz PostgreSQL i MySQL, na przykład dotyczące połączeń oraz aktywności bazy.
• snmp_exporter — pozwala pozyskiwać metryki z urządzeń obsługujących SNMP, takich jak przełączniki i routery.
• blackbox_exporter — wykonuje testy z zewnątrz, między innymi HTTP, TCP i ICMP. Pomaga sprawdzić dostępność usługi, a nie tylko stan maszyny, na której działa.
• cAdvisor i kube-state-metrics — dostarczają różnych informacji o środowiskach kontenerowych. cAdvisor pokazuje wykorzystanie zasobów przez kontenery, a kube-state-metrics udostępnia stan obiektów Kubernetes, na przykład liczbę dostępnych replik.

Instrumentacja — pomiary wewnątrz aplikacji

Instrumentacja polega na dodaniu do kodu pomiarów przy użyciu biblioteki klienckiej Prometheusa, dostępnej między innymi dla Go, Javy i Pythona. Programista określa, jakie zdarzenia i operacje mają być mierzone. Mogą to być liczba błędów płatności, czas obsługi żądania czy liczba zadań oczekujących na przetworzenie.

Eksportery i instrumentacja uzupełniają się, zamiast wzajemnie zastępować. node_exporter pokaże presję na zasoby serwera, eksporter bazy — jej aktywność, a pomiary w kodzie — wpływ tych warunków na działanie aplikacji. Przy wyborze eksportera warto sprawdzić jego zgodność z wersją monitorowanego systemu, aktualność projektu i wymagane uprawnienia dostępu.

Etykiety (labels), selekcja metryk i przechowywanie danych (retencja, TSDB)

Sama nazwa metryki nie zawsze wystarcza, aby ustalić, którego elementu infrastruktury dotyczy wynik. Tę informację uzupełniają etykiety (labels), czyli pary klucz–wartość przypisane do szeregu czasowego. Pozwalają odróżnić dane pochodzące z różnych instancji usługi, środowisk czy endpointów, a następnie wybrać do analizy tylko potrzebny fragment.

Etykiety jako kontekst danych

W Prometheusie nazwa metryki wraz z kompletnym zestawem etykiet identyfikuje konkretny szereg czasowy. Zmiana wartości choćby jednej etykiety oznacza więc inny szereg, a nie aktualizację opisu istniejącego. Przykładowo liczba żądań HTTP może być rejestrowana osobno dla każdej kombinacji metody i kodu odpowiedzi:

http_requests_total{method="GET", status="200"}
http_requests_total{method="GET", status="500"}

Oba zapisy odnoszą się do tej samej metryki, ale opisują różne grupy żądań. W praktyce często spotkasz również etykiety job, identyfikującą skonfigurowane zadanie zbierania danych, oraz instance, wskazującą konkretny monitorowany cel. Dodatkowe etykiety, takie jak environment czy service, warto nazywać i stosować konsekwentnie. Dzięki temu te same filtry można wykorzystywać w wielu zapytaniach i widokach monitoringu.

Selekcja metryk za pomocą etykiet

W języku zapytań PromQL warunki dotyczące etykiet zapisuje się w nawiasach klamrowych po nazwie metryki. Poniższy selektor wybiera szeregi z zadania api, które dotyczą odpowiedzi HTTP 500:

http_requests_total{job="api", status="500"}

Warunki rozdzielone przecinkami muszą być spełnione jednocześnie. Dostępne są cztery podstawowe operatory dopasowania:

• = — wartość dokładnie równa wskazanemu tekstowi;
• != — wartość inna niż wskazany tekst;
• =~ — wartość zgodna z wyrażeniem regularnym;
• !~ — wartość niezgodna z wyrażeniem regularnym.

Przykładowo status=~"5[0-9]{2}" pozwala wybrać wszystkie trzycyfrowe kody odpowiedzi z grupy 5xx. Dopasowanie wyrażenia regularnego obejmuje całą wartość etykiety. Selektor jedynie wybiera dane — nie sumuje wyników ani nie oblicza tempa zmian. Takie operacje wymagają dodatkowych wyrażeń PromQL.

TSDB i retencja: gdzie trafiają dane i jak długo pozostają dostępne

Prometheus zapisuje próbki w lokalnej bazie szeregów czasowych TSDB (Time Series Database). Najnowsze dane obsługuje w aktywnej części bazy, a starsze organizuje w skompresowane bloki na dysku. Dziennik WAL (Write-Ahead Log) pomaga odtworzyć najnowsze zapisy po restarcie, ale nie zastępuje kopii zapasowej.

O długości dostępnej historii decyduje retencja. Parametr --storage.tsdb.retention.time określa okres przechowywania danych, na przykład 30d. Z kolei --storage.tsdb.retention.size pozwala ustawić limit rozmiaru. Jeżeli obowiązują oba ograniczenia, usuwanie najstarszych bloków uruchamia to, które zostanie osiągnięte wcześniej. Gdy nie ustawiono żadnego z nich, domyślna retencja czasowa wynosi 15 dni.

Retencja nie zmniejsza szczegółowości starszych pomiarów — lokalny Prometheus nie zamienia ich automatycznie w rzadsze próbki. Usuwa całe przestarzałe bloki, dlatego zwolnienie miejsca nie musi nastąpić dokładnie w chwili przekroczenia progu. Okres przechowywania warto dobrać do potrzeb diagnostycznych, a limit rozmiaru ustawić z zapasem miejsca na WAL i bieżącą pracę bazy. Sama konfiguracja retencji nie jest twardym limitem zajętości całego katalogu danych.

Typowa architektura: Prometheus + exporters + Alertmanager + Grafana

W typowym środowisku Prometheus nie działa sam. Towarzyszą mu komponenty udostępniające metryki, obsługujące powiadomienia i prezentujące dane na wykresach. Każdy element ma odrębną odpowiedzialność: Prometheus zbiera i analizuje dane, eksportery udostępniają je z monitorowanych systemów, Alertmanager zarządza powiadomieniami, a Grafana zapewnia widok sytuacji na dashboardach.

Jak współpracują te elementy?

Przepływ zaczyna się od monitorowanej infrastruktury i aplikacji. Prometheus pobiera udostępniane przez nie metryki — bezpośrednio lub za pośrednictwem eksporterów. Zebrane dane służą następnie dwóm głównym celom: analizie na dashboardach oraz automatycznemu wykrywaniu problemów.

W pierwszym przypadku Grafana wysyła zapytania do Prometheusa, a otrzymane wyniki zamienia w wykresy, tabele i wskaźniki. Grafana nie zastępuje tu bazy metryk i nie musi pośredniczyć w ich zbieraniu. Niedostępność jej interfejsu nie zatrzymuje pracy Prometheusa ani obsługi alertów przez Alertmanager.

Drugi przepływ dotyczy alarmowania. To Prometheus ocenia skonfigurowane reguły i przekazuje aktywne alerty do Alertmanagera. Alertmanager nie sprawdza samodzielnie wartości metryk: odpowiada za grupowanie alertów, ograniczanie powtarzających się powiadomień, wyciszenia oraz kierowanie komunikatów do odpowiednich odbiorców. Ten podział oddziela wykrycie nieprawidłowości od organizacji powiadomień.

Przykład: wzrost liczby błędów aplikacji

Aplikacja udostępnia metryki żądań HTTP, które Prometheus regularnie pobiera. Jeżeli odsetek odpowiedzi z błędami przekracza ustalony próg przez czas określony w regule, Prometheus przekazuje alert do Alertmanagera. Ten może połączyć powiązane alerty w jedno powiadomienie i skierować je do zespołu odpowiedzialnego za usługę. Osoba diagnozująca problem otwiera dashboard Grafany, aby porównać błędy z natężeniem ruchu i czasem odpowiedzi.

Nie każde wdrożenie wymaga od razu wszystkich tych komponentów. Prometheus ma własny interfejs do wykonywania zapytań, więc Grafana jest rozszerzeniem możliwości wizualizacji, a nie warunkiem zbierania danych. Grafana oferuje również własny mechanizm alertowania; jeśli jest używany równolegle, warto jasno ustalić, gdzie definiowane są reguły i kto odpowiada za powiadomienia, aby uniknąć dublowania alarmów.

Kiedy Prometheus się sprawdza, a kiedy ma ograniczenia?

Prometheus sprawdza się przede wszystkim w bieżącym monitorowaniu kondycji infrastruktury i aplikacji. Pomaga wykrywać wzrost liczby błędów, wydłużenie czasu odpowiedzi czy zbliżające się wyczerpanie zasobów. Jest szczególnie przydatny w środowiskach kontenerowych, Kubernetes i architekturze mikroserwisowej, ale równie dobrze może monitorować tradycyjne serwery. O jego przydatności decyduje nie sam rodzaj środowiska, lecz to, czy na podstawie metryk można rozpoznać problem i podjąć działanie.

Nie zastępuje jednak wszystkich narzędzi obserwowalności. Metryki pozwalają zauważyć, że usługa zwolniła, ale ustalenie przyczyny konkretnego nieudanego żądania często wymaga także logów i śledzenia rozproszonego. Prometheus nie jest również systemem do bezstratnej ewidencji zdarzeń, dlatego nie powinien być jedynym źródłem danych do rozliczania transakcji czy prowadzenia audytu.

Skalowanie: znaczenie ma obciążenie, nie tylko liczba serwerów

Pojedyncza instancja Prometheusa może obsłużyć wiele źródeł danych, lecz jej możliwości zależą między innymi od liczby aktywnych szeregów czasowych, częstotliwości zbierania próbek i kosztu wykonywanych zapytań. Samo zwiększenie liczby monitorowanych maszyn nie mówi więc jeszcze, jak szybko wzrosną wymagania dotyczące pamięci, procesora i dysku.

Gdy jedna instancja przestaje wystarczać, można podzielić monitorowane cele między kilka instancji. Prometheus nie tworzy jednak automatycznie klastra, który wspólnie przechowuje dane i równoważy obciążenie. Przy potrzebie globalnego widoku, długiego przechowywania historii lub większej skali wykorzystuje się dodatkowe rozwiązania, takie jak Thanos czy Grafana Mimir. Oznacza to także więcej elementów wymagających utrzymania.

Wysoka dostępność: dwie instancje to dopiero początek

Typowe podejście do wysokiej dostępności, czyli HA, polega na uruchomieniu dwóch niezależnych instancji Prometheusa monitorujących te same cele. Awaria jednej nie zatrzymuje wtedy zbierania danych przez drugą. Nie jest to jednak replikacja wspólnej bazy danych: każda instancja zapisuje własne próbki. Trzeba dodatkowo zaplanować dostęp do wyników podczas awarii, obsługę zduplikowanych danych oraz dostępność całej ścieżki powiadamiania, w tym Alertmanagera.

Kardynalność: mały szczegół, duży koszt

Jednym z najczęstszych źródeł problemów jest wysoka kardynalność, czyli duża liczba unikalnych kombinacji etykiet. Identyfikator użytkownika, identyfikator żądania czy pełny adres URL z dynamicznymi parametrami mogą powodować gwałtowny przyrost liczby szeregów. Skutkiem bywa większe zużycie pamięci i miejsca na dysku, wolniejsze zapytania, a w skrajnych przypadkach niestabilność monitoringu.

Dlatego warto mierzyć zjawiska na poziomie potrzebnym do decyzji operacyjnych: według usługi, rodzaju operacji czy klasy odpowiedzi, zamiast osobno dla każdego użytkownika lub żądania. Prometheus jest dobrym wyborem, gdy potrzebujesz szybkiego wykrywania problemów na podstawie metryk i możesz kontrolować ich zakres. Wymagania dotyczące bezstratności, wieloletniej historii lub monitorowania wielu dużych środowisk wymagają już szerszej architektury, a nie tylko uruchomienia kolejnej instancji.

Praktyka: przykładowa konfiguracja scrape, przykładowe metryki i checklista wdrożeniowa

Pierwsze wdrożenie warto ograniczyć do dwóch źródeł: samego Prometheusa oraz jednego serwera z uruchomionym node_exporterem. Taki zestaw pozwala sprawdzić cały proces — od dostępności endpointu po pojawienie się danych i wywołanie próbnego alertu — bez podłączania od razu całej infrastruktury. W Cognity łączymy teorię z praktyką — dlatego zagadnienia monitorowania infrastruktury rozwijamy także w formie ćwiczeń na szkoleniach.

Przykładowa konfiguracja zbierania danych — opis ustawień

W pliku prometheus.yml ustaw globalny interwał zbierania danych, czyli scrape_interval, na 15 sekund, a limit czasu pojedynczego odczytu, scrape_timeout, na 10 sekund. To przykładowe wartości startowe do testów, nie uniwersalne zalecenie dla każdego środowiska. Timeout nie może przekraczać interwału zbierania danych.

W części scrape_configs zdefiniuj dwa zadania. Pierwsze, nazwane prometheus, powinno wskazywać adres własnego serwera Prometheus na porcie 9090. Drugie, node, skieruj na adres monitorowanego hosta i port 9100, na którym domyślnie działa node_exporter. Przy statycznej konfiguracji adresy wpisuje się jako cele w static_configs. Dla obu źródeł można pozostawić domyślną ścieżkę /metrics, o ile nie została zmieniona po stronie usług.

Adres celu musi być osiągalny z miejsca, w którym działa Prometheus. Jeśli uruchamiasz go w kontenerze, localhost oznacza ten kontener, a nie automatycznie host ani inny kontener. To jedna z pierwszych rzeczy do sprawdzenia, gdy usługa działa, ale zbieranie danych kończy się błędem.

Przed zastosowaniem zmian zweryfikuj plik narzędziem promtool. Następnie przeładuj konfigurację obsługiwaną metodą lub zrestartuj usługę. W widoku Targets sprawdź, czy oba cele mają status UP. Jeśli któryś pozostaje niedostępny, odczytaj komunikat błędu — pomoże odróżnić problem z adresem, połączeniem, uwierzytelnianiem lub formatem odpowiedzi.

Przykładowe metryki do pierwszej weryfikacji

Zacznij od metryki up, tworzonej przez Prometheusa dla monitorowanych celów. Wartość 1 oznacza udany odczyt, a 0 — nieudany. Nie traktuj jej jednak jako potwierdzenia, że aplikacja poprawnie obsługuje użytkowników: dostępny endpoint metryk może działać także podczas awarii funkcji biznesowej.

Dla serwera z node_exporterem sprawdź node_memory_MemAvailable_bytes. Przykładowa wartość 2147483648 oznacza 2 GiB pamięci dostępnej według systemowego oszacowania. Z kolei node_cpu_seconds_total nie pokazuje bezpośrednio procentowego obciążenia procesora. Do oceny bieżącego wykorzystania CPU potrzebna jest analiza tempa przyrostu tej metryki w wybranym przedziale czasu.

Checklista przed objęciem monitoringiem kolejnych usług

• Sprawdź dostępność z właściwego miejsca. Potwierdź połączenie do endpointów z hosta lub kontenera Prometheusa, nie tylko ze swojego komputera.
• Zweryfikuj świeżość danych. Upewnij się, że pojawiają się kolejne próbki, a widoczne wartości nie pochodzą wyłącznie z wcześniejszego, udanego odczytu.
• Ustal jednoznaczną identyfikację celów. Nazwy zadań i oznaczenia środowiska powinny pozwalać bez wątpliwości rozpoznać monitorowaną usługę.
• Ogranicz dostęp sieciowy. Nie wystawiaj endpointów metryk ani interfejsu Prometheusa publicznie bez odpowiednich zabezpieczeń.
• Sprawdź miejsce na dane. Zapewnij trwały wolumen i zapas pojemności; sama działająca usługa nie gwarantuje zachowania historii po odtworzeniu kontenera.
• Przetestuj powiadomienia. W kontrolowanych warunkach przerwij dostęp do testowego celu i sprawdź zarówno wykrycie problemu, jak i dostarczenie alertu do właściwego odbiorcy.
• Zapisz procedurę obsługi. Ustal, kto reaguje na alert, gdzie sprawdza szczegóły i jak przywraca poprzednią konfigurację po nieudanej zmianie.

Alerty w Grafanie i Prometheusie – jak automatycznie wykrywać awarie i problemy z wydajnością? 22 listopada 2026

Najczęstsze błędy podczas projektowania baz danych w Access i jak ich unikać. 20 listopada 2026