Monitoring infrastruktury w chmurze z Prometheus i Grafana: kompletny poradnik dla DevOps

Dlaczego monitoring w chmurze to nie luksus, tylko konieczność

Specyfika monitoringu w chmurze vs on‑premise

Środowiska on‑premise są zwykle stosunkowo statyczne: stała liczba serwerów, rzadkie zmiany sieci, przewidywalne aktualizacje. W chmurze infrastruktura żyje. Maszyny wirtualne pojawiają się i znikają w autoskalerze, pody w Kubernetes dostają efemeryczne IP, a część usług działa jako PaaS, do których nie masz bezpośredniego dostępu na poziomie systemu operacyjnego. Monitoring w chmurze musi nadążać za tą dynamiką i automatycznie odnajdywać nowe elementy.

W praktyce oznacza to, że klasyczne podejście „wpisz IP serwera do monitoringu i zapomnij” przestaje działać. Konfiguracje oparte na statycznych listach adresów szybko się dezaktualizują, a ręczne dopisywanie każdej nowej instancji generuje chaos i błędy. Dlatego DevOps w chmurze potrzebuje narzędzi, które wspierają autodiscovery, integrują się z API dostawców chmurowych i dobrze radzą sobie z krótkotrwałymi zasobami, które żyją kilkanaście minut, a zdążą wygenerować problemy z wydajnością.

Prometheus ze swoim modelem pull‑based i bogatym wsparciem dla service discovery (Kubernetes, konsule, chmury publiczne) został zaprojektowany dokładnie pod takie scenariusze. W połączeniu z Grafaną umożliwia nie tylko śledzenie maszyn wirtualnych, ale i metryk usług PaaS, kontenerów, a nawet funkcji serverless – o ile odpowiednio zaprojektujesz architekturę monitoringu w chmurze.

Konsekwencje braku realnego monitoringu

Brak monitoringu w środowisku cloudowym prędzej czy później prowadzi do powtarzalnego wzorca: zgłoszenie od biznesu lub klienta, panika, desperackie przeklikiwanie się po konsoli AWS/Azure/GCP i Slack pełen domysłów. Bez historycznych metryk trudno odróżnić, czy problemem jest błąd aplikacji, zbyt mało CPU na nodach, limit połączeń w bazie czy throttling ze strony usługodawcy chmury. Dochodzenie przyczyn trwa długo, a każda minuta to koszt: utracone przychody, reputacja, presja na zespół.

Drugi, mniej widoczny koszt to marnowanie zasobów. Bez metryk trudno uzasadnić zmniejszenie rozmiarów maszyn, redukcję liczby replik czy optymalizację zapytań do bazy. Wiele firm przepala budżet chmurowy tylko dlatego, że boi się zejść z zapasem mocy, nie mając twardych danych z monitoringu i trendów obciążenia. Dobrze skonfigurowany Prometheus i sensowne dashboardy w Grafanie pomagają podejmować decyzje „na chłodno”: widać, gdzie są zapasy, a gdzie faktyczne bottlenecki.

Wreszcie, brak monitoringu to także brak uczenia się z incydentów. Jeśli po problemie zostaje jedynie log z komunikatorów i ogólnikowe „było wysokie obciążenie”, zespół nie ma materiału, by ulepszać architekturę, limity autoskalera czy parametry baz danych. Monitoring zamienia jednorazowe pożary w źródło informacji, które można analizować po fakcie, dokładnie tak jak w innych obszarach inżynierii czy produkcji.

Monitoring jako fundament kultury DevOps i SRE

DevOps i SRE opierają się na pętlach feedbacku: wdrożenie zmiany, obserwacja efektu, adaptacja. Bez rzetelnych metryk ta pętla jest ślepa. Zespół wydaje nowe wersje aplikacji, zmienia konfigurację autoskalera, przenosi usługi do innego regionu – ale jeśli nie widzi wpływu na opóźnienia, obciążenie, błędy i koszty, to każda decyzja jest w praktyce eksperymentem bez pomiaru.

Prometheus i Grafana w roli centralnego systemu monitoringu w chmurze pozwalają budować kulturę, w której prawie każda zmiana ma swój „odcisk palca” w danych. Dobrze zaprojektowane dashboardy SRE z 4 Golden Signals (latency, traffic, errors, saturation), alerting oparty o SLO oraz przeglądy incydentów z danymi z metryk sprawiają, że dyskusje techniczne przestają opierać się na opiniach, a zaczynają na faktach.

Dodatkowo monitoring w chmurze to nie tylko metryki infrastruktury. W praktycznie każdym dojrzałym zespole DevOps ważne są także metryki biznesowe i produktowe: współczynnik konwersji, liczba aktywnych użytkowników, przepływ danych przez kluczowe integracje. Dzięki możliwością Grafany (panele z wielu źródeł danych) da się łączyć te informacje z metrykami technicznymi, co znacznie przyspiesza diagnozowanie problemów „biznes zaczyna widzieć spadek, ale zespół jeszcze nie widzi błędów 5xx”.

Minimum sensownego monitoringu przy małym budżecie

Niewielki zespół DevOps w startupie lub małej firmie nie potrzebuje od razu rozbudowanego, wielostrefowego klastra monitoringu. Wariant minimum, który daje realną wartość, to jedna instancja Prometheus, jedna Grafana i kilka dobrze dobranych eksporterów. Zamiast pełnego pokrycia wszystkiego, lepiej świadomie wybrać kluczowe komponenty: load balancer, aplikacja webowa, baza danych, cache, worker kolejki.

Przykładowy zestaw na start to: node_exporter na VM, blackbox_exporter do sprawdzania HTTP/HTTPS z zewnątrz, exporter dla bazy (np. postgres_exporter) oraz prosty set metryk aplikacyjnych (latencje requestów HTTP, kody odpowiedzi, error rate). Do tego 2–3 sensowne dashboardy w Grafanie, kilka prostych alertów (wysokie CPU, wysoki error rate, długa latencja) i już powstaje system, który realnie pomaga w dyżurach on‑call.

Podstawy Prometheus i Grafana w realiach DevOps

Jak działa Prometheus i dlaczego model pull ułatwia życie

Prometheus zbiera dane w modelu pull: okresowo odpytuje zdefiniowane cele (targets) pod adresem HTTP /metrics i pobiera z nich aktualny stan metryk. Każdy target to po prostu serwer HTTP wystawiający metryki w formacie tekstowym. Ten sposób działania ma kilka praktycznych zalet w chmurze. Po pierwsze, klient nie musi znać adresu serwera Prometheus, więc dużo łatwiej pracować w środowiskach z restrykcjami sieciowymi – wystarczy pozwolić Prometheusowi łączyć się „na zewnątrz”. Po drugie, to Prometheus zarządza harmonogramem scrapingu, dzięki czemu mamy spójną częstotliwość próbkowania.

Model pull dobrze integruje się też z mechanizmami service discovery. Prometheus potrafi odpytać API Kubernetes, AWS, GCP czy Consul, żeby poznać aktualną listę instancji do monitorowania. Nie trzeba utrzymywać statycznych list IP – konfiguracja może być zwięzła i oparta na etykietach (labels) środowiska. To sprawia, że przy autoskalowaniu ilość pracy po stronie DevOps spada praktycznie do zera.

Innym skutkiem modelu pull jest łatwiejsze radzenie sobie z krótkotrwałymi problemami z siecią. Jeśli w danym cyklu scrape nie powiedzie się, Prometheus ma prosty mechanizm retry i odpowiednią semantykę „braku danych”, co ułatwia pisaną później logikę alertów. W podejściu push (gdzie to serwery wysyłają metryki) znika jedno centralne miejsce sterujące tempem i spójnością danych.

Struktura metryki w Prometheus: nazwy, labele, typy

Każda metryka w Prometheus to nazwana wielkość z zestawem etykiet. Nazwa powinna być opisowa, w stylu http_requests_total czy node_cpu_seconds_total, a labele (label keys) służą do rozróżniania wymiarów, np. method="GET", status="200", instance="app-1". Dzięki temu jedna metryka obejmuje wiele wariantów, które można agregować i filtrować w zapytaniach PromQL.

Prometheus obsługuje kilka typów metryk, z których w praktyce najczęściej używane są:

• counter – monotonnie rosnąca wartość (licznik) do zliczania zdarzeń, np. liczba requestów, liczba błędów;
• gauge – aktualna wartość, która może rosnąć i maleć, np. użycie pamięci, liczba aktywnych połączeń;
• histogram – rozkład wartości w przedziałach (bucketach), używany np. do latencji;
• summary – lokalnie liczone percentyle, mniej popularny w dużych systemach z uwagi na trudniejszą agregację.

Dobór właściwego typu metryki jest kluczowy. Na przykład latencja requestów HTTP nie powinna być przechowywana jako zwykły gauge z jedną wartością „średnia latencja”. Zamiast tego stosuje się histogram z bucketami, co pozwala w PromQL policzyć p95, p99 i inne charakterystyki SRE. Podobnie, liczba requestów to zawsze counter, a nie gauge, ponieważ interesuje nas tempo przyrostu w czasie, a nie chwilowa „wartość stanu”.

Ekosystem: Prometheus, Alertmanager, Grafana i eksportery

Sam Prometheus to jedynie silnik zbierania metryk i silnik zapytań (PromQL). Typowa architektura monitoringu w chmurze obejmuje kilka elementów:

• Prometheus – zbiera metryki i przechowuje je lokalnie na dysku;
• Eksportery – procesy wystawiające metryki w formacie Prometheus (node_exporter, postgres_exporter, prometheus-nginx-exporter itd.);
• Alertmanager – komponent zarządzający alertami, odpowiada za deduplikację, routing i wysyłkę powiadomień (Slack, e‑mail, PagerDuty, Webhook);
• Grafana – warstwa wizualizacji, dashboardów i dodatkowych źródeł danych.

Przepływ danych wygląda następująco: eksportery i aplikacje wystawiają metryki; Prometheus okresowo je zbiera (scrape) i przechowuje w swoim TSDB (time series database); zapytania PromQL są wykonywane przez Grafanę (dashboardy) lub przez sam Prometheus (reguły alertów); wygenerowane alerty trafiają do Alertmanagera, który decyduje o ich dalszym losie. W praktyce oznacza to, że monitorując infrastrukturę w chmurze, nie musisz budować własnych mechanizmów powiadomień – wystarczy dobrze skonfigurować Alertmanager.

Koszty Prometheus + Grafana vs komercyjne APM

Prometheus i Grafana są open source, więc nie płacisz licencji za oprogramowanie. Koszty pojawiają się w postaci zasobów chmury (maszyny, dyski, transfer, backupy) oraz czasu ludzi na konfigurację i utrzymanie. W porównaniu z komercyjnymi APM (Application Performance Monitoring) w modelu SaaS zwykle daje to dużo niższy koszt całkowity przy średniej skali i jednocześnie większą kontrolę nad danymi (ważne, gdy polityka firmy nie pozwala wysyłać metryk i logów na zewnątrz).

Komercyjne APM mają swoje zalety: gotowe integracje, automatyczne wykrywanie usług, zaawansowane analizy ścieżek requestów. Jednak każda metryka, każdy trace i każdy log to potencjalny koszt w fakturze. Przy środowiskach o wielu mikroserwisach rachunek może szybko urosnąć. Zestaw Prometheus + Grafana pozwala świadomie dobrać, co jest mierzone, jak długo przechowywane i z jaką rozdzielczością. Dzięki temu łatwiej kontrolować budżet i unikać zbędnego gromadzenia danych.

W praktycznym scenariuszu budżetowym sensownym podejściem jest użycie Prometheus + Grafana jako głównego systemu monitoringu metryk, a komercyjne narzędzia SaaS wykorzystywać wybiórczo, np. tylko do szeroko rozumianego distributed tracing w krytycznych usługach. Taki hybrydowy model pozwala połączyć niskie koszty metryk z wygodą analizy złożonych ścieżek requestów, nie przepalając budżetu na pełen pakiet „wszystko w jednym” dla każdego komponentu.

Projekt architektury monitoringu w chmurze (IaaS, PaaS, Kubernetes)

Rozdzielenie zakresu: infrastruktura, platforma, aplikacje

Monitoring infrastruktury w chmurze łatwo zamienia się w „zbierzmy wszystko”. Taki chaos kosztuje: rośnie obciążenie Prometheus, rosną koszty storage, a dashboardy pełne są szumu. Lepsze podejście to podział na trzy warstwy:

• Infrastruktura – maszyny wirtualne, instancje baz danych jako usługi zarządzane, load balancery, sieci, dyski;
• Platforma – Kubernetes, serwisy PaaS (np. managed message brokers), funkcje serverless, CI/CD;
• Aplikacje biznesowe – mikroserwisy, API, frontendy, batch joby.

Granice odpowiedzialności między zespołami

Podział warstw to jedno, ale kluczowe staje się jasne określenie, kto odpowiada za które metryki i alerty. Inaczej bardzo szybko pojawia się zjawisko „niczyich alarmów” – coś dzwoni w nocy, każdy patrzy na kogoś innego. Prosty, praktyczny model wygląda tak:

Do kompletu polecam jeszcze: Klasyfikacja obrazów w PyTorch: od danych do wdrożenia — znajdziesz tam dodatkowe wskazówki.

• Infrastruktura (IaaS) – odpowiedzialność zespołu platformowego / SRE: kondycja maszyn, dysków, sieci, load balancerów, warstwy bezpieczeństwa (np. SG, firewall);
• Platforma (Kubernetes, PaaS) – zwykle wspólna odpowiedzialność SRE + DevOps w projektach: schedulery, autoscaling, kontrolery, kolejkowanie jobów, storage klastry;
• Aplikacje – zespół produktowy / deweloperski: błędy HTTP, latencja API, logika domenowa, SLA dla endpointów.

Dobrym ruchem jest przypisanie ownerów do dashboardów i alertów. Każdy kluczowy dashboard powinien mieć przyklejoną informację „właściciel: zespół X, kanał Slack: #team‑x”. To drobiazg, ale przy incydencie skraca czas szukania odpowiedniej osoby. Podobnie z alertami – w Alertmanagerze sensownie jest mieć routing typu: metryki z prefiksem node_ lecą do on‑call SRE, kube_ do zespołu platformy, a http_ danego mikroserwisu do jego właścicieli.

Monitoring w modelu IaaS: klasyczny „node level” i usługi zarządzane

W modelu IaaS rdzeniem jest monitoring maszyn wirtualnych i usług, które samodzielnie instalujesz. Najbardziej ekonomiczny start to prosty pakiet:

• node_exporter na każdej maszynie – CPU, RAM, dyski, sieć, file handles;
• eksporter do reverse proxy/web serwera (nginx, HAProxy, Envoy) – ruch na brzegu;
• eksporter do kluczowych baz danych (PostgreSQL, MySQL, Redis, RabbitMQ).

Cloud provider ma swoje metryki (CloudWatch, Cloud Monitoring, Azure Monitor). Nie ma sensu duplikować wszystkiego w Prometheus. Lepiej spiąć Grafanę bezpośrednio ze źródłem chmurowym i wykorzystać je do rzadziej odpytywanych metryk kosztowych (np. transfer, IOPS, liczba requestów do load balancerów). Prometheus zostaje do krótkookresowego, szczegółowego monitoringu infrastruktury, a dane „billingowe” odczytywane są z natywnych narzędzi, gdzie i tak będą najbardziej aktualne.

Przy IaaS dobrze działa reguła: minimum jeden dashboard infra na projekt. Bez rozbijania na OS czy typy maszyn – liczy się szybka diagnoza. Osobne, bardziej szczegółowe panele warto robić tylko tam, gdzie rzeczywiście występuje regularny problem (np. specyficzne storage dla OLAP).

Monitoring PaaS: metryki z API dostawcy, nie z wnętrza kontenera

Przy usługach PaaS (managed DB, managed Kafka, Cloud Run, App Service itd.) nie ma dostępu do hosta, więc odpadają klasyczne eksportery systemowe. Podstawowe źródła to:

• metryki udostępniane w natywnym systemie monitoringu chmury (CloudWatch, Stackdriver, Azure Monitor);
• czasem dedykowane endpointy /metrics w samych usługach (niektóre managed komponenty wystawiają dane w formacie Prometheus);
• metryki z warstwy klienta – aplikacja mierzy np. błędy połączeń do DB, czasy zapytań, retry.

Najprostsza i najtańsza strategia: nie kopiować hurtowo wszystkich metryk PaaS do Prometheus. Zamiast tego:

1. W Grafanie skonfigurować dwa źródła danych: Prometheus + monitoring chmurowy.
2. Używać metryk z chmury tylko tam, gdzie potrzeba danych długoterminowych lub kosztowych.
3. Na poziomie aplikacji dodać kilka konkretnych metryk biznesowo‑technicznych – np. db_connection_failures_total, external_api_latency_seconds.

Przykład z praktyki: zamiast zaciągać 200 metryk z managed PostgreSQL do Prometheus, wystarczą 3–4 kluczowe: CPU, storage, IOPS, connections – odczytywane bezpośrednio z CloudWatch w Grafanie. Resztę problemów łapie się metrykami na poziomie aplikacji (błędy zapytań, timeouty).

Kubernetes: jeden Prometheus czy kilka?

W klastrach Kubernetes od razu pojawia się pytanie o topologię: jeden centralny Prometheus na całą organizację czy osobny dla każdego klastra/projektu. Oba warianty mają wady i zalety:

• Jeden centralny Prometheus – łatwiejsze zarządzanie, jedno miejsce alertów, prostsze dashboardy przekrojowe. Wadą jest single point of failure i ryzyko, że instancja stanie się „odkurzaczem metryk” z całej firmy.
• Prometheus per klaster/projekt – lepsza izolacja, niezależne cykle życia, łatwiejsze ograniczanie kosztów (każdy ma swój retention). Za to więcej moving parts i trudniejsze przekrojowe zestawienia.

Budżetowo najczęściej wygrywa podejście hybrydowe: lekki Prometheus per klaster do lokalnych metryk (pod, node, kube‑state) + ewentualny centralny system długoterminowy (np. Thanos, Cortex, Mimir) tylko dla wybranych, istotnych serii. Dzięki temu nie przechowujesz z wysoką rozdzielczością absolutnie wszystkiego, a jednocześnie możesz porówniać klastry między sobą w jednym miejscu.

Warstwa aplikacyjna: SLI/SLO zamiast „tabelki wszystkiego”

Przy aplikacjach pokusa jest zawsze ta sama: dodać metrykę do każdego fragmentu kodu. To zabija przejrzystość i generuje niepotrzebne koszty storage. Skuteczniejsze podejście to zacząć od kilku SLI (Service Level Indicators) i powiązanych z nimi SLO:

• Dostępność – jaki procent requestów kończy się 2xx/3xx;
• Latencja – jak wygląda p95/p99 dla kluczowych endpointów;
• Błędy biznesowe – np. odsetek odrzuconych transakcji z powodów domenowych.

Dopiero wokół nich opłaca się rozbudowywać metryki pomocnicze. Zamiast więc produkować dziesiątki serii na każde zdarzenie w logice, lepiej mieć 3–4 dobrze zaprojektowane histogramy + kilka counterów błędów. Mniej serii to tańszy storage i szybsze zapytania PromQL.

Instalacja i podstawowa konfiguracja Prometheus w środowisku chmurowym

Wybór modelu wdrożenia: VM, Kubernetes czy managed

Na start opłaca się wybrać możliwie prosty model instalacji. Najczęstsze opcje:

• Pojedyncza VM z Prometheus – dobra na początek lub dla mniejszych zespołów; tania, łatwa do zrozumienia, wystarczy prosty backup wolumenu;
• Prometheus w Kubernetes (np. kube‑prometheus‑stack z Helm chart) – sensowny, jeśli i tak masz stabilny klaster i pipeline’y CI/CD;
• Managed Prometheus (np. Amazon Managed Service for Prometheus, GCP Managed Prometheus) – płacisz więcej za unit danych, ale nie utrzymujesz samej instancji.

Jeśli zespół ma ograniczone zasoby i nie przewidujesz dziesiątek tysięcy serii na starcie, jedna dobrze dobrana VM (np. instancja z szybszym storage) bywa tańsza i prostsza niż pełen setup z autoskalującym się Prometheus w Kubernetes. Managed Prometheus ma sens przy większej skali oraz tam, gdzie zespół nie chce wchodzić w tematy storage i HA dla TSDB.

Podstawowy plik konfiguracyjny prometheus.yml

Minimalna konfiguracja Prometheus sprowadza się do zdefiniowania globalnych ustawień i pierwszych jobów w sekcji scrape_configs. Przykład prostego, a jednocześnie sensownego pliku startowego:

global:
  scrape_interval: 30s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'nodes'
    static_configs:
      - targets:
        - 'vm-app-1:9100'
        - 'vm-app-2:9100'

  - job_name: 'nginx'
    metrics_path: /metrics
    static_configs:
      - targets:
        - 'lb-frontend:9113'

Na początek lepiej nie schodzić z scrape_interval poniżej 30 s. Krótsze interwały (np. 5 s) znacząco zwiększają liczbę próbek i obciążenie dysku, a w większości przypadków niewiele dają analitycznie. Różnicowanie interwałów opłaca się dopiero później: krytyczne metryki aplikacyjne można zbierać częściej, a metryki infra – rzadziej.

Service discovery w chmurze

Przy większej liczbie instancji ręczne listy targetów są nie do utrzymania. Wtedy wchodzi service discovery z chmury. Dla AWS może to wyglądać np. tak:

scrape_configs:
  - job_name: 'ec2-nodes'
    ec2_sd_configs:
      - region: us-east-1
        port: 9100
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Monitoring]
        regex: 'enabled'
        action: keep

W ten sposób monitorowane są wyłącznie instancje EC2 z tagiem Monitoring=enabled. To prosty filtr, który pozwala panować nad liczbą targetów. Podobnie działa integracja z Kubernetes: zamiast wpisów statycznych, Prometheus filtruje pod’y i serwisy po labelach, np. monitoring=enabled.

Konfiguracja retencji i storage

Domyślna retencja Prometheus to 15 dni. Dla wielu projektów to całkowicie wystarczające na początku. Jeżeli próbujesz od razu trzymać dane z 6–12 miesięcy w jednym Prometheus, rachunek za dyski bardzo szybko rośnie. Bardziej ekonomiczny schemat:

• Prometheus z retencją 15–30 dni na szybki troubleshooting;
• długoterminowe dane (jeśli są potrzebne) w tańszym systemie: Thanos/Cortex/Mimir lub exporter metryk zredukowanych (np. agregacje godzinne) do tańszej bazy.

Ustawienie retencji odbywa się parametrem startowym, np.:

--storage.tsdb.retention.time=30d
--storage.tsdb.path=/var/lib/prometheus

Warto też oddzielić wolumen Prometheus od innych danych na VM. Najprostszy wariant: osobny, szybki dysk (np. SSD) tylko dla TSDB, co poprawia wydajność i ułatwia ewentualną migrację.

Reguły rekordów i reguły alertów

Prometheus umożliwia definiowanie recording rules – gotowych, przeliczonych metryk złożonych. Pozwalają one przerzucić koszt obliczeń z czasu zapytań (Grafana) na czas zapisu. To użyteczne zwłaszcza dla cięższych agregacji używanych w wielu dashboardach. Przykład:

groups:
  - name: node-rules
    rules:
      - record: node:cpu_usage:avg5m
        expr: 100 - avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100

Alerting rules definiuje się podobnie, z dodaniem warunków i etykiet routingu:

groups:
  - name: node-alerts
    rules:
      - alert: NodeHighCPU
        expr: node:cpu_usage:avg5m > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Wysokie użycie CPU na {{ $labels.instance }}"
          description: "CPU powyżej 90% przez 10 minut."

Warto trzymać reguły w osobnych plikach per domena (infra, Kubernetes, aplikacje) i wersjonować je w Git. W połączeniu z CI/CD daje to kontrolę nad zmianami alertów i prosty rollback w razie zbyt „gadatliwej” konfiguracji.

Instalacja i konfiguracja Grafana dla chmury

Samodzielna Grafana vs wersja SaaS

Przy Grafanie wybór jest prostszy niż przy Prometheus. Platforma jest lekka, więc samodzielne hostowanie na jednej VM zwykle wystarcza na długi czas. Grafana Cloud i inne wersje SaaS są wygodne, ale każde dodatkowe źródło danych i użytkownik oznaczają dodatkowe koszty.

Dla małych i średnich zespołów dobry kompromis to:

Przy ograniczonych zasobach ważne jest też korzystanie z gotowych rozwiązań. Społeczność wokół Prometheus i Grafana dostarcza dziesiątki sprawdzonych dashboardów dla popularnych technologii. Zamiast pisać wszystko od zera, wystarczy dobrać 2–3 najbardziej pasujące i ewentualnie je przyciąć. W podobnym duchu tworzone są praktyczne poradniki IT i DevOps, jak choćby te na Złota Kielnia, gdzie więcej o informatyka można znaleźć w kontekście chmury, AI czy cyberbezpieczeństwa.

• Samodzielnie hostowana Grafana (Docker/VM/Kubernetes);
• Autoryzacja przez istniejący provider (OAuth, SSO) – bez budowania własnego systemu kont;
• Backup konfiguracji poprzez provisioning z plików w repozytorium Git.

Wersja SaaS zaczyna mieć sens przy bardzo rozproszonej organizacji, wielu tenantach i wymaganiach typu audyt uprawnień, granularne RBAC czy compliance.

Provisioning źródeł danych i dashboardów

Ręczne klikanie źródeł danych i dashboardów jest tanie czasowo tylko na początku. Przy kolejnym środowisku (dev/stage/prod) szybko staje się kłopotliwe. Grafana ma mechanizm provisioning, który pozwala zadeklarować wszystko jako pliki YAML/JSON.

Przykładowy plik datasources.yaml:

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

  - name: CloudWatch
    type: cloudwatch
    access: proxy
    jsonData:
      authType: default

Dashboardy można trzymać jako JSON w repozytorium, a ich provisioning opisać w pliku:

Konfiguracja dashboardów per środowisko

Jeden z częstszych błędów to kopiowanie tego samego dashboardu trzy razy: dla dev, stage i prod, tylko po to, żeby zmienić adres Prometheus lub nazwę joba. Lepiej zainwestować chwilę w parametrówkę i zmienne.

Prosty schemat:

• jedno źródło danych Prometheus per środowisko (np. prom-dev, prom-stage, prom-prod);
• zmienna dashboardu $env, która wybiera datasource – np. przez datasource variable z listą źródeł;
• zmienne takie jak $cluster, $namespace, $service zaciągane bezpośrednio z labeli Prometheus (np. poprzez label_values()).

Dzięki temu ten sam dashboard działa na wszystkich środowiskach. Przy kopiowaniu na kolejne projekty zmieniasz głównie prefiksy metryk i etykiety, a nie tworzysz wszystkiego od zera.

Przykładowe użycie zmiennej środowiska w zapytaniu PromQL:

sum by (job) (rate(http_requests_total{cluster="$cluster", namespace="$namespace"}[5m]))

To jednorazowy wydatek kilkudziesięciu minut, który później oddaje się przy każdym kolejnym serwisie i środowisku.

Role, uprawnienia i bezpieczny dostęp

Grafana kusi tym, że wszystko jest „na klik”. Przy kilku osobach w zespole jeszcze ujdzie, ale przy kilkunastu rozpoczyna się chaos: każdy edytuje wszystko, dashboardy się dublują, a ktoś przypadkiem usuwa krytyczny panel w piątek wieczorem.

Najprostszy, a jednocześnie sensowny model uprawnień w Grafana:

• Viewer – domyślna rola dla większości; może oglądać dashboardy, ale nie zapisuje zmian;
• Editor – dla kilku osób odpowiedzialnych za monitoring; tworzą i utrzymują dashboardy;
• Admin – wyłącznie dla osób utrzymujących samą platformę (datasources, organizacje, pluginy).

Do tego dobrze ustawić autoryzację przez istniejący mechanizm (OIDC/OAuth, SAML, GitHub/Google/AD). Odpada utrzymywanie haseł lokalnych i ręczne wyłączanie kont przy odejściu z firmy.

Szablony dashboardów zamiast dzieł sztuki

Nadmierny perfekcjonizm przy dashboardach łatwo zamienia się w marnowanie czasu. Zamiast rysować autorskie wizualizacje pod każdy serwis, lepiej mieć kilka powtarzalnych szablonów:

• dashboard infra (CPU, RAM, dyski, sieć, statusy instancji);
• dashboard Kubernetes (pod’y, deploye, requesty/limity, błędy);
• dashboard aplikacyjny (SLI/SLO: dostępność, latencja, błędy);
• dashboard kosztowy/zużycia (ilość metryk, liczba próbek, kluczowe eksportery).

Taki zestaw szablonów można trzymać jako JSON w repozytorium i versionować razem z kodem. Nowy projekt? Fork repo, zmiana labeli i w godzinę masz sensowne dashboardy zamiast kilkudniowego dłubania.

Minimalny zestaw pluginów

Każdy dodatkowy plugin to:

• ryzyko bezpieczeństwa (aktualizacje, CVE, zależności);
• czas na testy po upgrade Grafany;
• dodatkowe potencjalne bugi w core’owej funkcjonalności.

Dlatego na start wystarcza to, co jest wbudowane: wizualizacje typu time series, stat, bargauge oraz kilka podstawowych paneli (table, heatmap). Egzotyczne pluginy warto dołączać dopiero wtedy, gdy faktycznie rozwiązują konkretne, powtarzalne problemy – a nie dlatego, że „ładnie wyglądało na screenie”.

Eksportery i metryki: co monitorować, żeby nie przepłacać za dane

Standardowe eksportery – zestaw startowy

Przy nowym projekcie łatwo zagubić się w dżungli eksporterów. Zamiast instalować od razu kilkanaście, lepiej zacząć od minimalnego, sprawdzonego zestawu:

• node_exporter – system (CPU, RAM, dyski, sieć) dla VM;
• blackbox_exporter – ping HTTP/TCP/ICMP z zewnątrz (SLA i proste syntetyczne testy);
• nginx/apache/haproxy exporter – metryki z load balancerów i reverse proxy;
• kube-state-metrics + cAdvisor (lub metryki z kubeletów) – dla Kubernetes;
• cloud provider exporter (jeśli nie używasz direct integracji z CloudWatch/Stackdriver) – bazowe metryki infra z chmury.

Ten zestaw pokrywa podstawowe problemy produkcyjne: brak zasobów, błędy na warstwie sieciowej, problemy z orkiestracją. Eksportery aplikacyjne (np. do baz danych) można dodawać sukcesywnie, gdy pojawi się realna potrzeba.

Eksportery do baz danych – używać z głową

Eksportery do baz (PostgreSQL, MySQL, Redis, MongoDB i inne) potrafią generować ogromną liczbę serii, zwłaszcza gdy domyślnie eksportują metryki per tabela, indeks czy zapytanie. Z perspektywy kosztów lepsza jest selekcja:

• włączyć tylko najważniejsze namespace’y / schematy;
• wyłączyć metryki z bardzo wysoką kardynalnością (np. per zapytanie SQL, jeśli nie służą do konkretnej analizy);
• ograniczyć częstotliwość scrapowania, np. co 30–60 s, zamiast 5–10 s.

W wielu przypadkach wystarczy kilka podstawowych wskaźników: wykorzystanie CPU i RAM instancji, rozmiar bazy, liczba połączeń, latency zapytań, ilość locków. Cała reszta powinna pojawić się dopiero, gdy jest potrzebna do debugowania konkretnego incydentu.

Warto zauważyć, że Grafana potrafi korzystać z wielu źródeł danych, więc nic nie stoi na przeszkodzie, by na jednym ekranie zestawiać metryki z Prometheus, logi z Loki, dane biznesowe z bazy SQL czy dane AI z systemów takich jak cyfrowe bliźniaki. Ten wieloźródłowy charakter dobrze wpisuje się w nowoczesne scenariusze, w których monitoring infrastruktury łączy się z analityką procesów, jak przy projektach pokroju Cyfrowy bliźniak z AI: jak symulacje skracają wdrożenia.

Własne metryki aplikacyjne – projektowanie pod SLI

Metryki aplikacyjne najlepiej projektować „top‑down”: od SLI/SLO i procesów biznesowych, a nie od szczegółów technicznych. Zamiast eksportować stan każdego wewnętrznego cache czy każdy etap pipeline’u, lepiej zdefiniować kilka stabilnych, jednoznacznych punktów pomiaru:

• HTTP request duration – histogram (np. http_server_request_duration_seconds) z labelami path (lub pogrupowanymi endpointami), status, method;
• liczba błędów – counter (np. http_server_requests_errors_total) rozbity na klasy błędów (4xx/5xx) i kluczowe typy błędów domenowych;
• operacje biznesowe – counter (np. business_orders_created_total, business_payments_failed_total);
• kolejki / joby – liczba zadań w kolejce, czas oczekiwania, liczba błędnych retry.

Do tego dochodzą proste gauge’e typu „feature flags włączone”, „liczba aktywnych workerów”, ale dopiero wtedy, gdy są rzeczywiście używane w dashboardach lub alertach. Jeśli metryka nie służy do żadnej decyzji (nie ma ani dashboardu, ani alertu), jest kandydatem do usunięcia.

Ograniczanie kardynalności labeli

Największy zabójca budżetu w Prometheus to nie liczba typów metryk, ale liczba serii. Ta rośnie wykładniczo z liczbą labeli oraz ich kombinacji. Kilka prostych zasad projektowania:

• nie używać jako labeli wartości o dużej zmienności: ID użytkownika, ID sesji, losowe tokeny, trace ID;
• unikać labeli opartych na pełnym URL czy payloadzie; lepiej mieć label „endpoint_group” z kilkoma wartościami (np. cart, checkout, search);
• limitować liczbę możliwych wartości labeli przez mapowanie w kodzie (np. mapowanie typów błędów na kilka kategorii zamiast setek stringów z wyjątków);
• po zmianach metryk sprawdzać realny wzrost liczby serii – np. wbudowanymi metrykami prometheus_tsdb_head_series i dashboardem „Prometheus stats”.

Pomaga też okresowy przegląd metryk: co 2–3 miesiące przejść po dashboardach i usunąć te, które nikt nie otwiera oraz powiązane z nimi metryki pomocnicze. W praktyce często udaje się ściąć kilkadziesiąt procent serii bez utraty informacji.

Blackbox i syntetyczne testy zamiast milionów logów

Syntetyczne testy często zastępują nadmiernie szczegółowy loging. Zamiast trzymać każdy błąd 5xx w logach przez rok, można wdrożyć kilkanaście prostych checków HTTP na kluczowych endpointach:

• sprawdzanie strony głównej i kilku krytycznych ścieżek (np. login, checkout);
• pomiar czasu odpowiedzi z zewnątrz (nie z sieci wewnętrznej);
• testy z kilku regionów, jeśli użytkownicy są rozproszeni;
• prosty scenariusz biznesowy (np. utworzenie zasobu w testowej organizacji i jego odczyt).

Blackbox_exporter zbiera z tych testów niewielką liczbę metryk, a w zamian dostajesz czytelny sygnał „usługa jest dostępna / nie jest” plus SLA oparte na realnym doświadczeniu użytkownika. Koszt jest stabilny, niezależny od wolumenu ruchu – w przeciwieństwie do logów.

Monitoring chmurowy a limity API i koszty

Przy integracjach z API chmurowym (CloudWatch, Azure Monitor, GCP Monitoring) kluczowe są dwa aspekty: ograniczenie liczby zapytań oraz redukcja metryk, które wrzucasz do Prometheus. Bez tego łatwo wpaść w pułapkę podwójnego płacenia: raz za metryki w chmurze, drugi raz za ich przechowywanie lokalnie.

Zdrowy kompromis:

• zaciągać do Prometheus tylko metryki, których faktycznie używasz w alertach lub dashboardach;
• dla pozostałych (rzadziej używanych) korzystać bezpośrednio z konsoli chmurowej lub query w narzędziu provider’a;
• ustawić dłuższe interwały scrapowania metryk chmurowych, np. 60–120 s, zamiast 15 s;
• agregować metryki po stronie chmury, gdy to możliwe (np. sumaryczne zużycie na ASG zamiast per‑instancja dla krótkotrwałych VM).

Dla wielu zespołów sensowny jest model mieszany: Prometheus trzyma metryki operacyjne i SLI, a szczegółowa analiza kosztów i rzadkie metryki infrastrukturalne idą przez natywne narzędzia typu Cost Explorer, Billing API czy rapor ty usage.

Tagowanie i standaryzacja etykiet

Monitoring w chmurze szybko zamienia się w bałagan, jeśli każda ekipa wymyśla własne etykiety. Dobrze jest na początku ustalić prosty kontrakt na labelach, który później konsekwentnie stosujesz:

• env – środowisko (dev, stage, prod);
• service – nazwa serwisu (spójna z repo i CI/CD);
• team – właściciel (do rozliczeń kosztów i on‑call);
• region, cluster – lokalizacja i klaster.

Te same pola warto mieć też jako tagi w infrastrukturze chmurowej (tagi EC2, label’e w Kubernetes, tagi w bazach danych). Dzięki temu łatwiej łączyć dane z różnych źródeł (Prometheus, billing, CMDB) i odpowiadać na pytania typu „który zespół generuje najwięcej metryk” albo „które serwisy są najbardziej awaryjne vs. kosztują najwięcej”.

Minimalny monitoring kosztów metryk

Monitoring samego systemu monitoringu często jest pomijany, a to on mówi, kiedy zbliżasz się do ściany budżetowej. Kilka prostych metryk do obserwacji:

• prometheus_tsdb_head_series – liczba aktywnych serii (wzrost > X% w krótkim czasie zwykle oznacza złą zmianę w metrykach);
• prometheus_tsdb_head_samples_appended_total – tempo dopisywania próbek;
• prometheus_remote_storage_queue_pending_samples (jeśli używasz remote write) – czy nadążasz z wysyłaniem danych;
• zużycie dysku i IOPS dla wolumenu Prometheus – z metryk systemowych lub chmurowych.

Prosty alert typu „liczba serii wzrosła o 50% w ciągu dnia” pozwala zareagować zanim rachunek za storage eksploduje pod koniec miesiąca. Często wystarczy jedna zła pętla z metrykami w kodzie, żeby wygenerować tysiące niepotrzebnych serii.

Najczęściej zadawane pytania (FAQ)

Dlaczego potrzebuję osobnego monitoringu w chmurze, skoro mam konsolę AWS/Azure/GCP?

Pulpity w konsoli dostawcy chmury są dobre do szybkiego podglądu stanu usług, ale nie zastąpią spójnego monitoringu. Zazwyczaj pokazują tylko wycinek metryk, w różnych miejscach interfejsu, bez jednego widoku na aplikację, infrastrukturę i metryki biznesowe. Przy incydencie kończy się to przeklikiwaniem i zgadywaniem, a nie systematyczną analizą.

Prometheus i Grafana dają jeden punkt prawdy: te same dashboardy dla całego zespołu, jednolite alerty i dobrą historię danych. Dzięki temu możesz szybko odpowiedzieć na pytania typu: „czy problem zaczął się po wdrożeniu?”, „czy brakuje CPU, czy dusi nas baza?”, zamiast tracić czas na skakanie po zakładkach chmurowego panelu.

Jak zacząć monitoring w chmurze z Prometheus i Grafana przy małym budżecie?

Na start wystarczy prosty zestaw: jedna instancja Prometheus, jedna Grafana i kilka eksporterów. Uruchom Prometheus na małej maszynie w tej samej chmurze, co aplikacja, a do tego:

• node_exporter na VM (CPU, RAM, dysk, sieć),
• blackbox_exporter do sprawdzania HTTP/HTTPS z zewnątrz,
• eksporter do bazy (np. postgres_exporter),
• podstawowe metryki aplikacyjne (latencja, kody HTTP, error rate).

Do tego 2–3 sensowne dashboardy i kilka prostych alertów. To wariant „minimum wysiłku, maksimum efektu”, który realnie pomaga na dyżurach, bez budowania klastra monitoringu i skomplikowanej automatyzacji.

Na czym polega różnica między monitoringiem w chmurze a on‑premise?

On‑premise jest zazwyczaj statyczne: hosty zmieniają się rzadko, IP są znane, konfigurację monitoringu aktualizuje się sporadycznie. W chmurze infrastruktura jest dynamiczna: autoskalery tworzą i usuwają VM, pody w Kubernetes dostają efemeryczne IP, a część usług działa jako PaaS, do których nie ma dostępu na poziomie systemu operacyjnego.

To oznacza, że monitoring nie może opierać się na ręcznie wpisanych listach IP. Potrzebne są mechanizmy autodiscovery, integracja z API dostawcy chmury i sensowne etykietowanie zasobów. Prometheus z modelem pull i wbudowanym service discovery (Kubernetes, AWS, GCP, Consul) został zbudowany dokładnie pod taki, „żyjący” świat.

Co konkretnie tracę, jeśli nie mam porządnego monitoringu w chmurze?

Bez metryk powtarza się ten sam scenariusz: zgłoszenie od klienta, panika, Slack pełen domysłów i chaotyczne klikanie po konsoli chmurowej. Nie wiesz, czy winna jest aplikacja, baza, limit połączeń, throttling API czy po prostu brak zasobów. Analiza przyczyny trwa długo, a każda minuta to koszt – finansowy i wizerunkowy.

Druga, często większa strata to przepalanie budżetu: bez danych trudno uargumentować zmniejszenie rozmiaru maszyn, liczby replik czy zmianę konfiguracji autoskalera. Z metrykami z Prometheus i przemyślanymi dashboardami w Grafanie widać, gdzie są realne bottlenecki, a gdzie tylko „na wszelki wypadek” trzymany zapas mocy, który można bezpiecznie ściąć.

Czy Prometheus poradzi sobie z krótkotrwałymi instancjami i autoskalowaniem?

Tak, to jest jego naturalne środowisko. Dzięki modelowi pull i service discovery Prometheus sam okresowo pyta API Kubernetes, AWS, GCP czy Consul o aktualną listę instancji do monitorowania. Konfigurację opierasz na etykietach (labels), a nie na twardo wpisanych IP, więc nowe instancje pojawiają się w monitoringu automatycznie.

Jeżeli instancja żyje kilkanaście minut, ale zdąży wygenerować problemy z wydajnością, Prometheus ją i tak „złapie”, bo to on steruje scrapowaniem. Przy chwilowych problemach sieciowych ma wbudowane retry i spójną semantykę braku danych, co upraszcza później reguły alertujące i zmniejsza liczbę fałszywych alarmów.

Jakie metryki są absolutnym minimum do monitoringu aplikacji w chmurze?

Jeśli budżet i czas są ograniczone, skup się na kilku kluczowych obszarach zamiast monitorować „wszystko”. W praktyce dobre minimum to:

• 4 Golden Signals dla aplikacji: latencja, ruch, błędy, nasycenie (np. kolejki, zużycie CPU),
• infrastruktura VM/kontenerów: CPU, RAM, I/O, sieć,
• baza danych: opóźnienia zapytań, liczba połączeń, błędy, blokady,
• warstwa zewnętrzna: HTTP/HTTPS z punktu widzenia użytkownika (blackbox).

Do tego kilka metryk biznesowych, np. liczba aktywnych użytkowników czy konwersje, podpiętych do Grafany. Taki zestaw daje dobry obraz „czy użytkownik cierpi” i „gdzie boli najbardziej”, bez budowania rozdmuchanego systemu monitoringu.

Jak monitoring Prometheus + Grafana wspiera kulturę DevOps/SRE?

DevOps i SRE opierają się na szybkiej pętli feedbacku: zmiana → obserwacja → korekta. Bez rzetelnych metryk każda zmiana to eksperyment bez pomiaru. Z centralnym monitoringiem większość zmian ma swój wyraźny ślad w danych: wdrożenie nowej wersji, korekta autoskalera, modyfikacja parametrów bazy.

Dashboardy oparte o Golden Signals, alerty powiązane ze SLO oraz przeglądy incydentów z konkretnymi wykresami zamiast ogólników pozwalają podejmować decyzje „na chłodno”. Efekt jest bardzo pragmatyczny: mniej sporów opartych na opiniach, szybsza diagnoza przy incydentach i bardziej świadome decyzje o wydatkach na infrastrukturę.