Z Grafany i Datadog na Elastic: PromQL w wersji 9.5

Przenoszenie monitoringu z jednego narzędzia na drugie rzadko zawodzi na samej technice zbierania danych. Zwykle zajmuje najwięcej czasu odtwarzanie dashboardów i reguł alertów, które zespół budował latami. Wydanie Elastic 9.5 z 4 sierpnia 2026 dotyka obu miejsc: natywny PromQL dostał status GA, a Elastic opisuje narzędzie do przenoszenia dashboardów i alertów z Grafany i Datadog do Kibany. Poniżej piszemy, co to realnie zmienia przy migracji, i gdzie nadal trzeba pracy ręcznej.

Co w 9.5 dotyczy migracji

Funkcja	Status według Elastic
Natywny zapis Prometheus remote write i PromQL w ES|QL	GA w Elastic Stack od 9.5 (w 9.4 podgląd)
Narzędzie migracji dashboardów i alertów z Grafany i Datadog	GA według ogłoszenia 9.5
Integracja Kubernetes (dashboardy, alerty, SLO, zadania ML)	GA
Integracja AWS	Podgląd techniczny
Tryb Columnar (indeksowanie kolumnowe)	Podgląd techniczny

Źródła: ogłoszenie Elastic 9.5 i dokumentacja PromQL. Dokumentacja potwierdza status PromQL: GA w Elastic Stack od 9.5 i w Serverless, podgląd w 9.4.

PromQL: istniejące zapytania Grafany bez przepisywania

Największą korzyścią dla zespołów z Grafaną jest to, że wiele ich zapytań napisanych w PromQL można uruchomić na danych w Elasticsearch, bez przepisywania na inny język zapytań. Zapytania działają przez API zgodne z Prometheusem (prefiks /_prometheus/) albo przez komendę PROMQL w ES|QL. Elasticsearch tłumaczy PromQL na plan ES|QL i wykonuje go tym samym silnikiem co komendę TS. Wymagane jest, by metryki leżały w strumieniach danych szeregów czasowych (TSDS), a dane mogą pochodzić z remote write, OTLP albo z interfejsu bulk.

Zapis z istniejącego Prometheusa to krótka konfiguracja:

remote_write:
  - url: "https://<adres-elasticsearch>/_prometheus/api/v1/write"
    authorization:
      type: ApiKey
      credentials: "<klucz-api>"

Domyślnie dane trafiają do strumienia metrics-generic.prometheus-default, a klucz API musi mieć prawo zapisu do niego. Zgodność z Prometheusem nie jest pełna. Elastic prowadzi osobną stronę, na której wymienia obsługiwane i nieobsługiwane funkcje oraz różnice w zachowaniu, i na niej opieraj się przy ocenie, czy Twoje zapytania przejdą bez zmian.

Narzędzie migracji: ile można mu zaufać

W ogłoszeniu 9.5 narzędzie do przenoszenia dashboardów i alertów z Grafany i Datadog ma status GA. Tu warto zachować ostrożność, bo inne źródła Elastic opisują je ostrożniej. Wpis Elastic z 28 kwietnia 2026 nazywa je platformą migracji obserwowalności (obs-migrate) i mówi, że narzędzie „wciąż się rozwija”: dla Grafany pokrycie jest szersze, dla Datadog węższe. Dokumentacja migracji z Datadog w chwili pisania tego tekstu nadal opisuje ręczne odtwarzanie dashboardów i monitorów. Rozsądnie jest więc traktować narzędzie jako przyspieszenie pracy, a nie jako przycisk „migruj”.

Z opisu we wpisie z kwietnia wynika, jak narzędzie pracuje:

• czyta dashboardy i alerty z plików eksportu albo z API Grafany i Datadog,
• tłumaczy zapytania i panele na obiekty Kibany, a gdy tłumaczenie nie jest bezpieczne, oznacza panel do ręcznej poprawki albo zastępuje go bezpiecznym zamiennikiem,
• wynik można zweryfikować względem klastra i wgrać do Kibany,
• zaimportowane reguły alertów są domyślnie wyłączone, dopóki ich nie przejrzysz,
• po przebiegu zostają raporty (migration_report.json, verification_packets.json, run_summary.json) pokazujące, co przeszło czysto, a co wymaga uwagi.

Przykładowe wywołanie z tego wpisu dla Grafany z plików wygląda tak:

obs-migrate migrate \
  --source grafana \
  --input-mode files \
  --input-dir ./grafana_exports \
  --output-dir ./migration_output \
  --assets all \
  --native-promql \
  --data-view "metrics-*" \
  --validate \
  --upload

W oryginale dochodzą jeszcze adresy i klucze Elasticsearch oraz Kibany. Zwróć uwagę, że wpis opisuje przebieg na projekcie Elastic Observability Serverless, więc dla klastra na własnej infrastrukturze sprawdź w dokumentacji, czy jest to ścieżka obsługiwana.

Jak planujemy taką migrację

Przy takim przenoszeniu o powodzeniu decyduje kolejność i okres pracy równoległej, a nie wybór narzędzia. Polecamy taki porządek:

1. Inwentaryzacja. Lista dashboardów i alertów, które ktoś faktycznie używa. Często część z nich nikt nie otwiera od dawna i nie trzeba jej przenosić.
2. Równoległy zapis. Dane trafiają do starego i nowego systemu jednocześnie. Dla Prometheusa to drugi wpis remote_write, dla OpenTelemetry drugi eksporter w kolektorze. Szczegóły dla wysyłki z OTLP opisaliśmy w tekście o Elastic 9.4 dla metryk.
3. Migracja i przegląd dashboardów. Narzędzie wykonuje ciężką część, człowiek sprawdza każdy ważny panel względem starego wykresu.
4. Alerty. Włączaj je po kolei i porównuj z tym, co zgłaszał stary system, przez co najmniej kilka tygodni.
5. Wyłączenie starego systemu dopiero po okresie bez rozbieżności.

Integracje i onboarding w 9.5

Poza migracją 9.5 upraszcza także samo podłączanie źródeł. Integracja Kubernetes ma status GA i dostarcza dashboardy, alerty, SLO i zadania uczenia maszynowego. Ogłoszenie opisuje też uproszczony onboarding Kubernetes i AWS, który domyślnie używa ścieżki OpenTelemetry, oraz zarządzane integracje pobierające dane z chmury bez agentów w siedzibie klienta. Dla firm przenoszących monitoring oznacza to mniej ręcznej konfiguracji, ale nadal trzeba sprawdzić, czy metryki z nowego źródła mają te same nazwy i etykiety, na które powołują się przeniesione dashboardy.

Zmiany z 9.5, które trzeba znać przy aktualizacji

Uwagi do wydania 9.5 wymieniają m.in. zmianę czasu look-ahead w strumieniach danych szeregów czasowych: z 30 do 9 minut. Dokumenty z czasem w przyszłości o więcej niż 9 minut będą odrzucane. Jeśli Twoje agenty lub urządzenia mają niedokładny zegar, sprawdź to przed aktualizacją. Poprzednią wartość przywracasz ustawieniem index.look_ahead_time w szablonach. Przed aktualizacją przejrzyj też pełną listę zmian niezgodnych wstecz.

Kiedy ma to sens

Przejście na Elastic opłaca się najbardziej, gdy logi, metryki i ślady chcesz mieć w jednym miejscu, a zespół zna już PromQL. Jeśli Grafana i Prometheus działają dobrze i nikt nie narzeka na koszty, nie ma powodu ich ruszać. Przenoszenie monitoringu z Grafany, Datadog i Splunk na Elastic prowadzimy w ramach migracji monitoringu.