Failure store w Elastic 9.2: odrzucone logi już nie giną

Elastic 9.2 został wydany 23 października 2025 roku. W ogłoszeniu dominują agenci AI i wyszukiwanie wektorowe, ale administrator logów powinien zwrócić uwagę na zmianę, którą Elastic wymienia wśród głównych nowości Elasticsearch 9.2: failure store jest teraz domyślnie włączony dla nowych strumieni danych logów o nazwach pasujących do wzorca logs-*-*. Mechanizm wprowadzono w wersji 9.1. Zmiana domyślnego ustawienia w 9.2 sprawia, że działa w klastrach, w których nikt go świadomie nie włączał, a zmienia też zachowanie odpowiedzi na zapis. Warto wiedzieć, co dokładnie się dzieje.

Problem, który rozwiązuje

Do tej pory dokument, którego Elasticsearch nie mógł zapisać, wracał do klienta jako błąd. Powodem był wyjątek w potoku ingest (pipeline) albo konflikt z mapowaniem, na przykład pole zdefiniowane jako liczba, do którego aplikacja wysłała tekst. Wiele programów wysyłających logi nie ma sensownej obsługi takiego błędu i po prostu porzuca dokument. Dla logów oznacza to, że zdarzenie, które mogło być ważnym sygnałem, znika bez śladu, często właśnie wtedy, gdy zmieni się format logu po aktualizacji aplikacji.

Failure store to dodatkowy zestaw indeksów wewnątrz strumienia danych, przeznaczony na takie dokumenty. Elasticsearch przyjmuje wadliwy dokument, zapisuje go razem z czasem zdarzenia i opisem błędu, a klient dostaje informację o przekierowaniu. Mechanizm nie obejmuje błędów wynikających z przeciążenia (backpressure), uprawnień ani konfliktów wersji dokumentu: te zawsze wracają do klienta, bo wymagają jego reakcji.

Co się zmienia dla klientów

Notatka do wydania 9.2 mówi wprost: gdy failure store jest włączony, kod odpowiedzi przy zapisie nieprawidłowego dokumentu zmienia się z 400 Bad Request na 201 Created, a w odpowiedzi pojawia się dodatkowy atrybut "failure_store": "used". W zapisie zbiorczym (_bulk) element z przekierowanym dokumentem także ma status 201 i ten sam atrybut.

To zmiana, którą trzeba uwzględnić w monitoringu. Jeśli jakiś program, skrypt albo alert reaguje na kody 400 przy zapisie, po aktualizacji przestanie widzieć problem, mimo że dokumenty nadal są odrzucane. Błędy trzeba teraz wyszukiwać w failure store albo sprawdzać atrybut failure_store w odpowiedzi. Pozostałe warianty tego atrybutu to not_enabled (mechanizm mógł przyjąć dokument, ale jest wyłączony, więc błąd wraca jak dawniej) i failed (zapis do failure store się nie udał, na przykład z powodu niedostępnego shardu).

Jak włączyć go tam, gdzie nie działa samo

Domyślne włączenie dotyczy nowych strumieni logs-*-*. Dla pozostałych strumieni, w tym logów w wersji 9.1 i starszych, trzeba włączyć mechanizm samodzielnie. Są trzy sposoby.

W szablonie indeksu, dla nowych strumieni:

PUT _index_template/moj-szablon
{
  "index_patterns": ["aplikacja-*"],
  "data_stream": {},
  "template": {
    "data_stream_options": { "failure_store": { "enabled": true } }
  }
}

Dla strumienia, który już istnieje (sekcja data_stream_options z szablonu działa tylko przy tworzeniu strumienia):

PUT _data_stream/aplikacja-produkcja/_options
{ "failure_store": { "enabled": true } }

Dla wielu strumieni naraz, ustawieniem klastra data_streams.failure_store.enabled, które przyjmuje listę wzorców nazw. Opcje ustawione na samym strumieniu mają pierwszeństwo przed tym ustawieniem. Notatki do 9.2 mówią też, że mechanizm jest włączany dla nowo tworzonych strumieni danych OpenTelemetry.

Jak szukać błędów

Wadliwe dokumenty są w osobnych indeksach, więc zwykłe zapytania ich nie pokazują. Dopisujesz do nazwy strumienia selektor ::failures:

FROM logs-*::failures
| WHERE @timestamp > NOW() - 1 day
| STATS bledy = COUNT(*) BY document.index, error.type
| SORT bledy DESC

Takie zestawienie od razu pokazuje, które strumienie i jakiego rodzaju błędy są najczęstsze. Dokument w failure store zawiera czas wystąpienia błędu, identyfikator i nazwę strumienia, treść oryginalnego dokumentu (w polu document.source), typ i komunikat błędu, a przy błędach potoku także nazwę potoku i procesora. Po poprawie mapowania albo potoku wadliwe dokumenty można ponownie zaindeksować, a nie tracić.

W Kibanie od wersji 9.1 na stronie jakości zestawów danych (Data Set Quality) widać metryki failure store, a interfejs informuje, gdy mechanizm nie jest włączony dla danego strumienia.

Retencja i dane wrażliwe

Domyślnie dane w failure store przechowywane są 30 dni, przez wewnętrzny cykl życia strumienia danych. Okres zmienisz ustawieniem klastra data_streams.lifecycle.retention.failures_default albo w opcjach pojedynczego strumienia, a obowiązuje też maksymalna retencja ustawiona w klastrze. Przy włączaniu mechanizmu zwróć uwagę na dwie sprawy z dokumentacji.

Po pierwsze, dokument przekierowany po błędzie potoku trafia do failure store w oryginalnej, nieprzetworzonej postaci. Jeśli potok ukrywa dane wrażliwe (maskuje numery, usuwa pola), w failure store może znaleźć się wersja bez maskowania. Dlatego dostęp do niej wymaga osobnego uprawnienia read_failure_store na strumieniu. Przyznawaj je wąsko i uwzględnij w przeglądzie uprawnień.

Po drugie, wadliwe dokumenty mają inną strukturę niż zwykłe dane. Jeśli korzystasz z zabezpieczeń na poziomie dokumentów lub pól (DLS i FLS), reguły napisane dla normalnych dokumentów mogą nie działać tak samo dla dokumentów z failure store.

Co jeszcze w 9.2 dla osób pracujących z ES|QL

Polecenie LOOKUP JOIN, które opisywaliśmy w tekście o wzbogacaniu logów w ES|QL, w 9.2 obsługuje dopasowanie po kilku polach i indeksy zdalne (wyszukiwanie między klastrami). Dopasowanie po wyrażeniach, na przykład z operatorami większe lub mniejsze, ma w tej wersji status podglądu technicznego. Dochodzą też polecenia do analizy szeregów czasowych, w tym TS.

Co z tego zrobić po aktualizacji

1. Sprawdź, czy któryś alert lub skrypt opiera się na kodzie 400 przy zapisie, i zamień go na kontrolę failure store.
2. Ustal, kto ma prawo odczytu ::failures, i czy potoki maskujące dane wymagają dodatkowej ostrożności.
3. Włącz mechanizm dla istniejących strumieni logów, które ważą dla Ciebie najwięcej, a potem dla pozostałych.
4. Zbuduj jeden dashboard lub alert z liczbą błędów na dobę. Nagły wzrost zwykle oznacza, że aplikacja zmieniła format logów.

Jeśli aktualizujesz z 8.x, przeczytaj najpierw nasz tekst o kolejności aktualizacji z 8.x do 9.x. Konfigurację failure store i uprawnień do niego ustawiamy w ramach zarządzania logami.