Grafana i Prometheus – jak połączyć oba narzędzia i stworzyć pierwszy dashboard?

Wymagania i warianty uruchomienia Grafany i Prometheusa

Przed uruchomieniem narzędzi ustal, co ma pokazywać pierwszy dashboard: stan pojedynczego serwera, środowiska kontenerowego czy klastra Kubernetes. Od tego zależą sposób wdrożenia i źródła metryk. Prometheus zbiera i przechowuje metryki, a Grafana służy do ich odpytywania i wizualizacji. Samo uruchomienie obu aplikacji nie wystarczy więc do obserwowania obciążenia systemu — potrzebne jest jeszcze źródło danych, na przykład eksporter metryk hosta.

Co przygotować przed rozpoczęciem?

Do ćwiczenia potrzebujesz środowiska, w którym możesz uruchamiać usługi, przeglądarki do obsługi Grafany oraz komunikacji sieciowej między komponentami. Grafana musi mieć dostęp do Prometheusa, a Prometheus — do punktów udostępniających metryki. Domyślne porty usług to odpowiednio 3000 i 9090; sprawdź, czy nie zajmują ich inne procesy. Na potrzeby nauki nie wystawiaj tych usług bezpośrednio do internetu.

Zaplanuj również miejsce na dane. Prometheus zapisuje szeregi czasowe na dysku, natomiast Grafana przechowuje między innymi konfigurację i definicje dashboardów. W środowiskach kontenerowych dane te powinny znajdować się w trwałych wolumenach, jeśli mają przetrwać odtworzenie kontenera lub poda. Zapotrzebowanie na RAM, CPU i przestrzeń dyskową zależy przede wszystkim od liczby aktywnych szeregów czasowych, częstotliwości zbierania próbek i okresu ich przechowywania. Do pierwszej próby ogranicz zakres monitorowania do jednego hosta lub niewielkiej części klastra.

Lokalnie: najprostsze środowisko do poznania podstaw

Uruchomienie Grafany i Prometheusa bezpośrednio w systemie pozwala poznać ich działanie bez dodatkowej warstwy kontenerów. Potrzebujesz pakietów lub plików wykonywalnych odpowiednich dla systemu operacyjnego i architektury procesora oraz uprawnień do uruchomienia aplikacji i zapisu danych. To dobry wybór do nauki albo monitorowania pojedynczej maszyny.

Jeśli chcesz odtworzyć typowy scenariusz monitorowania serwera z użyciem Node Exportera, wygodnym punktem wyjścia będzie Linux, również w maszynie wirtualnej. Dla Windows stosuje się inne źródło metryk systemowych, na przykład windows_exporter; nazwy i zakres dostępnych metryk będą się różnić.

Docker: powtarzalny zestaw do testów

Docker ułatwia uruchomienie odizolowanego zestawu usług i jego późniejsze odtworzenie. Przygotuj działający silnik Docker, a jeśli chcesz zarządzać całością wspólnie — także Docker Compose. Ten wariant sprawdza się w lokalnym laboratorium i środowisku deweloperskim.

Najważniejsze kwestie do zaplanowania to wspólna sieć usług, dostęp do portów oraz trwałe wolumeny. Pamiętaj, że localhost wewnątrz kontenera oznacza ten kontener, a nie komputer gospodarza ani sąsiednią usługę. Ustal też, czy interesują Cię zasoby hosta, czy kontenerów — sposób udostępnienia metryk musi odpowiadać temu wyborowi.

Kubernetes: monitoring zasobów klastra

Ten wariant wybierz, gdy masz już klaster i chcesz obserwować jego węzły, pody oraz obiekty aplikacyjne. Potrzebujesz dostępu przez kubectl i uprawnień pozwalających wdrożyć komponenty monitoringu. Zależnie od wybranej metody instalacji przydatny będzie Helm; popularnym rozwiązaniem jest zestaw kube-prometheus-stack, obejmujący między innymi Prometheusa, Grafanę i komponenty zbierające metryki.

Kubernetes wymaga dodatkowo zaplanowania przestrzeni nazw, uprawnień i trwałego przechowywania danych. Nie warto wprowadzać go wyłącznie po to, by zbudować pierwszy dashboard dla jednego serwera — lokalne uruchomienie lub Docker będzie wtedy prostsze.

Wstępna lista metryk do pierwszego dashboardu

Na początek wybierz niewielki zestaw odpowiadający na konkretne pytania o kondycję środowiska:

• Dostępność źródeł metryk: czy Prometheus może pobierać z nich dane. Udany odczyt nie oznacza jeszcze, że wszystkie funkcje aplikacji działają poprawnie.
• CPU: wykorzystanie procesora i zmiany obciążenia w czasie.
• RAM: pamięć dostępna dla aplikacji oraz wykorzystanie pamięci wymiany, jeśli jest używana.
• Dysk: wolne miejsce w systemach plików; w razie potrzeby także aktywność odczytu i zapisu.
• Sieć: ruch przychodzący i wychodzący oraz błędy interfejsów.
• Dla Kubernetes: gotowość węzłów i podów, restarty kontenerów oraz zgodność liczby dostępnych replik z oczekiwaną.

Metryki hosta zwykle dostarcza eksporter systemowy. W Kubernetes informacje o stanie obiektów udostępnia kube-state-metrics, natomiast pomiary zużycia zasobów kontenerów pochodzą z innych źródeł, między innymi kubeleta i cAdvisor. Rozróżnienie tych danych pozwala od początku dobrać źródła do pytań, na które ma odpowiadać dashboard.

Instalacja i konfiguracja Prometheusa oraz weryfikacja zbierania metryk

Prometheus sam pobiera metryki z monitorowanych usług w modelu pull: w ustalonych odstępach odpytuje ich endpointy HTTP, najczęściej pod ścieżką /metrics. Konfiguracja musi więc wskazywać nie tylko adres źródła danych, lecz także sposób dotarcia do niego. W Cognity często słyszymy pytania, jak poprawnie skonfigurować zbieranie metryk i zweryfikować, czy Prometheus rzeczywiście je pobiera — odpowiadamy na nie także na blogu. Na tym etapie celem jest uruchomienie serwera i potwierdzenie, że regularnie zbiera próbki z wybranych źródeł.

Uruchomienie serwera Prometheus

Przy instalacji bezpośrednio w systemie pobierz oficjalne wydanie Prometheusa odpowiednie dla systemu operacyjnego i architektury procesora, rozpakuj je, a następnie uruchom serwer, wskazując plik prometheus.yml oraz katalog danych. Konto, na którym działa proces, musi mieć prawo odczytu konfiguracji i zapisu w tym katalogu. Jeśli serwer ma działać stale, skonfiguruj go jako usługę systemową, zamiast pozostawiać proces uruchomiony w terminalu.

W Dockerze skorzystaj z oficjalnego obrazu prom/prometheus. Podłącz własny plik konfiguracyjny i trwały wolumen na dane oraz zapewnij dostęp do interfejsu HTTP, który domyślnie działa na porcie 9090. Warto przypiąć konkretną wersję obrazu, aby aktualizacja nie następowała przypadkowo przy ponownym wdrożeniu.

W Kubernetes częstym wyborem jest chart Helm kube-prometheus-stack, obejmujący Prometheus Operator oraz komponenty monitoringu. W tym wariancie konfiguracją zarządza operator, a źródła metryk zwykle definiuje się przez zasoby ServiceMonitor lub PodMonitor. Nie edytuj ręcznie wygenerowanego pliku konfiguracji — zmiany wprowadzaj w zasobach Kubernetes lub wartościach chartu. Samo utworzenie monitora nie wystarczy: musi on pasować do selektorów i zakresu namespace’ów obserwowanych przez daną instancję Prometheusa.

Targets i konfiguracja odpytywania

W samodzielnej instalacji najważniejszą częścią pliku prometheus.yml jest lista scrape_configs. Każdy jej wpis opisuje zadanie zbierania metryk: zawiera nazwę job_name oraz określa sposób odnajdywania źródeł. Przy prostej konfiguracji statycznej adresy podaje się w static_configs, na liście targets, jako host i port. Protokół oraz ścieżkę endpointu ustawia się osobno; domyślnie są to HTTP i /metrics.

Częstotliwość pobierania danych określa scrape_interval, a maksymalny czas pojedynczego żądania — scrape_timeout. Ustawienia globalne można nadpisywać dla poszczególnych zadań, przy czym timeout nie może przekraczać interwału odpytywania. Na początek warto pozostawić również zadanie zbierające metryki samego Prometheusa: pomaga ono potwierdzić poprawne działanie podstawowej konfiguracji.

Adres targetu musi być osiągalny z miejsca, w którym działa Prometheus. W kontenerze localhost oznacza ten kontener, a nie komputer gospodarza ani sąsiednią usługę. Między kontenerami korzystaj z nazw usług we wspólnej sieci, a w Kubernetes — z mechanizmów wykrywania usług i adresacji klastra.

Node Exporter i kube-state-metrics: różne źródła danych

• Node Exporter udostępnia metryki systemowe hosta, m.in. dotyczące procesora, pamięci, systemów plików i interfejsów sieciowych. Domyślnie nasłuchuje na porcie 9100. Uruchom go na monitorowanym hoście i dodaj jego adres jako target. W kontenerze wymaga odpowiedniego dostępu do zasobów hosta — samo uruchomienie obrazu nie zapewnia poprawnego monitorowania całej maszyny.
• kube-state-metrics odczytuje stan obiektów z API Kubernetes i udostępnia go w postaci metryk, np. liczby replik Deploymentu czy fazy życia Poda. Wymaga odpowiednich uprawnień RBAC. Nie mierzy bieżącego zużycia CPU ani RAM przez kontenery i nie zastępuje Node Exportera.

Jeśli korzystasz z kube-prometheus-stack, sprawdź, które eksportery i monitory są już włączone w konfiguracji wdrożenia. Ponowna instalacja tych samych komponentów może prowadzić do zbędnego, podwójnego zbierania danych.

Jak potwierdzić, że Prometheus zbiera metryki?

Przed zastosowaniem zmian sprawdź plik konfiguracji narzędziem promtool. Następnie zrestartuj serwer lub przeładuj konfigurację obsługiwanym mechanizmem. Przeładowanie przez HTTP wymaga wcześniejszego włączenia obsługi cyklu życia; nie należy zakładać, że jest domyślnie dostępne.

Otwórz interfejs Prometheusa i przejdź do widoku Targets. Sprawdź obecność oczekiwanych endpointów, czas ostatniego pobrania oraz status UP. Oznacza on udane pobranie i przetworzenie metryk, ale nie potwierdza jeszcze, że eksporter udostępnia wszystkie potrzebne dane. W przeglądarce zapytań wyszukaj więc konkretną metrykę, np. node_memory_MemAvailable_bytes dla hosta z Linuksem lub kube_pod_info dla Kubernetes, i sprawdź, czy pojawiają się aktualne próbki.

Przy statusie DOWN zacznij od komunikatu błędu przy targecie. Zweryfikuj adres, port, rozwiązywanie nazw, reguły sieciowe oraz ewentualne wymagania TLS i uwierzytelniania. Endpoint /metrics testuj z tej samej sieci co Prometheus — dostępność w przeglądarce na Twoim komputerze nie dowodzi, że serwer monitoringu również może go odpytać.

3. Instalacja Grafany i pierwsze logowanie: podstawowe ustawienia, organizacje i użytkownicy

Grafanę instalujesz niezależnie od Prometheusa. Na tym etapie celem jest uruchomienie interfejsu, zabezpieczenie konta administratora i przygotowanie dostępu dla użytkowników. Połączenie ze źródłem metryk nie jest jeszcze potrzebne.

Uruchomienie Grafany i dostęp do interfejsu

Do pierwszego dashboardu wystarczy Grafana OSS. Jeśli pracujesz w Dockerze, możesz uruchomić ją poniższym poleceniem:

docker run -d \
  --name grafana \
  -p 127.0.0.1:3000:3000 \
  -v grafana-data:/var/lib/grafana \
  --restart unless-stopped \
  grafana/grafana:latest

Interfejs będzie dostępny pod adresem http://localhost:3000 na komputerze, na którym działa Docker. Powiązanie portu z 127.0.0.1 ogranicza dostęp do tego hosta — to bezpieczniejszy punkt wyjścia niż udostępnienie panelu w całej sieci. Na zdalnym serwerze możesz skorzystać z tunelu SSH. Tag latest jest wygodny do testów; w stałym środowisku przypnij konkretną, sprawdzoną wersję obrazu.

Wolumen grafana-data zachowuje dane po usunięciu kontenera, w tym dashboardy, konta i ustawienia przechowywane w domyślnej bazie SQLite. Nie zastępuje jednak kopii zapasowej. W Kubernetes analogiczną trwałość należy zapewnić przez odpowiednio skonfigurowany PVC, jeśli korzystasz z lokalnej bazy danych Grafany.

Przy instalacji bez kontenerów pobierz pakiet z oficjalnego źródła Grafany, zgodny z systemem. W dystrybucji Linux korzystającej z systemd, po zainstalowaniu pakietu usługę uruchomisz poleceniem sudo systemctl enable --now grafana-server. Jeśli strona się nie otwiera, sprawdź stan usługi i jej logi; w Dockerze zacznij od docker logs grafana.

Pierwsze logowanie i podstawowe ustawienia

W świeżej instalacji, bez nadpisanej konfiguracji administratora, domyślny login i hasło to admin / admin. Po zalogowaniu Grafana poprosi o zmianę hasła. Ustaw unikalne, silne hasło i nie używaj tego konta jako wspólnego loginu zespołu. Jeśli wdrożenie korzysta z istniejącego wolumenu lub sekretu ustawiającego dane administratora, domyślne dane mogą nie obowiązywać.

Przed rozpoczęciem pracy sprawdź kilka ustawień:

• Strefa czasowa: wybierz w preferencjach użytkownika czas przeglądarki albo UTC. W zespołach pracujących w różnych lokalizacjach UTC ułatwia porównywanie zdarzeń. Poszczególne dashboardy mogą mieć własne ustawienie strefy.
• Rejestracja i dostęp anonimowy: pozostaw je wyłączone, jeśli nie masz konkretnego powodu, aby je udostępniać. Dostęp przyznawaj świadomie wskazanym osobom.
• Adres publiczny i HTTPS: jeśli Grafana działa za reverse proxy, skonfiguruj właściwy root_url, a w razie publikacji w podścieżce również ustawienia obsługi tej ścieżki. Zdalne logowanie powinno odbywać się przez HTTPS.

W instalacji pakietowej konfiguracja zwykle znajduje się w /etc/grafana/grafana.ini. W kontenerze te same opcje można przekazywać zmiennymi środowiskowymi, na przykład GF_USERS_ALLOW_SIGN_UP=false. Zmiany konfiguracji serwera zazwyczaj wymagają restartu; preferencje zapisane w interfejsie nie wymagają ponownego uruchomienia usługi.

Organizacje, użytkownicy i role

Organizacja w Grafanie jest logicznym obszarem pracy z własnymi dashboardami, źródłami danych i członkostwem użytkowników. Na początek wystarczy organizacja domyślna. Kolejne warto tworzyć, gdy potrzebujesz rozdzielić takie zasoby między niezależne grupy; nie ma potrzeby zakładania organizacji dla każdego dashboardu.

Podstawowe role organizacyjne określają zakres pracy użytkownika:

• Viewer — przegląda udostępnione dashboardy, bez zapisywania zmian.
• Editor — tworzy i edytuje dashboardy w granicach przyznanych uprawnień.
• Admin — zarządza organizacją, jej użytkownikami i konfiguracją zasobów, w tym źródłami danych.

Rola administratora organizacji nie jest tym samym co uprawnienie administratora serwera Grafany, obejmujące całą instancję. Jedna osoba może należeć do kilku organizacji i mieć w każdej inną rolę. Przy nadawaniu dostępu stosuj zasadę najmniejszych uprawnień: odbiorcom wykresów zwykle wystarczy Viewer, a osobom budującym dashboardy — Editor. Własne konto każdego użytkownika ułatwia zarządzanie dostępem i jego późniejsze odebranie.

4. Dodanie Prometheusa jako Data Source w Grafanie i test połączenia

Grafana pobiera dane z Prometheusa przez jego API HTTP. Nie trzeba kopiować metryk ani konfigurować ich wysyłania do Grafany — wystarczy dodać źródło danych, wskazać właściwy adres i ustawić sposób uwierzytelniania. Najważniejsza zasada: adres Prometheusa musi być osiągalny z serwera Grafany, nie tylko z przeglądarki użytkownika.

W Cognity omawiamy konfigurację połączenia Grafany z Prometheusem zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników szkoleń.

Dodaj źródło danych i ustaw URL

W menu Grafany przejdź do Connections → Data sources → Add data source, a następnie wybierz Prometheus. Nazwy i położenie opcji mogą się nieznacznie różnić zależnie od wersji. Nadaj źródłu czytelną nazwę, która pozwoli odróżnić je od innych środowisk. Jeżeli będzie głównym źródłem metryk, możesz oznaczyć je jako domyślne.

W polu Prometheus server URL wpisz bazowy adres usługi. Nie dopisuj końcówki /metrics ani /api/v1/query: pierwsza służy do udostępniania metryk, a ścieżki API Grafana dobiera samodzielnie.

Jeśli Prometheus jest dostępny przez reverse proxy pod dodatkową ścieżką, uwzględnij ją w adresie bazowym. Przy połączeniu między różnymi hostami lub spoza klastra sprawdź również routing, reguły zapory i ewentualne NetworkPolicy.

Uwierzytelnianie i TLS

Ustawienia autoryzacji muszą odpowiadać zabezpieczeniom endpointu Prometheusa lub stojącego przed nim proxy. Samo logowanie użytkownika do Grafany nie uwierzytelnia automatycznie połączenia Grafana–Prometheus.

• Bez uwierzytelniania — odpowiednie dla odizolowanego środowiska testowego, jeśli endpoint rzeczywiście nie wymaga poświadczeń. Nie oznacza to, że można bezpiecznie wystawić go publicznie.
• Basic authentication — włącz, gdy endpoint oczekuje loginu i hasła. Poświadczenia przesyłaj przez HTTPS.
• Token w nagłówku — jeśli wymaga go warstwa dostępowa, skonfiguruj nagłówek HTTP, na przykład Authorization z wartością Bearer TOKEN. Token wpisz w przeznaczonym do tego polu konfiguracji, nie w URL.
• TLS i certyfikaty — dla prywatnego urzędu certyfikacji dodaj właściwy certyfikat CA; jeśli endpoint wymaga mTLS, skonfiguruj także certyfikat i klucz klienta.

Nie traktuj wyłączenia weryfikacji certyfikatu jako docelowego rozwiązania błędów HTTPS. Lepiej poprawić łańcuch zaufania lub użyć nazwy hosta zgodnej z certyfikatem.

Timeout i test połączenia

W ustawieniach HTTP sprawdź Timeout, czyli limit oczekiwania na odpowiedź. Jeśli pole jest dostępne, na początek możesz ustawić przykładowo 30 sekund, zgodnie z jednostką podaną w interfejsie. To wartość startowa, nie uniwersalna rekomendacja. Osobny Query timeout, jeśli występuje, dotyczy czasu wykonania zapytania po stronie Prometheusa; limity reverse proxy również mogą przerwać żądanie wcześniej.

Kliknij Save & test. Pozytywny wynik potwierdza poprawność podstawowej komunikacji z API, ale nie gwarantuje obecności wszystkich potrzebnych metryk. Przy błędzie sprawdź jego rodzaj: connection refused zwykle wskazuje niewłaściwy port lub niedostępną usługę, 401/403 — problem z uwierzytelnianiem lub uprawnieniami, a błąd x509 — problem z certyfikatem. Timeout wymaga sprawdzenia sieci i czasu odpowiedzi, nie tylko zwiększenia limitu.

Przeglądanie metryk po etykietach

Po zapisaniu źródła otwórz Explore i wybierz dodanego Prometheusa. W edytorze zapytań skorzystaj z trybu Builder lub dostępnej przeglądarki metryk. Label-based browsing pozwala zawężać serie według etykiet, takich jak job, instance czy — jeśli występują w danych — namespace.

Wybierz dostępną metrykę, dodaj filtr etykiety i uruchom zapytanie. Dzięki temu sprawdzisz nie tylko połączenie, lecz także odczyt rzeczywistych danych. Brak wyników nie musi oznaczać awarii źródła: przyczyną może być zbyt wąski zakres czasu, nieistniejąca wartość etykiety albo brak wybranej metryki. Takie filtrowanie służy do eksploracji danych i nie jest jeszcze konfiguracją zmiennych dashboardu.

Budowa pierwszego dashboardu: struktura, zakres czasu, jednostki i legendy

Pierwszy dashboard w Grafanie powinien odpowiadać na kilka konkretnych pytań, a nie prezentować wszystkie dostępne metryki. Czy monitorowane zasoby działają prawidłowo? Co zmieniło się w ostatnim czasie? Który host lub komponent wymaga sprawdzenia? Taki punkt wyjścia ułatwia wybór paneli i chroni przed stworzeniem widoku, który zawiera dużo danych, ale niewiele wyjaśnia.

Utwórz dashboard i zaplanuj układ paneli

W obszarze Dashboards wybierz utworzenie nowego dashboardu, a następnie dodaj wizualizację. Nazwy przycisków mogą nieznacznie różnić się między wersjami Grafany. W edytorze panelu wskaż skonfigurowane źródło danych Prometheus. Każdy panel łączy zapytanie, sposób prezentacji wyników i ustawienia opisujące dane — między innymi tytuł, jednostkę oraz legendę.

Zacznij od niewielkiej liczby paneli i uporządkuj je od ogółu do szczegółu. Na górze umieść najważniejsze wskaźniki, poniżej wykresy pokazujące zmiany w czasie. Szczegółowe zestawienia mogą znaleźć się na dole. Powiązane tematycznie panele warto grupować w wiersze, czyli Rows, z krótkimi nazwami, np. „Zasoby hosta” lub „Ruch sieciowy”.

Jeden panel powinien mieć jeden jasno określony cel. Nie łącz na wspólnym wykresie danych o różnych jednostkach tylko dlatego, że dotyczą tego samego serwera. Zachowaj podobną szerokość paneli o zbliżonej funkcji, a wykresom wymagającym porównywania wielu serii zapewnij więcej miejsca.

Dobierz wizualizację do pytania

Wybór wykresu powinien wynikać ze sposobu odczytywania danych. Na początek wystarczą trzy podstawowe typy:

• Time series — pokazuje przebieg wartości w czasie; pomaga zauważyć skoki, trendy i moment wystąpienia problemu.
• Stat — eksponuje pojedynczą wartość, np. ostatni dostępny pomiar lub średnią z wybranego okresu.
• Table — ułatwia porównanie wielu obiektów, zwłaszcza gdy obok wartości trzeba pokazać identyfikujące je etykiety.

Przy panelu Stat sprawdź sposób wyliczania wyświetlanej wartości. Ostatnia próbka i średnia z godziny odpowiadają na inne pytania. Jeśli pokazujesz średnią, zaznacz to w tytule lub opisie — sama duża liczba nie informuje, jak została obliczona.

Ustaw zakres czasu i odświeżanie

Zakres czasu wybierany w prawym górnym rogu dashboardu domyślnie obejmuje wszystkie panele. Do pierwszego przeglądu możesz ustawić ostatnią godzinę, a przy szukaniu dłuższych trendów rozszerzyć widok do doby. Podczas analizy konkretnego zdarzenia użyj zakresu bezwzględnego, z ustaloną datą i godziną początku oraz końca. Dzięki temu analizowany przedział nie będzie przesuwał się wraz z upływem czasu.

Automatyczne odświeżanie dopasuj do częstotliwości zbierania metryk i potrzeb odbiorców. Jeśli Prometheus pobiera próbki co 15 sekund, odświeżanie dashboardu co sekundę zwykle nie daje korzyści, a generuje dodatkowe zapytania. Odświeżanie widoku nie zmienia częstotliwości zbierania danych. Sprawdź też strefę czasową dashboardu, szczególnie gdy porównujesz wykresy z logami lub udostępniasz widok innym osobom.

Zadbaj o jednostki, legendy i opisy

W opcjach standardowych panelu ustaw jednostkę odpowiadającą wynikowi zapytania. Dla udziałów rozróżnij procenty zapisane w skali 0–1 i 0–100. Dla danych o rozmiarze świadomie wybierz jednostki dziesiętne lub binarne, a dla czasu — sekundy albo milisekundy. Formatowanie w Grafanie nie zastępuje poprawnego przeliczenia danych w zapytaniu. Ogranicz również liczbę miejsc po przecinku do poziomu przydatnego przy odczycie.

Legenda powinna jednoznacznie identyfikować serię, ale nie musi zawierać wszystkich etykiet zwracanych przez Prometheusa. Możesz wykorzystać np. {{instance}}, jeśli ta etykieta występuje w wyniku zapytania. Gdy jeden host zwraca kilka serii, dodaj informację, która je odróżnia. Kilka identycznych podpisów utrudnia interpretację równie mocno jak zbyt długa legenda.

Przed zapisaniem dashboardu sprawdź czytelność tytułów, zgodność jednostek i zachowanie paneli po zmianie zakresu czasu. Nie przedstawiaj braku danych jako zera — to dwa różne stany. Na koniec nadaj dashboardowi nazwę opisującą jego zakres, wybierz folder i zapisz widok z ustawieniami czasu przydatnymi podczas codziennej pracy.

Panele z bazowymi metrykami i przykładowe zapytania PromQL: CPU, RAM, dysk i sieć

Pierwszy zestaw paneli powinien odpowiadać na cztery pytania: czy procesor jest przeciążony, ile pamięci pozostaje dostępne, czy kończy się miejsce na dysku i jak zmienia się ruch sieciowy. Poniższe zapytania wykorzystują metryki hosta z Node Exportera działającego na Linuksie. Nie pokazują zużycia zasobów przez pojedyncze kontenery ani pody; również w Kubernetes opisują węzeł, a nie uruchomione na nim aplikacje.

W przykładach liczniki przeliczamy funkcją rate() na średnie tempo zmian na sekundę. Okno [$__rate_interval] jest makrem Grafany dobieranym do rozdzielczości wykresu i interwału zbierania danych. Aby działało prawidłowo, ustawienia interwału w źródle danych powinny odpowiadać rzeczywistej konfiguracji Prometheusa.

CPU: procent czasu, w którym procesor nie był bezczynny

Metryka node_cpu_seconds_total jest licznikiem czasu procesora, a nie gotowym procentem wykorzystania. Poniższe zapytanie oblicza udział czasu poza trybem idle i uśrednia wynik po rdzeniach, osobno dla każdej pary job i instance:

100 * (1 - avg by (job, instance) (
  rate(node_cpu_seconds_total{mode="idle"}[$__rate_interval])
))

Wynik najlepiej pokazać jako Time series z jednostką Percent (0–100). Przykładowe progi to 80% dla ostrzeżenia i 95% dla stanu krytycznego, ale dopiero utrzymujące się wysokie wartości mogą wskazywać na problem. Ten wskaźnik obejmuje także czas iowait, dlatego nie należy traktować go jako czystej miary wykonywania obliczeń. Średnia może też ukryć pełne obciążenie pojedynczego rdzenia.

RAM: zajętość obliczona na podstawie dostępnej pamięci

Do oceny presji pamięci lepiej wykorzystać MemAvailable niż samą wolną pamięć. Linux używa RAM-u między innymi jako pamięci podręcznej, której część może odzyskać na potrzeby aplikacji.

100 * (
  1 - node_memory_MemAvailable_bytes
      / node_memory_MemTotal_bytes
)

Gauge dobrze pokazuje bieżący poziom wykorzystania, natomiast Time series pozwala zauważyć systematyczny wzrost. Ustaw jednostkę Percent (0–100); wartości 85% i 95% mogą posłużyć jako początkowe progi wizualne. Nie są jednak uniwersalną granicą awarii — znaczenie ma również aktywność swapu i charakter obciążenia.

Dysk: oddziel zajętość systemu plików od transferu danych

Brak miejsca i intensywne operacje dyskowe to dwa różne problemy. Pierwszy panel powinien pokazywać wykorzystanie każdego istotnego punktu montowania:

100 * (
  1 - node_filesystem_avail_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs"}
      / node_filesystem_size_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs"}
)

Zapytanie oblicza udział pojemności niedostępnej dla zwykłych użytkowników, uwzględniając również miejsce zarezerwowane. Filtr typów systemów plików jest punktem wyjścia — dopasuj go do hosta i pomiń nieistotne lub tylko do odczytu punkty montowania. W panelu Bar gauge zachowaj rozróżnienie według instance i mountpoint; nie uśredniaj zajętości wszystkich dysków.

Progi 80% i 90% mogą ułatwić wstępną ocenę, lecz zestaw je z liczbą dostępnych bajtów. Dziesięć procent wolnej przestrzeni oznacza coś innego na małym wolumenie systemowym niż na wieloterabajtowym zasobie.

Transfer dyskowy pokaż w osobnym panelu Time series, dodając dwa zapytania:

rate(node_disk_read_bytes_total[$__rate_interval])

rate(node_disk_written_bytes_total[$__rate_interval])

Ustaw jednostkę bajtów na sekundę i rozróżnij odczyt oraz zapis dla każdego device. Nie sumuj bezrefleksyjnie urządzeń fizycznych i logicznych: przy warstwach takich jak LVM te same operacje mogą być widoczne na kilku poziomach. Wysoki transfer sam w sobie nie dowodzi przeciążenia; do jego oceny potrzebne są również informacje o opóźnieniach i możliwościach nośnika.

Sieć: ruch przychodzący i wychodzący

Dwa zapytania w jednym panelu pozwalają porównać odbieranie i wysyłanie danych:

rate(node_network_receive_bytes_total{device!="lo"}[$__rate_interval])

rate(node_network_transmit_bytes_total{device!="lo"}[$__rate_interval])

Wybierz Time series i jednostkę bajtów na sekundę. Jeśli chcesz prezentować bity na sekundę, pomnóż wyniki przez 8 i dopiero wtedy ustaw odpowiednią jednostkę. Zachowaj osobne serie dla interfejsów; filtr wykluczający lo usuwa jedynie interfejs pętli zwrotnej. Mosty i interfejsy wirtualne mogą pokazywać ten sam ruch na kolejnych etapach, więc ich suma bywa myląca. Progi wykorzystania łącza ustalaj względem jego znanej przepustowości, a nie arbitralnej wartości transferu.

Transformacje: porządkowanie wyników bez zmiany ich znaczenia

Obliczenia wykorzystania i tempa zmian pozostaw w PromQL. Transformacje Grafany wykorzystaj przede wszystkim do prezentacji: Organize fields by name pozwala uporządkować i nazwać kolumny pojedynczej tabeli, a Labels to fields przenieść etykiety do pól. Przy łączeniu wyników zadbaj o jednoznaczny identyfikator hosta — sama etykieta instance nie zawsze wystarcza, jeśli występuje w kilku zadaniach zbierania metryk.

Do tabeli bieżących wartości możesz użyć zapytań typu Instant. Jeśli redukujesz szeregi czasowe transformacją Reduce, świadomie wybierz ostatnią wartość albo średnią z zakresu: odpowiadają na inne pytania. Nie zastępuj automatycznie brakujących danych zerem. Brak pomiaru CPU lub ruchu sieciowego nie oznacza braku obciążenia, a kolorowy próg w panelu nie jest jeszcze regułą alertową.

Templating i zmienne — filtrowanie dashboardu i reużywalność paneli

Zamiast tworzyć osobny dashboard dla każdego hosta, namespace’u czy poda, przygotuj jeden widok sterowany zmiennymi. W Grafanie ten mechanizm nazywa się templatingiem: użytkownik wybiera wartość z listy, a panele korzystające z danej zmiennej pokazują odpowiadające jej dane. Dzięki temu ten sam dashboard może służyć do obserwowania całego środowiska i analizowania pojedynczego zasobu.

Jakie zmienne warto przygotować?

Punktem wyjścia są etykiety dostępne w metrykach Prometheusa. Dla monitoringu hostów zwykle przydaje się para job → instance, a w Kubernetes — namespace → pod. Jeśli źródło danych obejmuje kilka klastrów, warto dodać nadrzędny wybór klastra, o ile metryki zawierają odpowiednią etykietę.

• job — identyfikuje zadanie zbierania metryk; pomaga oddzielić na przykład dane z różnych eksporterów.
• instance — identyfikuje konkretny target, często przez adres i port; nie zawsze odpowiada nazwie hosta.
• namespace — pozwala zawęzić dane do wybranej przestrzeni nazw Kubernetes.
• pod — umożliwia wybór konkretnego poda w obserwowanym środowisku.

Nie każda metryka ma wszystkie te etykiety. Metryki hosta udostępniane przez Node Exporter zazwyczaj nie zawierają informacji o namespace’ach ani podach. Filtry należy więc przypisywać do paneli zgodnie z rzeczywistymi etykietami ich danych, a nie stosować jeden zestaw ograniczeń do całego dashboardu bez sprawdzenia.

Tworzenie zmiennych i zależnych list wyboru

W ustawieniach dashboardu przejdź do obszaru Variables i dodaj zmienną typu Query, wskazując Prometheusa jako źródło danych. Do list opartych na etykietach służy typ zapytania Label values. Wybierz etykietę oraz, gdy to potrzebne, metrykę ograniczającą zakres wyszukiwania. Lista instancji powinna pochodzić z danych istotnych dla danego dashboardu, zamiast obejmować wszystkie targety w środowisku.

Następnie zbuduj zależności: lista instancji powinna uwzględniać wybrany job, a lista podów — namespace. Umieść zmienne nadrzędne przed zależnymi. Taki układ skraca listy wyboru i ogranicza sytuacje, w których użytkownik wskazuje zasoby niepasujące do siebie.

Dopasuj odświeżanie list do zmienności środowiska. Odświeżenie przy otwarciu dashboardu często wystarczy dla stabilnej infrastruktury. Odświeżanie przy zmianie zakresu czasu przydaje się wtedy, gdy wyniki zapytania zmiennej zależą od tego zakresu, ale zwiększa liczbę zapytań do źródła danych.

Filtrowanie paneli i wybór wielu wartości

Samo utworzenie zmiennej nie filtruje paneli. Trzeba jeszcze wykorzystać ją w selektorach etykiet w zapytaniach każdego odpowiedniego panelu. Można również umieścić jej wartość w tytule panelu lub opisie wiersza, aby odbiorca od razu widział kontekst prezentowanych danych.

Opcja Multi-value pozwala wybrać kilka wartości, a Include All dodaje wybór wszystkich dostępnych pozycji. Przy takich ustawieniach dopasowanie etykiet w zapytaniach Prometheusa powinno obsługiwać wyrażenia regularne zamiast porównania do jednej dokładnej wartości. Szeroki wybór może jednak znacząco zwiększyć liczbę zwracanych serii, dlatego nie zawsze warto ustawiać „wszystkie” jako widok domyślny.

Reużywalność bez kopiowania konfiguracji

Jeżeli chcesz porównywać zasoby obok siebie, wykorzystaj powtarzanie paneli lub wierszy według zmiennej. Grafana utworzy widoki dla wybranych wartości na podstawie jednego wzorca. Przy dużej liczbie podów lub hostów lepszy będzie jednak ograniczony wybór — dziesiątki powtórzonych paneli pogarszają czytelność i zwiększają obciążenie.

Do współdzielenia panelu między dashboardami służą Library panels. Pozwalają utrzymywać wspólną konfigurację, ale dashboardy korzystające z takiego panelu muszą udostępniać zgodne zmienne i źródła danych. Przed zapisaniem widoku sprawdź wybór pojedynczy, wielokrotny oraz zmianę zmiennej nadrzędnej. To najprostszy sposób, by wykryć puste panele i filtry, które nie reagują na wybór użytkownika.

Eksport i import dashboardu: JSON, wersjonowanie i udostępnianie w zespole

Gotowy dashboard warto traktować jak element konfiguracji środowiska, a nie tylko widok zapisany w Grafanie. Eksport do JSON pozwala przenieść go do innej instancji, Git ułatwia kontrolowanie zmian, a foldery i linki porządkują codzienną pracę zespołu. Gdy konfiguracja ma być odtwarzalna, przydaje się provisioning, czyli automatyczne dostarczanie definicji dashboardów.

Eksport i import dashboardu w formacie JSON

W opcjach udostępniania lub eksportu dashboardu możesz pobrać jego definicję jako plik JSON. Dokładne położenie tej funkcji zależy od wersji Grafany. Plik zawiera między innymi układ paneli, zapytania, ustawienia wizualizacji i zmienne. Nie jest kopią danych przechowywanych w Prometheusie ani pełną kopią konfiguracji Grafany.

Import polega na wczytaniu pliku lub wklejeniu jego zawartości w widoku importowania dashboardów. Podczas przenoszenia między instancjami zwróć uwagę na odwołania do źródeł danych: identyfikator źródła Prometheus w środowisku docelowym może być inny. Jeśli eksport oferuje wariant przeznaczony do udostępniania poza bieżącą instancją, warto go użyć — ułatwia wskazanie odpowiedniego źródła podczas importu.

Przed zatwierdzeniem importu sprawdź nazwę, folder i identyfikator UID dashboardu. Zachowanie UID jest przydatne przy aktualizowaniu tego samego widoku, ponieważ pomaga utrzymać stabilne odnośniki. Przy tworzeniu niezależnej kopii trzeba natomiast uniknąć konfliktu z istniejącym dashboardem. Po imporcie upewnij się również, że środowisko docelowe ma wymagane wtyczki wizualizacyjne.

Wersjonowanie: historia Grafany i repozytorium Git

Historia wersji dostępna w Grafanie pomaga porównać zapisane zmiany i przywrócić wcześniejszą wersję dashboardu. Do pracy zespołowej warto dodatkowo przechowywać wyeksportowane pliki JSON w repozytorium Git. Dzięki temu zmiany można powiązać z zadaniem, poddać przeglądowi i wdrażać w kontrolowany sposób.

Ustal jedno źródło prawdy. Jeśli jest nim repozytorium, poprawki wykonane w interfejsie Grafany powinny trafić do niego przed kolejnym wdrożeniem. W przeciwnym razie zawartość repozytorium i dashboard używany przez zespół zaczną się różnić. W opisach zmian zapisuj ich cel, na przykład korektę jednostki lub zmianę sposobu prezentacji danych, zamiast ograniczać się do ogólnego „aktualizacja dashboardu”. W Cognity uczymy, jak skutecznie radzić sobie z podobnymi wyzwaniami w codziennej pracy — zarówno indywidualnie, jak i zespołowo.

Udostępnianie przez linki i foldery

Do codziennej współpracy w obrębie jednej instancji najczęściej wystarczy link. Może on uwzględniać zakres czasu oraz wybrane wartości zmiennych, co ułatwia przekazanie widoku dotyczącego konkretnego incydentu. Zwykły link nie nadaje uprawnień — odbiorca nadal musi mieć dostęp do odpowiednich zasobów w Grafanie.

Dashboardy warto grupować w folderach według usług, zespołów lub środowisk, a dostęp przyznawać zespołom zamiast zarządzać każdą osobą oddzielnie. Oddziel możliwość przeglądania od edycji. Publiczne udostępnianie, jeśli jest dostępne i włączone w danej instalacji, wymaga osobnej oceny: nazwy hostów, etykiety i informacje operacyjne mogą być wrażliwe. Przed przekazaniem pliku JSON poza zespół również przejrzyj jego zawartość.

Provisioning: dashboardy dostarczane wraz z konfiguracją

Provisioning pozwala Grafanie wczytywać dashboardy z przygotowanych plików na podstawie konfiguracji wskazującej ich lokalizację i folder docelowy. Sprawdza się przy odtwarzaniu środowisk oraz automatycznych wdrożeniach: pliki JSON mogą pochodzić z repozytorium i trafiać do Grafany przez proces wdrożeniowy.

W tym modelu zmiany najlepiej wprowadzać w plikach źródłowych. Nawet jeśli konfiguracja dopuszcza zapis zmian w interfejsie, Grafana nie zapisuje ich automatycznie z powrotem do pliku, a późniejsza aktualizacja z provisioningu może je nadpisać. Jasna zasada edycji pozwala uniknąć utraty poprawek i utrzymać spójność dashboardów między środowiskami.

Grafana vs Prometheus – czym różnią się te narzędzia i dlaczego warto używać ich razem? 15 listopada 2026

Co to jest Grafana i do czego służy? Praktyczny przewodnik po monitorowaniu i wizualizacji danych 13 listopada 2026