Grafana – monitorowanie infrastruktury i aplikacji

geek.justjoin.it 3 dni temu

Kiedy aplikacja zwalnia o trzeciej w nocy, nikt nie chce zgadywać, co się dzieje. Grafana pokazuje to na jednym ekranie: obciążenie serwerów, czasy odpowiedzi API, błędy w logach i alerty. To jedno z najczęściej wybieranych narzędzi do monitoringu aplikacji i infrastruktury, a w wielu zespołach DevOps i SRE stało się standardem.

Poniżej wyjaśniamy, czym jest Grafana, jak działa i jak zbudować pierwszy dashboard krok po kroku. Porównujemy też Grafanę z Kibaną i podpowiadamy, jak uniknąć typowych błędów.

Grafana – co to jest?

Grafana to otwartoźródłowa platforma do wizualizacji, analizy i alertowania na podstawie danych z wielu źródeł. Sama nie przechowuje większości danych, które pokazuje. Łączy się z zewnętrznymi bazami i systemami (tzw. data sources), pobiera z nich dane i rysuje wykresy, tabele, mapy cieplne czy liczniki.

Projekt powstał w 2014 roku. Jego autorem jest szwedzki programista Torkel Ödegaard, a początkowo był forkiem Kibany nastawionym na metryki szeregów czasowych. Dziś rozwija go firma Grafana Labs. Od 2021 roku główne komponenty open source działają na licencji AGPLv3. Wcześniej korzystały z Apache 2.0, o czym warto pamiętać przy wdrożeniach w firmach z rygorystyczną polityką licencyjną.

Do czego służy Grafana?

W praktyce Grafana pełni cztery role:

Wizualizacja – dashboardy z wykresami metryk, logów i śladów.
Eksploracja danych – tryb Explore do szybkiego „dłubania” w zapytaniach bez budowania dashboardu.
Alertowanie – reguły, które wysyłają powiadomienia na Slacka, e-mail, Microsoft Teams czy do PagerDuty.
Korelacja sygnałów – łączenie metryk, logów i trace’ów w jednym miejscu.

Z Grafany korzystają zespoły DevOps, SRE, administratorzy, a także programiści. Jej zastosowania wychodzą poza IT. Grafana monitoruje też dane z IoT, produkcji, energetyki czy finansów.

Grafana a Prometheus – to nie to samo

Te dwie nazwy często padają razem, bo świetnie się uzupełniają. Prometheus zbiera i przechowuje metryki oraz pozwala je odpytywać językiem PromQL. Grafana je wizualizuje. Prometheus bez Grafany ma bardzo prosty interfejs, a Grafana bez źródła danych nie ma czego pokazywać.

Jak działa Grafana? Architektura w pigułce

Grafana to aplikacja serwerowa napisana w Go, z interfejsem webowym w React/TypeScript. Działa według prostego schematu:

Źródła danych – Prometheus, Loki, Elasticsearch, InfluxDB, PostgreSQL, MySQL, CloudWatch, Azure Monitor, Google Cloud Monitoring i wiele innych.
Zapytania – w panelu wybierasz źródło i piszesz zapytanie w jego języku (PromQL, LogQL, SQL, Lucene itd.).
Wizualizacje – wynik zapytania trafia do panelu, np. wykresu liniowego, stat, gauge czy tabeli.
Dashboardy – panele układasz w dashboardy, które można filtrować zmiennymi (np. wybór środowiska, klastra lub serwisu).
Alerty – na podstawie tych samych zapytań definiujesz reguły i kanały powiadomień.

Wtyczki rozszerzają Grafanę o kolejne źródła danych, typy paneli i aplikacje. Ich katalog znajdziesz na stronie Grafana Labs.

Stack LGTM – Grafana jako część większej układanki

Grafana Labs rozwija cały ekosystem observability, czyli obserwowalności systemów. Najczęściej mówi się o stacku LGTM:

L – Loki: system do przechowywania i przeszukiwania logów. Indeksuje tylko etykiety, nie całą treść logów, więc jest zwykle tańszy w utrzymaniu niż rozwiązania oparte na pełnotekstowym indeksowaniu.
G – Grafana: warstwa wizualizacji i alertowania.
T – Tempo: backend do rozproszonego śledzenia (distributed tracing).
M – Mimir: skalowalny, długoterminowy magazyn metryk zgodny z Prometheusem.

Do tego dochodzą Pyroscope (profilowanie ciągłe), k6 (testy wydajnościowe) oraz Grafana Faro (monitoring frontendu i doświadczeń użytkowników). Jako kolektor telemetrii Grafana Labs rekomenduje Grafana Alloy, własną dystrybucję OpenTelemetry Collectora. Zastąpił on wcześniejszego Grafana Agenta, który został wycofany z użycia. jeżeli trafisz na starszy tutorial z Agentem, traktuj go jako przestarzały.

Takie podejście ma duże znaczenie praktyczne. Gdy widzisz skok błędów na wykresie metryk, jednym kliknięciem przechodzisz do logów z tego momentu, a stamtąd do konkretnego trace’a. To właśnie korelacja trzech sygnałów (metryk, logów i śladów) odróżnia dojrzały monitoring od zbioru ładnych wykresów.

Grafana – tutorial: pierwszy dashboard w 15 minut

Przejdźmy do praktyki. Zbudujemy lokalny zestaw: Grafana, Prometheus i Node Exporter, który wystawia metryki systemowe maszyny. Potrzebujesz tylko Dockera i Docker Compose.

Krok 1: Uruchom stack w Docker Compose

Utwórz plik docker-compose.yml:

yaml services: grafana: image: grafana/grafana-oss:latest ports: - "3000:3000" volumes: - grafana-data:/var/lib/grafana prometheus: image: prom/prometheus:latest ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml node-exporter: image: prom/node-exporter:latest ports: - "9100:9100" volumes: grafana-data:

Obok dodaj prometheus.yml:

yaml global: scrape_interval: 15s scrape_configs: - job_name: "node" static_configs: - targets: ["node-exporter:9100"]

Uruchom całość poleceniem docker compose up -d. W środowisku produkcyjnym przypnij konkretne wersje obrazów zamiast tagu latest. Dzięki temu aktualizacja nie zaskoczy cię w środku tygodnia.

Krok 2: Zaloguj się do Grafany

Otwórz http://localhost:3000. Domyślny login i hasło to admin / admin. Grafana poprosi o zmianę hasła przy pierwszym logowaniu. Nigdy nie zostawiaj domyślnych danych na serwerze dostępnym z sieci.

Krok 3: Dodaj źródło danych

Przejdź do Connections → Data sources → Add data source i wybierz Prometheus. W polu URL wpisz http://prometheus:9090 (nazwa usługi z Compose). Kliknij Save & test. jeżeli widzisz zielony komunikat, połączenie działa.

Krok 4: Zaimportuj gotowy dashboard

Nie musisz zaczynać od zera. W bibliotece dashboardów na grafana.com znajdziesz tysiące gotowców tworzonych przez społeczność. Wejdź w Dashboards → New → Import i wpisz ID 1860 (popularny dashboard Node Exporter Full). Wskaż źródło danych Prometheus i zatwierdź. Po chwili zobaczysz CPU, pamięć, dyski i ruch sieciowy swojej maszyny.

Krok 5: Zbuduj własny panel

Gotowce są świetnym punktem startowym, ale prawdziwa wartość zaczyna się przy własnych panelach. Utwórz nowy dashboard, dodaj wizualizację i wpisz zapytanie PromQL pokazujące zajęcie procesora:

promql 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

To zapytanie liczy średnie obciążenie CPU z ostatnich pięciu minut jako 100% minus czas bezczynności. Wybierz typ panelu Time series, ustaw jednostkę na Percent (0-100) i dodaj progi kolorystyczne, np. żółty od 70%, czerwony od 90%.

Krok 6: Ustaw alert

W panelu przejdź do zakładki Alert i utwórz regułę: jeżeli obciążenie CPU przekracza 90% przez 10 minut, wyślij powiadomienie. Najpierw skonfiguruj contact point (np. Slack lub e-mail), a potem przypisz go do polityki powiadomień. Od wersji 9 Grafana ma ujednolicony system alertów (Grafana Alerting), który obsługuje reguły z wielu źródeł danych w jednym miejscu.

Grafana dashboard – jak zrobić go dobrze?

Dashboard można zbudować w godzinę. Zbudowanie takiego, który ktoś będzie chciał otworzyć w trakcie awarii, wymaga trochę więcej pracy. Oto zasady, które sprawdzają się w praktyce.

Zacznij od pytań, nie od metryk

Zanim dodasz pierwszy panel, odpowiedz na pytanie: kto będzie patrzył na ten dashboard i jaką decyzję ma podjąć? Inaczej wygląda widok dla zespołu on-call, a inaczej dla managera, który chce wiedzieć, czy SLA jest dotrzymane.

Korzystaj z metod RED i USE

Dwie sprawdzone metodologie porządkują wybór metryk:

RED (dla usług): Rate – liczba żądań, Errors – liczba błędów, Duration – czasy odpowiedzi.
USE (dla zasobów): Utilization – wykorzystanie, Saturation – nasycenie, Errors – błędy.

Do tego dochodzą cztery złote sygnały z książki o SRE od Google: opóźnienie, ruch, błędy i nasycenie. Wszystkie trzy podejścia prowadzą do podobnych wniosków i dobrze sprawdzają się jako szkielet każdego dashboardu.

Używaj zmiennych

Zamiast tworzyć osobny dashboard dla wszystkich serwisu, zdefiniuj zmienne (variables), np. $environment, $namespace czy $service. Jeden dashboard obsłuży wtedy dziesiątki usług. To także prosty sposób na uniknięcie „dashboardowego chaosu”, w którym nikt nie wie, która kopia jest aktualna.

Traktuj dashboardy jak kod

Dashboardy edytowane manualnie w interfejsie gwałtownie się rozjeżdżają. Dojrzałe zespoły stosują podejście dashboards as code:

Provisioning – dashboardy i źródła danych ładowane z plików YAML/JSON przy starcie.
Terraform – provider Grafany do zarządzania całą konfiguracją.
Grafonnet / Foundation SDK – biblioteki do generowania dashboardów z kodu.
Git Sync – nowsza funkcja z Grafany 12, która synchronizuje dashboardy z repozytorium Git. Na moment pisania artykułu część możliwości może mieć status eksperymentalny lub podglądowy, więc sprawdź dokumentację swojej wersji.

Grafana 12, zaprezentowana w 2025 roku, rozwija też dynamiczne dashboardy z nowym modelem układu paneli i lepszym podejściem do wersjonowania. jeżeli korzystasz ze starszych wersji, warto przejrzeć notatki o wydaniach przed aktualizacją.

Kilka błędów, które widzimy najczęściej

Za dużo paneli na jednym ekranie. jeżeli dashboard wymaga przewijania przez 40 wykresów, nikt nie znajdzie w nim przyczyny awarii.
Brak jednostek i opisów. Wykres bez jednostki (ms? s? bajty?) wprowadza w błąd.
Alerty na wszystko. Zespół, który codziennie dostaje 200 powiadomień, przestaje na nie reagować (tzw. alert fatigue). Alertuj na objawy odczuwalne przez użytkownika, a nie na każdy skok CPU.
Ciężkie zapytania. Panel z zapytaniem po dużym zakresie czasu i wysokiej kardynalności etykiet potrafi obciążyć Prometheusa bardziej niż sama aplikacja.

Monitoring aplikacji z Grafaną – od metryk do trace’ów

Monitoring infrastruktury to dopiero początek. Prawdziwy monitoring aplikacji wymaga widoczności tego, co dzieje się w kodzie.

Metryki aplikacyjne

Aplikacje wystawiają własne metryki biznesowe i techniczne: liczbę zamówień, czas obsługi żądania, długość kolejek, liczbę błędów 5xx. Służą do tego biblioteki klienckie Prometheusa dla Javy, Pythona, Go, Node.js i .NET. Coraz częściej zespoły sięgają po OpenTelemetry, otwarty standard zbierania metryk, logów i trace’ów, który stał się de facto standardem w branży. Grafana dobrze go wspiera, a Alloy działa jako pośrednik między aplikacją a backendami.

Logi w Loki

Logi z aplikacji trafiają do Loki, a w Grafanie przeszukujesz je językiem LogQL. Przykładowo zapytanie {app=”api”} |= „error” pokaże wszystkie linie logów z etykietą app=”api”, które zawierają słowo „error”. Najlepsze jest to, iż możesz wyświetlić logi obok wykresu metryk z tego samego okresu.

Trace’y w Tempo

Rozproszone śledzenie pokazuje, którędy przechodzi pojedyncze żądanie przez mikroserwisy i gdzie traci czas. jeżeli jeden z dwudziestu serwisów dodaje 800 ms opóźnienia, trace wskaże go od razu. Bez tego szukasz winnego po omacku.

Monitoring frontendu i syntetyczny

Grafana Faro zbiera dane z przeglądarek użytkowników, m.in. błędy JavaScript i Core Web Vitals. Do tego dochodzi monitoring syntetyczny, czyli automatyczne sprawdzanie, czy najważniejsze ścieżki (np. logowanie i płatność) działają z zewnątrz.

Grafana vs Kibana – co wybrać?

To jedno z najczęstszych pytań. Obie platformy rysują wykresy na podstawie danych, ale wywodzą się z innych światów i mają inne mocne strony.

Kryterium	Grafana	Kibana
Główny cel	Wizualizacja metryk i obserwowalność z wielu źródeł	Eksploracja i analiza danych w Elasticsearch
Źródła danych	Dziesiątki (Prometheus, Loki, SQL, chmury, Elasticsearch i inne)	Praktycznie tylko Elasticsearch
Najmocniejsza strona	Metryki, szeregi czasowe, dashboardy operacyjne	Logi, wyszukiwanie pełnotekstowe, analityka bezpieczeństwa
Alertowanie	Wbudowane, obejmuje wiele źródeł	Wbudowane, ale w ramach ekosystemu Elastic
Licencja	AGPLv3 (wersja OSS) + wersje komercyjne	Elastic License / SSPL, a od 2024 także opcja AGPLv3
Typowy stack	Prometheus, Loki, Tempo, Mimir	Elasticsearch, Logstash, Beats (ELK/Elastic Stack)

Kiedy wybrać Grafanę?

Wybierz Grafanę, gdy masz wiele źródeł danych, pracujesz głównie z metrykami albo działasz w środowisku Kubernetes i chmurowym. Sprawdzi się też, gdy chcesz łączyć metryki, logi i trace’y w jednym interfejsie.

Kiedy wybrać Kibanę?

Kibana jest naturalnym wyborem, gdy całą swoją infrastrukturę logowania zbudowałeś/-aś na Elasticsearch. Ma przewagę przy pełnotekstowym przeszukiwaniu ogromnych wolumenów logów i w zastosowaniach SIEM. Jej możliwości w analizie bezpieczeństwa są szersze niż w Grafanie.

Czy trzeba wybierać?

Nie. W wielu firmach oba narzędzia działają równolegle. Grafana może zresztą używać Elasticsearcha jako źródła danych, więc często łączy się ją z istniejącym stackiem ELK, zamiast go wymieniać. Zamiast pytać „co jest lepsze?”, zapytaj, jakie dane masz i kto z nich korzysta.

Grafana OSS, Enterprise czy Cloud?

Masz trzy główne ścieżki wdrożenia:

Grafana OSS – darmowa, samodzielnie hostowana. Pełna kontrola, ale ty odpowiadasz za aktualizacje, kopie zapasowe i skalowanie.
Grafana Enterprise – wersja komercyjna z dodatkowymi funkcjami: zaawansowane uprawnienia, audyt, wtyczki do systemów korporacyjnych (np. Splunk, ServiceNow) i wsparcie.
Grafana Cloud – usługa zarządzana przez Grafana Labs. Obejmuje hostowane Mimir, Loki i Tempo, a także darmowy plan z ograniczeniami. Aktualne limity i ceny sprawdź na stronie producenta, bo zmieniają się dość często.

Na start dla zespołu 5-10 osób zwykle wystarcza Grafana OSS lub darmowy plan w chmurze. Przy dziesiątkach usług i wymaganiach dotyczących bezpieczeństwa i zgodności sensowne bywa przejście na Enterprise albo Cloud. Koszt utrzymania własnej infrastruktury łatwo niedoszacować.

Bezpieczeństwo i utrzymanie – o czym łatwo zapomnieć

Grafana często ma wgląd w wrażliwe dane o całej infrastrukturze, więc zasługuje na tę samą ostrożność co każdy inny system produkcyjny:

Uwierzytelnianie: włącz SSO (OAuth, SAML, LDAP) zamiast lokalnych kont.
Role i uprawnienia: nadawaj dostęp do folderów i dashboardów według zasady najmniejszych uprawnień.
Aktualizacje: Grafana regularnie publikuje poprawki bezpieczeństwa. Subskrybuj ogłoszenia o wydaniach.
HTTPS i reverse proxy: nie wystawiaj instancji do internetu bez szyfrowania.
Kopie zapasowe: zadbaj o backup bazy Grafany (domyślnie SQLite, w produkcji lepiej PostgreSQL lub MySQL) albo trzymaj wszystko jako kod w repozytorium.

Podsumowanie

Grafana stała się standardem w monitoringu nowoczesnych systemów, bo robi jedną rzecz dobrze: łączy dane z wielu źródeł w czytelny obraz tego, co dzieje się z aplikacją i infrastrukturą. Razem z Prometheusem, Loki i Tempo daje pełną obserwowalność bez uzależnienia od jednego dostawcy.

Najważniejsze wnioski:

Grafana wizualizuje dane z wielu źródeł, a nie je przechowuje.
Najlepsze efekty daje korelacja metryk, logów i trace’ów.
Dobry dashboard zaczyna się od pytania, nie od wykresu.
Grafana i Kibana nie muszą ze sobą konkurować. Wybór zależy od danych i zastosowań.
Dashboardy i alerty warto traktować jak kod.

Zacznij od małego eksperymentu: postaw stack z tego tutoriala i podepnij jedną własną usługę.

Idź do oryginalnego materiału