Grafana to więcej niż wykresy CPU

CPU, pamięć, dysk. Przydatne wykresy. Tylko że pytania w codziennej pracy zwykle idą dalej. Czy backup faktycznie się skończył? Co zmieniło się przed alertem? Które zasoby podbijają rachunek za chmurę? Czy za chwilę nie wygaśnie certyfikat?

Platforma observability, którą zaprojektowałem, zbudowałem i utrzymuję, zbiera te tematy w jednym miejscu. Według mojego zestawienia z października 2026 miała ponad 40 dashboardów zarządzanych jako kod i przetwarzała miliony linii logów dziennie. Najciekawsze jest dla mnie to, co mogę z tymi danymi zrobić. Najlepiej bez otwierania połowy przeglądarki, żeby zrozumieć jeden problem. 🙂

Co robi Grafana, a co działa za nią

W Grafanie odpytuję źródła, przeglądam dane i buduję wizualizacje. Sama Grafana nie jest bazą przechowującą całą telemetrię. Źródła danych łączą ją z systemami, w których te informacje są zapisane. To rozróżnienie dobrze opisuje wprowadzenie do Grafany.

W moim stacku Prometheus obsługuje metryki, a VictoriaLogs centralne logi. Dane dostarczają eksportery, Grafana Alloy i własne kolektory. Obejmuje to metryki maszyn Linux i Windows, informacje o procesach, zdarzenia systemowe i logi aplikacji. Część maszyn można odpytywać bezpośrednio. Inne potrzebują agenta, który wysyła dane na zewnątrz. Sposób zbierania dopasowuję do dostępnej komunikacji.

Podobnie można podejść do informacji, które nie zaczynają życia jako metryka CPU. Kolektor odpytuje API, wybiera potrzebne pola i udostępnia wynik źródłu obsługiwanemu przez Grafanę. Tak z konkretnego pytania operacyjnego zaczyna powstawać dashboard.

Do czego używam tego w praktyce

Backupy i dostępność

To, że maszyna działa, nie mówi mi jeszcze, czy jej backupy są w porządku. Monitoring backupów dokłada status zadań, aktualność kopii i informacje o błędach. Testy dostępności odpowiadają na kolejne pytanie: czy faktycznie da się dotrzeć do usługi?

Dostępność sprawdzam sondami, które odpytują usługę spoza jej własnego procesu. Odpowiedzi HTTP, czas odpowiedzi i termin ważności certyfikatu TLS dają więcej informacji niż sama zielona ikona VM. Historia takich pomiarów może też zasilać raport dostępności za jasno określony okres.

Traktuję te sygnały osobno. Wynik pomiaru dostępności nie zastępuje testu odtwarzania. Każdy odpowiada na inne pytanie i każdy powinien mieć czytelne miejsce na ekranie.

Koszty chmury obok infrastruktury

Własne kolektory dostarczają dane kosztowe z Azure i IONOS. Mogę sprawdzić wydatki w czasie, porównać okresy i zobaczyć, które zasoby lub usługi odpowiadają za zmianę. Rekomendacje Azure Advisor dokładają kolejny kontekst.

Zbieranie tych informacji odbywa się poza Grafaną. Dashboard ułatwia analizę wyników. Dane billingowe mają też własny cykl aktualizacji. Sam wykres nie zamienia ich w rachunek aktualizowany w czasie rzeczywistym.

Zmiany DNS i rzeczy, które wygasają

Audytor DNS sprawdza rekordy i przygotowuje wyniki, które mogę przeglądać w Grafanie. Automatyzacja wokół niego może przekazywać nowe ustalenia do Jira przez n8n. Dostaję konkretną informację, kontekst i miejsce, w którym można dalej obsłużyć temat.

Daty wygaśnięcia poświadczeń to kolejny praktyczny przykład. Kolektory i procesy automatyzacji zbierają terminy ważności certyfikatów i tokenów. Część dat pochodzi z API, inne wymagają prowadzenia rejestru. Dashboard pokazuje identyfikatory i daty, bez wartości sekretów.

Logi, incydenty i zmiany podczas jednej analizy

Kiedy metryka zaczyna się zmieniać, chcę zobaczyć logi z tego samego przedziału czasu. Źródło danych VictoriaLogs pozwala filtrować i przeglądać logi z poziomu Grafany, również w Explore.

Uporządkowane wpisy o deploymentach, wyniki pipeline i historia incydentów dokładają kontekst. Deployment wykonany tuż przed skokiem liczby błędów to dobry trop. Nadal trzeba sprawdzić, czy był przyczyną.

Spójne etykiety robią tu sporą różnicę. Nazwy hostów, usług i środowisk muszą znaczyć to samo w różnych źródłach. Inaczej mam kilka ładnych dashboardów, a całość i tak muszę składać w głowie.

Miniwykres powyżej pokazuje fikcyjny przykład takiej analizy. Najpierw widzę zmianę czasu odpowiedzi i liczby błędów w pobliżu oznaczenia deploymentu. Potem zawężam przedział czasu, otwieram odpowiednie logi i sprawdzam wpis o zmianie. Wykres daje punkt zaczepienia. Dowodów szukam podczas analizy.

Kolejne moduły, których używałem lub które testowałem

Nie ma jednej wtyczki, która robi z Grafany cały taki system. Najwięcej daje połączenie właściwego źródła z konkretnym pytaniem, a potem pilnowanie, żeby to połączenie nadal działało. Z tym samym stackiem łączyłem lub testowałem też takie moduły:

• Bezpieczeństwo firewalli. Zdarzenia z OPNsense tworzą widoki blokowanego ruchu, sygnałów wykrywania intruzów i zmian aktywności w czasie. Zbieranie danych i wykrywanie odbywa się w systemach wokół Grafany. W niej analizuję wzorce i przechodzę do zdarzeń, które za nimi stoją.

• Aktualizacje i zgodność urządzeń Windows. Dane z Windows Update for Business i Microsoft Entra ID pozwalają pokazać zgłoszone wersje systemów, stan aktualizacji i zmiany w środowisku. Ważna jest aktualność źródła. Urządzenie, które od dawna się nie zgłosiło, wymaga innej interpretacji niż takie, którego aktualny stan został potwierdzony.

• Historia incydentów. Dane z PagerDuty dokładają otwarte incydenty oraz historię ich potwierdzania i rozwiązywania. Mogę sprawdzić powracające alerty i ich kontekst. Nie muszę polegać wyłącznie na tym, czy ktoś akurat pamięta podobny przypadek sprzed kilku tygodni.

• Deploymenty i przepływ pracy. Dane z Azure DevOps pozwalają pokazać wyniki pipeline, czas wykonania, oczekiwanie na agenta i przepływ zadań. Wolny deployment może wynikać z błędnego kroku, kolejki albo zablokowanej pracy. Osobne widoki pomagają zadać dokładniejsze pytanie, zanim zacznę coś zmieniać.

• Stan automatyzacji. Historia wykonań n8n pokazuje, które procesy się uruchomiły, które zawiodły i czy zaplanowana praca nadal jest wykonywana. Zapis w platformie logowania pozwala zestawić te informacje z innymi sygnałami. Proces wysyłający tę historię też potrzebuje własnego sygnału sprawności.

• Użycie AI. Zbierane dane o użyciu i cykliczne eksporty pozwalają analizować aktywność, zużycie oraz wykorzystanie usług AI objętych integracją. Oddzielam to od obserwacji pojedynczego zapytania do modelu. Dashboard wykorzystania nie daje automatycznie promptów, śladów wykonania ani oceny jakości odpowiedzi.

• Analiza wspierana przez AI. Testowałem też odpytywanie Grafany przez integrację MCP z asystentem AI. Dobry punkt startowy to analiza z dostępem tylko do odczytu: znaleźć dashboard, odpytać sygnał, obejrzeć przedział czasu. Wyniki nadal trzeba sprawdzać, szczególnie kiedy asystent próbuje wyciągnąć wniosek z niepełnego kontekstu.

W każdym z tych tematów wraca podobny schemat. Zebrać przydatne dane, zachować ich znaczenie i ułatwić następny krok. Sama większa liczba paneli nie poprawia platformy.

Za alertem i raportem musi stać proces

Grafana Alerting sprawdza wybrane warunki i kieruje powiadomienia do punktów kontaktowych, takich jak Teams czy PagerDuty. W moim rozwiązaniu n8n i własna automatyzacja obsługują dodatkowe procesy operacyjne. Alert jest przydatniejszy, kiedy wiadomo, co oznacza i co sprawdzić w następnej kolejności.

Cykliczne raporty dostępności i wydajności przygotowują własne zadania korzystające z danych i renderowanych dashboardów. Generuję też eksporty, kiedy dla odbiorcy praktyczniejszy jest CSV albo arkusz. Harmonogramy, dostarczanie wyników i archiwum są częścią automatyzacji wokół platformy. Mają też własny status, którego trzeba pilnować.

To własny proces raportowania zbudowany wokół stacku. Wbudowane opcje raportowania Grafany zależą od edycji. Dokumentacja raportowania opisuje je osobno.

Muszę też obserwować same kolektory i zadania raportujące. Spokojny dashboard cieszy dopiero wtedy, kiedy wiadomo, że dane nadal do niego docierają.

Platforma też powinna być w kodzie

Dashboardy, źródła danych, reguły alertów i konfigurację trzymam w kontroli wersji. Terraform odpowiada za zasoby chmurowe. Ansible za konfigurację i deployment przez Azure DevOps. Zmiany można przejrzeć, zweryfikować i odtworzyć.

Grafana obsługuje provisioning dashboardów i źródeł danych z plików oraz zasobów alertingu. W mojej platformie trwała wersja zmiany ma być w Git, a nie wyłącznie w sesji przeglądarki.

Tożsamość i uprawnienia też są częścią utrzymania. Korzystałem z logowania przez Microsoft Entra ID, ról Grafany i osobnych organizacji dla zespołów potrzebujących różnych przestrzeni do pracy. Przydatny dashboard nadal musi trafiać do właściwych odbiorców. Samo zalogowanie to tylko część tej decyzji.

Używam też Grafana Advisor jako dodatkowego sprawdzenia samej platformy: stanu źródeł danych, wtyczek i konfiguracji uwierzytelniania. To przydatne narzędzie obok obserwacji kolektorów, planowania retencji i procedur odtwarzania. Uruchomienie kontenerów to początek utrzymania całego stacku.

Szerszy opis rozwiązania jest w projekcie observability. W mniejszym labie zacząłbym od jednej usługi, jej metryk, logów i jednego alertu, na który wiem, jak zareagować. Potem kolejne pytanie operacyjne.