Grafana gcx i MCP są już GA: telemetria dla agentów AI

Grafana Labs ogłosiła 28 lipca ogólną dostępność (GA) dwóch narzędzi zaprojektowanych z myślą o pracy agentów kodujących z obserwowalnością: Grafana CLI for AI agents (gcx) oraz Grafana MCP server. Kierunek jest ważniejszy niż sama premiera. Agent AI przestaje pracować wyłącznie na kodzie i testach — może dostać kontrolowany dostęp do metryk, logów, śladów, alertów i dashboardów, a następnie sprawdzić, jak jego zmiana zachowuje się w realnym systemie.

Grafana nazywa ten model telemetry-driven development. Zamiast kończyć zadanie po wygenerowaniu patcha, agent może zebrać dowody: porównać opóźnienia przed i po zmianie, sprawdzić błędy na realistycznym obciążeniu, odczytać SLO albo ocenić wynik testu syntetycznego. To obiecujący krok w stronę bardziej odpowiedzialnej automatyzacji — pod warunkiem że dostęp do telemetrii nie stanie się tylnymi drzwiami do produkcji.

Schemat pracy agenta AI: rdzeń modelu przechodzi przez kontrolowaną bramę do metryk, logów i śladów

Co udostępniła Grafana

Oba narzędzia rozwiązują podobny problem, ale na różne sposoby.

Grafana MCP server wystawia zestaw narzędzi zgodnych z Model Context Protocol. Może być uruchamiany samodzielnie albo używany jako usługa hostowana dla Grafana Cloud. Jest bardziej opiniotwórczy: agent dostaje operacje odpowiadające najczęstszym zadaniom, zamiast dowolnie konstruować każde wywołanie API.

gcx jest interfejsem wiersza poleceń zaprojektowanym do przewidywalnej pracy maszynowej. Zwraca ustrukturyzowane dane JSON lub YAML, ma stabilne kody wyjścia i błędy, którymi agent może sterować w pętli. Obsługuje Grafana Cloud oraz samodzielnie hostowane Grafana OSS i Enterprise w wersji 12 lub nowszej.

CLI daje dostęp do zasobów takich jak:

dashboardy i foldery;
reguły alertów;
źródła danych;
konteksty rozdzielające środowiska;
usługi chmurowe Grafany, w tym Synthetic Monitoring, k6, Fleet Management, Incidents i Adaptive Telemetry.

W praktyce organizacja może użyć MCP do standardowych interakcji w edytorze lub agencie, a gcx do bardziej deterministycznych workflow, automatyzacji i GitOps. Nie trzeba wybierać jednego mechanizmu dla wszystkich przypadków.

Dlaczego agenci kodujący potrzebują telemetrii

Agent dobrze radzi sobie z lokalnym kodem, ale bez danych operacyjnych nie zna środowiska. Może zobaczyć funkcję obsługującą żądanie, lecz nie wie, czy endpoint dostaje dziesięć wywołań na minutę czy sto tysięcy na sekundę. Nie zna typowych rozmiarów payloadu, rozkładu opóźnień ani tego, które błędy są już tolerowane.

Powstaje luka poznawcza: szybkość generowania zmian rośnie szybciej niż zdolność człowieka do rozumienia ich wpływu. Więcej patchy nie musi oznaczać większej produktywności, jeśli zespół spędza później czas na gaszeniu regresji.

Telemetria może tę lukę zmniejszyć. Agent wykonujący zadanie optymalizacyjne może:

odczytać bazowy p95 i p99 dla wybranego endpointu;
znaleźć ślady najwolniejszych żądań;
powiązać je z zapytaniami do bazy i błędami;
przygotować zmianę oraz test;
uruchomić obciążenie w odizolowanym środowisku;
porównać wynik z bazą i limitem SLO;
przedstawić człowiekowi patch razem z dowodami.

To lepszy kontrakt niż polecenie „przyspiesz API”. Kryterium sukcesu staje się mierzalne, a wynik można odtworzyć.

MCP czy CLI: dwa różne kontrakty

MCP jest naturalny dla agenta działającego w rozmowie. Model widzi opis dostępnych narzędzi, dobiera parametry i odczytuje odpowiedź. Zaletą jest elastyczność oraz mały próg integracji. Ryzykiem — większa swoboda interpretacji, zwłaszcza gdy narzędzi jest dużo albo ich uprawnienia są szerokie.

CLI daje bardziej tradycyjny kontrakt automatyzacyjny. Polecenie, kod wyjścia i schemat odpowiedzi da się przetestować, ograniczyć wrapperem i uruchomić w pipeline. gcx wspiera konteksty, dzięki czemu konfiguracje dla developmentu, stagingu i produkcji nie muszą dzielić jednego celu ani tokenu.

Dobrą praktyką jest dobór interfejsu do ryzyka:

odczyt dashboardu w sesji analitycznej może odbywać się przez MCP;
masowe wersjonowanie dashboardów lepiej prowadzić deterministycznym pipeline’em;
zmiany alertów produkcyjnych wymagają przeglądu i zatwierdzenia niezależnie od interfejsu;
eksploracyjne zapytania o wysokim koszcie powinny mieć limity czasu, zakresu i liczby serii.

Telemetria jako część specyfikacji zadania

Najciekawsza zmiana organizacyjna polega na dołączeniu obserwowalności do definicji gotowości. Zadanie dla agenta może zawierać nie tylko testy jednostkowe, ale też:

dozwolony budżet opóźnienia;
maksymalny wzrost liczby błędów;
wymagany wynik testu syntetycznego;
zakaz zwiększania kardynalności metryk;
dashboard i alert, które mają pozostać poprawne;
okno porównawcze oraz minimalną liczbę próbek.

W ten sposób agent nie „uznaje”, że poprawił system. Dostarcza patch, testy i pakiet obserwacji. Człowiek nadal ocenia, czy metryka jest dobrą miarą celu i czy wynik usprawiedliwia wdrożenie.

Ten model dobrze łączy się z lokalnym środowiskiem OpenTelemetry i stosem LGTM. Agent może najpierw instrumentować usługę, uruchomić ją w izolacji, wygenerować kontrolowane obciążenie i przeanalizować logi, metryki oraz trace’y bez dostępu do danych klientów. Więcej o projektowaniu takiej warstwy opisaliśmy w artykule o observability agentów AI z OpenTelemetry.

Najważniejsze ryzyka bezpieczeństwa

Telemetria jest uprzywilejowanym źródłem danych. Logi zawierają identyfikatory użytkowników, fragmenty żądań, nazwy hostów, błędy aplikacji, a czasem również sekrety, które nigdy nie powinny zostać zapisane. Dashboardy i reguły alertów ujawniają architekturę, krytyczne usługi oraz progi reakcji.

Dlatego dostęp agenta powinien opierać się na kilku zasadach.

Domyślnie tylko odczyt

Agent analizujący regresję nie potrzebuje prawa do zmiany alertu ani usunięcia dashboardu. Utwórz osobną tożsamość z minimalnym zakresem i osobne konteksty dla każdego środowiska. Produkcja powinna być read-only, dopóki konkretny workflow nie uzasadni wyjątku.

Zatwierdzanie operacji zmieniających stan

Zmiana reguły alertu, konfiguracji źródła danych lub dashboardu może wyciszyć widoczność incydentu. Operacja zapisu powinna wygenerować czytelny diff i trafić do akceptacji. Warto preferować pull request i GitOps zamiast bezpośredniej mutacji przez sesję agenta.

Ograniczenie kosztu zapytań

Nieprecyzyjne zapytanie może pobrać ogromny zakres logów lub utworzyć kosztowną kardynalność. Limituj czas, liczbę punktów i zakres źródeł. Oddziel piaskownicę od produkcji, a zapytania agenta oznaczaj w logach audytowych.

Ochrona danych w kontekście modelu

Przed wysłaniem wyniku do modelu stosuj redakcję sekretów i danych osobowych. Ustal retencję sesji, dostawcę modelu i region przetwarzania. Token do Grafany nie powinien znaleźć się w promptach, plikach repozytorium ani historii rozmowy.

Bezpieczny serwer MCP

Serwer MCP jest nową granicą zaufania. Trzeba uwierzytelniać klienta, ograniczać narzędzia i weryfikować parametry po stronie serwera, nie polegać na posłuszeństwie modelu. Szczegółowy model zagrożeń opisujemy w przewodniku bezpieczeństwa Model Context Protocol.

Przykładowy bezpieczny workflow

Załóżmy, że agent ma zmniejszyć czas odpowiedzi serwisu płatności.

Otrzymuje read-only kontekst do stagingu i ograniczony zestaw dashboardów.
Pobiera bazową telemetrię oraz identyfikuje konkretny fragment śladu.
Modyfikuje kod w odizolowanej gałęzi i dodaje test regresji.
Uruchamia k6 oraz lokalną telemetrię OpenTelemetry.
Porównuje wynik z wcześniej zapisanym baseline’em.
Tworzy pull request z kodem, danymi i opisem niepewności.
Człowiek zatwierdza wdrożenie canary.
Osobna automatyzacja obserwuje SLO i może wycofać zmianę według z góry ustalonej reguły.

Agent nie otrzymuje prawa do samodzielnego „naprawiania” produkcji. Telemetria daje mu lepsze dowody, a nie automatyczne upoważnienie do działania.

Najczęstsze pytania

Czy gcx zastępuje Grafana API?
Nie. To interfejs przystosowany do przewidywalnej pracy agentów i automatyzacji, z ustrukturyzowanymi wynikami oraz obsługą kontekstów. API pozostaje warstwą bazową dla niestandardowych integracji.

Czy Grafana MCP server działa tylko w Grafana Cloud?
Nie. Można użyć wariantu hostowanego dla Grafana Cloud albo uruchomić serwer samodzielnie.

Czy agent powinien mieć dostęp do produkcyjnych logów?
Tylko wtedy, gdy istnieje uzasadniony przypadek, minimalny zakres, redakcja danych i audyt. Wiele zadań można wykonać na stagingu z realistycznym, zanonimizowanym obciążeniem.

Czy więcej telemetrii automatycznie poprawia kod agenta?
Nie. Agent potrzebuje dobrze dobranych mierników, punktu odniesienia i kryteriów sukcesu. Zła lub niepełna telemetria może prowadzić do równie złych wniosków jak jej brak.

Wniosek

Ogólna dostępność gcx i Grafana MCP server pokazuje, że obserwowalność staje się częścią interfejsu dla agentów AI, a nie tylko ekranem dla człowieka po wdrożeniu. Największa wartość pojawi się tam, gdzie telemetria pełni rolę mierzalnej specyfikacji, a uprawnienia, koszty i zapis zmian są kontrolowane. Jeśli wdrażasz agentów z dostępem do narzędzi firmowych, warto objąć cały przepływ audytem bezpieczeństwa AI i LLM.

Źródła: Grafana Labs — telemetry-driven development z gcx i Grafana MCP, dokumentacja gcx, Grafana AI Week 2026.