ES|QL w Elasticsearch 9.1: LOOKUP JOIN do wzbogacania logów

29 lipca 2025 roku Elastic wydał Elasticsearch 9.1 oraz 8.19, ostatnią wersję z linii 8.x. Najwięcej uwagi w ogłoszeniu dostały wektory i AI, ale dla zespołu, który na co dzień pracuje z logami i alertami, najważniejsza jest zmiana w ES|QL, czyli piszącym się potokowo języku zapytań Elasticsearch: polecenie LOOKUP JOIN ma status GA (ogólnej dostępności). Do tej pory było w podglądzie technicznym, od 9.1 i 8.19 można je włączać do zapytań, które mają działać w produkcji. Poniżej opisujemy, do czego się przydaje, jak je ustawić i które ograniczenia warto znać przed pierwszym użyciem.

Co robi LOOKUP JOIN

Polecenie dołącza do wyników zapytania kolumny z drugiego, niewielkiego indeksu (indeksu wyszukiwania), jeśli wartość w wybranym polu jest taka sama po obu stronach. Działa jak złączenie lewostronne z SQL: wiersz bez dopasowania zostaje w wynikach, a nowe kolumny dostają wartość null. Jeśli pasuje kilka dokumentów z indeksu wyszukiwania, w wynikach pojawi się kilka wierszy.

W praktyce oznacza to, że dane referencyjne nie muszą już trafiać do każdego dokumentu przy zapisie. Typowe zastosowania:

• sprawdzenie, czy adresy źródłowe w logach firewalla są na liście znanych złośliwych adresów,
• dopisanie do metryk informacji o właścicielu i środowisku hosta z inwentarza,
• oznaczenie logów aplikacji zespołem odpowiedzialnym za usługę, żeby szybciej kierować zgłoszenia.

Jak to ustawić

Indeks wyszukiwania musi mieć tryb lookup. Takie indeksy zawsze mają jeden shard, więc nadają się na listy, a nie na dane o dużym wolumenie. Przykład z listą zagrożeń:

PUT threat_list
{
  "settings": { "index.mode": "lookup" },
  "mappings": {
    "properties": {
      "source.ip":    { "type": "ip" },
      "threat_level": { "type": "keyword" },
      "threat_type":  { "type": "keyword" }
    }
  }
}

Zapytanie łączy logi firewalla z tą listą i zostawia tylko trafienia:

FROM firewall_logs
| LOOKUP JOIN threat_list ON source.ip
| WHERE threat_level IS NOT NULL
| SORT @timestamp
| KEEP @timestamp, source.ip, action, threat_type, threat_level
| LIMIT 100

Dwie uwagi praktyczne. Kolejność wyników po LOOKUP JOIN nie jest gwarantowana, więc jeśli jej potrzebujesz, dodaj SORT. Poza tym zapytania działają szybciej, gdy do złączenia trafia mniej wierszy, dlatego filtr WHERE na danych źródłowych warto umieścić przed LOOKUP JOIN. Elasticsearch stara się to zrobić sam tam, gdzie to możliwe.

LOOKUP JOIN czy ENRICH

Wzbogacanie logów da się robić także procesorem enrich przy zapisie. Różnica jest taka, że enrich wymaga polityki i jej wykonania po każdej zmianie danych, a indeks wyszukiwania aktualizujesz zwykłym zapisem i kolejne zapytanie od razu widzi zmianę. Dokumentacja Elastic wskazuje LOOKUP JOIN jako lepszy wybór, gdy:

Sytuacja	Wybór
Dane referencyjne często się zmieniają	LOOKUP JOIN
Nie chcesz przetwarzać danych przy zapisie	LOOKUP JOIN
Dopasowanie ma być po dowolnym polu indeksu	LOOKUP JOIN
Używasz zabezpieczeń na poziomie dokumentów lub pól	LOOKUP JOIN
Potrzebujesz dopasowania po zakresach lub relacjach przestrzennych	ENRICH

Ostatni wiersz pokazuje, że ENRICH nie znika. Przy dopasowaniu do zakresów adresów IP albo do lokalizacji nadal będzie właściwym narzędziem.

Ograniczenia w wersji 9.1

Zanim zaplanujesz na tym raporty, sprawdź ograniczenia z dokumentacji dla wersji 9.0 i 9.1:

• złączenie jest po jednym polu i tylko po równości, nie po zakresach,
• indeks wyszukiwania musi być jeden, bez wildcardów (alias lub konkretna nazwa),
• nazwa pola w ON musi istnieć w wynikach zapytania, więc czasem potrzebny jest RENAME lub EVAL,
• zapytanie przerywa się zabezpieczeniem pamięci (circuit breaker), jeśli dopasowanych dokumentów jest zbyt wiele albo są bardzo duże, bo złączenie działa partiami po około 10 000 wierszy,
• w tych wersjach złączenie nie działa w zapytaniach między klastrami, a oba indeksy muszą być lokalne.

Na liście nowości 9.1 jest za to kilka ulepszeń: złączenie po polach liczbowych o różnych, ale zgodnych typach (np. long z integer), obsługa aliasów oraz pól date_nanos bez utraty precyzji.

Co jeszcze zmienia się w ES|QL po aktualizacji

Wydanie 8.19 i 9.1 zmienia też zachowanie domyślne, o którym powinni wiedzieć ci, którzy mają alerty lub raporty oparte na ES|QL.

Ustawienie allow_partial_results jest teraz włączone domyślnie. Jeśli jeden shard jest chwilowo niedostępny, zapytanie zwróci wyniki z pozostałych, zamiast kończyć się błędem. Podobnie skip_unavailable obejmuje więcej błędów na zdalnych klastrach. Odpowiedź zawiera flagę is_partial, którą trzeba sprawdzać wszędzie tam, gdzie liczy się kompletność danych, na przykład w raportach dla audytora. Zapytania ponawiają się też automatycznie po błędach na poziomie shardów, co pomaga przy restartach węzłów podczas aktualizacji.

Elastic ogłosił w tym wydaniu także ogólną dostępność ES|QL w wyszukiwaniu między klastrami (CCS). Jeśli masz osobne klastry dla logów bezpieczeństwa i obserwowalności, jedno zapytanie może sięgać do obu. Zwracamy uwagę, że to dotyczy samych zapytań, a nie LOOKUP JOIN, który w 9.1 działa tylko lokalnie. Nowe jest także logowanie zapytań ES|QL do pliku, przydatne do wyszukiwania kosztownych zapytań, oraz API listujące zapytania aktualnie wykonywane (to ostatnie w podglądzie technicznym, więc może się jeszcze zmienić).

Jak z tego skorzystać

Na początek wybierz jedną listę, która dziś żyje w arkuszu lub w głowach administratorów: właścicieli systemów, adresy partnerów, znane skanery. Załaduj ją do indeksu w trybie lookup i zbuduj jedno zapytanie lub dashboard w Kibanie, który z niej korzysta. Jeśli to się sprawdzi, kolejne listy dodasz w kilka minut.

Jeśli planujesz aktualizację z 8.x do 9.1, pamiętaj, że wymaga ona wcześniejszego przejścia na 8.19, a wersja 8.19 ma już ten sam LOOKUP JOIN w statusie GA. Można więc zacząć korzystać z nowości jeszcze przed dużą aktualizacją.

Reguły, do których takie wzbogacanie pasuje, opisaliśmy w tekście SIEM na Elastic Security: pierwsze kroki z regułami. Źródła danych i listy referencyjne dobieramy w ramach zarządzania logami.