Elastic 9.4 dla metryk: zarządzany punkt OTLP i PromQL

Elastic 9.4 ukazał się 5 maja 2026. W ogłoszeniu producent wyraźnie stawia na metryki: chce, żeby Elasticsearch przechowywał je tak samo dobrze jak logi. Dla zespołów, które dziś trzymają metryki w Prometheusie, Grafanie albo w usłudze SaaS, interesujące są trzy rzeczy: zarządzany punkt OTLP w Elastic Cloud, natywna obsługa PromQL oraz zmiany w indeksach szeregów czasowych. Poniżej opisujemy każdą z nich razem ze statusem, bo część funkcji jest nadal w podglądzie technicznym.

Co w 9.4 dotyczy metryk

Funkcja	Status w 9.4	Uwagi
Zarządzany punkt OTLP (managed OTLP endpoint)	GA	Elastic Cloud Hosted (wersja 9.0 lub nowsza) i Serverless
Natywna obsługa Prometheusa i PromQL	Podgląd techniczny	Zapis przez remote write i zapytania PromQL w Kibanie
Obsługa szeregów czasowych w ES|QL (komenda TS, funkcje rate, changes i inne)	GA	Uzupełnia ją filtrowanie po całym zakresie czasu
Poprawki wydajności TSDB	GA	Liczby producenta, nie nasze pomiary

Statusy pochodzą z ogłoszenia Elastic 9.4 i dokumentacji. Elastic podaje w nim, że zajętość miejsca na metryki jest 2,6 razy lepsza niż w Prometheusie, a zapytania szybsze nawet 30 razy niż w Prometheusie i Mimirze. To wyniki z benchmarków producenta. Przy własnym wolumenie i własnych zapytaniach wynik może być inny, dlatego przed decyzją o migracji warto zrobić test na próbce.

Zarządzany punkt OTLP: dane bez własnego kolektora

OpenTelemetry Protocol (OTLP) to otwarty protokół przesyłania logów, metryk i śladów. W Elastic Cloud możesz wskazać aplikacjom adres zarządzanego punktu i wysyłać dane bez uruchamiania własnego kolektora do podstawowego zbierania. Dokumentacja podaje, że punkt obsługuje logi, metryki i ślady. Adres znajdziesz w konsoli Elastic Cloud w sekcji Application endpoints.

Uwierzytelnianie odbywa się kluczem API z uprawnieniem event:write do aplikacji apm. Klucz utworzony w Kibanie nie ma przedrostka schematu, więc dopisz go sam. Konfiguracja kolektora OpenTelemetry wygląda tak:

exporters:
  otlp:
    endpoint: https://<adres-punktu-otlp>
    headers:
      Authorization: ApiKey <klucz-api>

A dla aplikacji ze zmiennymi środowiskowymi SDK:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://<adres-punktu-otlp>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <klucz-api>"

Trzy rzeczy, o których dokumentacja mówi wprost i które warto wziąć pod uwagę:

• Zawężenie klucza do indeksów nie jest jeszcze obsługiwane. Klucze z własnymi uprawnieniami na poziomie indeksu kończą się błędem PermissionDenied.
• Dane są zapisywane w natywnym formacie OpenTelemetry, bez tłumaczenia na ECS. Własne atrybuty trafiają do attributes.* z zachowanymi kropkami. Starszy sposób przyjmowania danych przez APM Server tłumaczy dane na ECS i zapisuje atrybuty w labels.*, więc istniejące dashboardy i reguły mogą wymagać poprawek pól.
• To zarządzany punkt w chmurze. Dla klastrów na własnej infrastrukturze nadal potrzebny jest kolektor lub Elastic Agent pracujący jako brama.

O tym, jak zbudować architekturę z kolektorem i dlaczego OpenTelemetry opłaca się wprowadzić niezależnie od wyboru backendu, piszemy w tekście o OpenTelemetry obok Elastic i Grafany.

PromQL w Elasticsearch: podgląd, ale warto go znać

Elastic zapowiada natywną obsługę Prometheusa: dane można wysyłać mechanizmem remote write, a zapytania PromQL uruchamiać w Kibanie. W 9.4 ma to status podglądu technicznego. Dokumentacja opisuje domyślną ścieżkę zapisu /_prometheus/api/v1/write, a konfiguracja po stronie Prometheusa to kilka linii:

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. Klucz musi mieć prawo zapisu do docelowego strumienia danych. PromQL działa na metrykach przechowywanych w strumieniach danych szeregów czasowych (TSDS), a Elasticsearch tłumaczy zapytanie na plan ES|QL i wykonuje go tym samym silnikiem co komendę TS.

Podgląd techniczny oznacza, że szczegóły mogą się zmienić, a nie wszystkie funkcje PromQL są obsługiwane. Zgodność opisuje osobna strona dokumentacji. Naszym zdaniem to dobry moment na test równoległy: zostaw Prometheusa jako źródło prawdy i podłącz Elastic jako drugi cel zapisu, i porównaj wyniki kilku ważnych zapytań. Nie planuj na tym etapie wyłączania istniejącego monitoringu.

ES|QL i szeregi czasowe

Obsługa szeregów czasowych w ES|QL ma w 9.4 status GA. Doszły funkcje rate, changes, cumulative, trange i clamp oraz pełne filtrowanie po zakresie czasu. Dla zespołu, który buduje alerty i dashboardy na metrykach, to znaczy, że typowe wyrażenia (szybkość zmiany licznika, wykrywanie zmian) da się zapisać natywnie, bez obejść.

Zmiany, na które trzeba uważać przy aktualizacji

Uwagi do wydania 9.4 opisują trzy zmiany niezgodne wstecz, które dotyczą właśnie metryk:

1. Wykładnicze histogramy są domyślne dla danych OTLP. Jeśli Twoje zapytania zakładają klasyczne histogramy, sprawdź je po aktualizacji.
2. Indeksy szeregów czasowych mają wyłączone numery sekwencyjne. Operacje z if_seq_no kończą się błędem, a update_by_query i delete_by_query działają bez wykrywania konfliktów. Poprzednie zachowanie przywraca ustawienie index.disable_sequence_numbers na false.
3. Downsampling w ILM nie wykonuje już domyślnie force merge. Jeśli na tym polegasz, dodaj akcję force merge do polityki albo ustaw force_merge_index na true.

Przed aktualizacją przejrzyj uwagi o zmianach niezgodnych wstecz dla każdej wersji pomiędzy obecną a docelową.

Dla kogo to ma sens

Zarządzany punkt OTLP ma największy sens dla firm, które już korzystają z Elastic Cloud i wprowadzają OpenTelemetry w aplikacjach: oszczędzasz utrzymanie kolektora w prostych scenariuszach, ale nadal możesz go dodać tam, gdzie potrzebujesz przetwarzania danych przed wysyłką. PromQL jest dla zespołów z Prometheusem, które chcą ocenić Elastic jako jedno miejsce na logi i metryki. Jeśli Twoje metryki pochodzą z agentów Elastic i nie planujesz zmian, 9.4 jest przede wszystkim aktualizacją wydajnościową, a najważniejsze będzie przejrzenie zmian niezgodnych wstecz.

Od czego zacząć

Jeśli używasz Elastic Cloud, zacznij od jednej aplikacji, która już wysyła dane OpenTelemetry, i skieruj jej wyjście na zarządzany punkt. Jeśli korzystasz z Prometheusa, uruchom równoległy zapis do Elastic na środowisku testowym. W obu przypadkach przejrzyj reguły alertów pod kątem zmian w nazwach pól.

Monitoring metryk, logów i śladów na Elastic wdrażamy w ramach monitoringu aplikacji, także z porównaniem z istniejącymi narzędziami.