Elastic 9.3: pattern_text, Streams i Workflows dla logów

Elastic 9.3 trafił do ogólnej dostępności 3 lutego 2026. W ogłoszeniu najwięcej miejsca zajmują agenci AI i wyszukiwanie wektorowe, ale administrator, który odpowiada za logi, znajdzie tam kilka zmian ważniejszych dla codziennej pracy. Poniżej opisujemy te, które naszym zdaniem warto sprawdzić na własnych danych, i zaznaczamy, które są już gotowe do produkcji, a które nadal mają status podglądu technicznego.

Co jest w 9.3 dla logów i obserwowalności

Funkcja	Status w 9.3	Dla kogo
Pole pattern_text	GA (w 9.2 był podgląd)	Zespoły z dużym wolumenem logów tekstowych
Streams: agentowe parsowanie pola message	Podgląd techniczny	Administratorzy z logami bez struktury
Elastic Workflows	Podgląd techniczny	Zespoły automatyzujące reakcje na alerty
Elastic Agent Builder	GA	Zespoły budujące własnych agentów AI na danych w Elasticsearch
Metryki w ES|QL (komendy szeregów czasowych, wykładnicze histogramy)	Podgląd techniczny	Zespoły z metrykami w Elasticsearch

Statusy pochodzą z ogłoszenia Elastic 9.3 i dokumentacji pól. Przy planowaniu wdrożenia wracaj do dokumentacji danej funkcji, bo podglądy zmieniają się między wydaniami.

pattern_text: mniej miejsca na powtarzalne komunikaty

Logi aplikacyjne w dużej części składają się z tych samych zdań, w których zmieniają się tylko wartości: identyfikator użytkownika, adres, czas trwania. Pole pattern_text to odmiana pola text, która rozdziela taką wartość na szablon (część powtarzalną) i zmienne. Szablon nie jest dostępny bezpośrednio, ale pole <nazwa>.template_id zawiera jego skrót, więc można po nim grupować podobne komunikaty. Elastic podaje, że pole obniża zajętość miejsca nawet o połowę, co jest wartością producenta i zależy od danych.

Dokumentacja opisuje też ograniczenia, które trzeba znać przed zmianą mapowania:

• dokument nie może mieć kilku wartości w tym polu, bo zapis zwróci błąd,
• zapytania typu span nie są obsługiwane, zamiast nich używa się zapytań interval,
• podobnie jak text, pole nie służy do sortowania i ma ograniczone agregacje,
• zapytania frazowe zwracają stałą ocenę 1.0, więc nie ma rankingu trafności,
• funkcja wymaga subskrypcji.

Dla logów to zwykle akceptowalna cena, bo szukamy zdarzeń, a nie najlepiej dopasowanych dokumentów. Dla indeksów, w których trafność wyników ma znaczenie, zostań przy text.

Jak to sprawdzić na własnych danych

Najrzetelniejszy test to porównanie tych samych dokumentów w dwóch indeksach. Utwórz indeks testowy z polem pattern_text i sortowaniem po identyfikatorze szablonu (dokumentacja podaje, że kompresja poprawia się wyraźnie, gdy indeks jest posortowany po template_id):

PUT logi-test-pattern
{
  "settings": {
    "index": {
      "sort.field": [ "message.template_id", "@timestamp" ],
      "sort.order": [ "asc", "desc" ]
    }
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "message": { "type": "pattern_text" }
    }
  }
}

Następnie skopiuj do niego próbkę produkcyjnych logów z kilku dni i porównaj rozmiar z indeksem, w którym message jest zwykłym text:

POST _reindex
{
  "source": { "index": "logi-produkcyjne-probka" },
  "dest": { "index": "logi-test-pattern" }
}

GET _cat/indices/logi-*?v&h=index,docs.count,pri.store.size

Porównuj oba indeksy po zakończeniu scalania segmentów i na tej samej liczbie dokumentów. Sprawdź też, czy zapytania, których używają Twoje dashboardy i reguły alertów, nadal działają. Jeśli korzystasz z fraz w cudzysłowie albo zapytań span, zobaczysz różnicę od razu.

Dokumentacja opisuje również ustawienie index.logsdb.default_sort_on_message_template, które dla pola pattern_text o nazwie message włącza sortowanie po szablonie komunikatu. Przy indeksach w trybie LogsDB sprawdź je zanim zaczniesz ustawiać sortowanie ręcznie.

Pytania przed testem

Zanim zmienisz mapowanie, odpowiedz na trzy pytania. Które źródła logów zajmują najwięcej miejsca? Czy komunikaty w tych źródłach są powtarzalne (logi aplikacji, urządzeń sieciowych), czy raczej unikalne (zrzuty błędów z całymi stosami wywołań)? Czy ktoś w zespole używa wyszukiwania fraz lub zapytań span w dashboardach i regułach? Pole pattern_text daje najwięcej tam, gdzie komunikaty się powtarzają, a nikt nie polega na rankingu trafności. Jeśli większość miejsca zajmują unikalne długie wpisy, oszczędność będzie mniejsza niż w przykładach producenta.

Streams i parsowanie pola message

Streams to zestaw funkcji Elastic do pracy z logami, wprowadzony w wersji 9.2. W 9.3 doszedł agentowy proces, który analizuje pole message i proponuje sposób jego rozbicia na pola. Jest to podgląd techniczny, więc traktuj go jako pomoc przy pierwszej analizie, a nie jako zamiennik przemyślanego potoku przetwarzania (ingest pipeline). Propozycje parsowania sprawdzaj na próbce, zanim zapiszesz je dla całego strumienia. Porządkowanie przechowywania i parsowania logów w całej organizacji to osobny temat, którym zajmujemy się przy wdrożeniach.

Workflows: automatyzacja w podglądzie

Elastic Workflows to wbudowana w Kibanę automatyzacja oparta na regułach, z wyzwalaczami ręcznym, harmonogramowym i alertowym. W 9.3 funkcja ma status podglądu i jest domyślnie wyłączona. Dokumentacja podaje, że włącza się ją w ustawieniach zaawansowanych Kibany przez opcję workflows:ui:enabled, a dostęp do niej reguluje uprawnienie Workflows w sekcji Analytics. Na środowiskach produkcyjnych nie warto budować na podglądzie procesów, od których zależy reakcja na incydenty.

Na co uważać przy aktualizacji do 9.3

Lista zmian niezgodnych wstecz dla 9.3 jest krótka. Elastic opisuje m.in. natywny syntetyczny _source dla znormalizowanych pól keyword oraz wyłączenie funkcji międzyklastrowych dla _fleet/_fleet_search i _fleet/_fleet_msearch. Jeśli używasz Fleet w układzie wielu klastrów, sprawdź to przed aktualizacją. Jeśli aktualizujesz z wersji 8.x, zacznij od przeglądu indeksów i ustawień, bo 9.x wymaga kilku kroków przygotowawczych.

Kilka praktycznych zasad, które stosujemy u klientów:

1. Nowe typy pól sprawdzaj na kopii próbki danych, nie na indeksie produkcyjnym.
2. Funkcje w podglądzie technicznym włączaj tylko na środowisku testowym i zapisuj, które z nich Twój zespół faktycznie używa.
3. Przed aktualizacją przeczytaj uwagi o zmianach niezgodnych wstecz dla każdego wydania pomiędzy obecną a docelową wersją.

Co z tego wynika dla Twojego klastra

Jeśli koszt przechowywania logów jest dziś największą pozycją w rachunku za klaster, pattern_text jest najłatwiejszym kandydatem do testu w wersji 9.3. Jeśli problemem jest parsowanie niestrukturalnych logów, wypróbuj Streams na kopii danych. Automatyzację w Workflows na razie testuj tylko poza produkcją, dopóki funkcja ma status podglądu.

Dobór mapowań, aktualizacje i analizę kosztów przechowywania wykonujemy w ramach wdrożeń Elastic.