#grafana agent

Nazwa Grafana Agent pojawia się dziś najczęściej w dwóch sytuacjach: przy spisie oprogramowania zastanego na serwerach i przy czytaniu instrukcji sprzed kilku lat. Program zbierał pomiary z maszyn i odsyłał je do miejsca składowania, a jego rozwój został zakończony. Od tego trzeba zacząć, bo zmienia sens każdego dalszego zdania.

Kombajn zamiast czterech maszyn

Przed nim pole obrabiało się osobno. Jedna maszyna kosiła, druga młóciła, trzecia ładowała ziarno, czwarta zbierała słomę. Każda wymagała paliwa, obsługi i własnego przejazdu, a rolnik pilnował czterech harmonogramów naraz. Kombajn wjeżdża raz i wykonuje wszystkie te czynności w jednym przejeździe, tym samym silnikiem.

Grafana Agent był takim kombajnem dla pomiarów. Zamiast czterech osobnych programów na serwerze, każdego z własnym plikiem ustawień, własnym portem i własną regułą na zaporze, stawiało się jeden proces obsługujący cztery rodzaje danych.

Cztery rodzaje danych z jednego procesu

Zakres był ustalony i wynikał z rodziny narzędzi tego samego producenta.

Największym zaskoczeniem bywa pozycja czwarta. Profil pokazuje nie tylko, że aplikacja zjadła procesor, ale która jej część go zjadła, i przy szukaniu przyczyny bywa wart więcej niż wszystkie wykresy obciążenia razem wzięte.

Trzy postacie pod jedną nazwą

Tu leży źródło nieporozumień przy czytaniu starszej dokumentacji, bo pod jedną nazwą kryły się trzy różne sposoby pracy.

Wariant statyczny był pierwszy. Konfiguracja to plik YAML z trzema działami odpowiadającymi metrykom, dziennikom i śladom, a pod spodem pracowały opakowane oryginalne programy: Prometheus, Promtail i kolektor OpenTelemetry.

Wariant dla Kubernetesa dokładał do tego operatora, czyli składnik obserwujący zasoby w klastrze i układający z nich konfigurację, żeby nikt nie edytował pliku ręcznie przy każdej nowej usłudze.

Wariant przepływowy odwracał sposób opisu. Zamiast działów pojawiły się komponenty, a zamiast listy ustawień połączenia między nimi.

River, czyli ustawienia opisane jak kod

Ostatni wariant miał własny język konfiguracji o nazwie River, wzorowany składniowo na narzędziu Terraform. Blok deklaruje jeden składnik. Każdy taki składnik coś przyjmuje i coś oddaje, a wskazanie tego, co oddaje pierwszy, jako źródła dla drugiego, tworzy między nimi połączenie. Z połączeń powstaje trasa, którą wędrują pomiary.

Zysk był realny: dołożenie nowego źródła nie wymagało przebudowy pliku, a odczytanie, skąd dane przychodzą i dokąd idą, sprowadzało się do prześledzenia strzałek. Cena też była realna, bo taki plik przestaje być zestawem ustawień. Zaczyna być kodem, a kod wymaga wersjonowania, przeglądu przed wypuszczeniem i możliwości cofnięcia zmiany.

Data, po której nie ma już łatek

Producent podał termin i termin minął. Wsparcie dla wszystkich trzech wariantów zakończyło się z ostatnim dniem października 2025 roku, a od 1 listopada 2025 program nie dostaje poprawek błędów ani poprawek bezpieczeństwa. Następcą jest Grafana Alloy, zbudowany na wariancie przepływowym, więc migracja z niego jest przesunięciem, a z wariantu statycznego przepisaniem konfiguracji.

Skutek nie jest teoretyczny. Taki program stoi na każdej maszynie w firmie, czyta pliki z dysku, sięga do punktów pomiarowych i utrzymuje połączenie na zewnątrz sieci. Oprogramowanie o takim zasięgu, które przestało dostawać łatki, jest pozycją na liście ryzyk niezależnie od tego, czy działa poprawnie. A działa poprawnie, i właśnie dlatego zostaje na serwerach latami.

Jak rozpoznać, że gdzieś jeszcze stoi

Ślady są proste do znalezienia. Usługa systemowa o nazwie zawierającej słowo agent, katalog z plikiem konfiguracyjnym w formacie YAML z działami metrics, logs i traces, albo plik z rozszerzeniem wskazującym na River. W klastrze Kubernetes szuka się zasobów utworzonych przez operatora oraz kontenerów działających jako zestaw na każdym węźle.

Sprawdzenie warto zrobić nawet wtedy, gdy nikt nie pamięta, żeby coś takiego stawiał. Agenta zbierającego pomiary instaluje się zwykle raz, przy uruchamianiu monitorowania, i od tej pory nie ma powodu, żeby ktokolwiek do niego wracał.

Kiedy taki program nie był potrzebny

Jedna maszyna z jedną aplikacją nie wymaga pośrednika, bo baza pomiarów sięga po odczyt wprost do niej. Firma mająca już własne monitorowanie z agentami na maszynach dokłada sobie drugi komplet robiący to samo. Sama instalacja agenta bez miejsca składowania, bez progów i bez osoby, która na to patrzy, daje ruch sieciowy i rachunek za przechowywanie, a nie wiedzę o tym, co się dzieje.