Koniec wsparcia Elastic 8.x w 2027: harmonogram aktualizacji

Elastic publikuje terminy wsparcia z dużym wyprzedzeniem, ale w praktyce większość firm zaczyna o nich myśleć dopiero wtedy, gdy dostaje przypomnienie od audytora albo dostawcy. Jeśli Twój klaster działa na wersji 8.x, masz dziś (koniec marca 2026) niespełna dziesięć miesięcy do końca konserwacji. To dużo dla małego klastra i mało dla środowiska, w którym trzeba przeindeksować stare dane, przetestować integracje i zgrać okno serwisowe z kalendarzem biznesu. Poniżej układamy harmonogram wstecz od właściwej daty. Sam przebieg aktualizacji opisaliśmy wcześniej w tekście Aktualizacja Elastic z 8.x do 9.x: kolejność i pułapki.

Co mówi polityka wsparcia

Według strony polityki wsparcia Elastic terminy wyglądają tak:

Wersja	Koniec konserwacji (EOM)	Koniec wsparcia (EOS)
7.17.x	15 kwietnia 2025	15 stycznia 2026
8.x (8.0 do 8.19)	15 stycznia 2027	15 lipca 2027
9.x (seria)	15 października 2027	brak daty na stronie

Konserwacja oznacza poprawki, w tym bezpieczeństwa. Wsparcie to dalsza pomoc techniczna przez sześć miesięcy po końcu konserwacji. Polityka podaje też zasadę ogólną: każda wersja główna jest utrzymywana przez dłuższy z dwóch okresów, 30 miesięcy od wydania albo 18 miesięcy od wydania następnej wersji głównej. Do tego dochodzi zasada dla wydań minor: konserwacją objęte są dwa ostatnie wydania minor bieżącej wersji głównej oraz ostatnie wydanie minor poprzedniej wersji głównej. W tabeli 9.x ma jedną datę dla całej serii, ale w kontrakcie i planie operacyjnym czytaj obie reguły. Wersje 8.17 i 8.18 mają osobne wyjątki: 8.17 była utrzymywana do wydania 8.19, a 8.18 do wydania 9.2.

Wniosek praktyczny: 7.17 jest już poza wsparciem, a klaster 8.x przestanie dostawać poprawki bezpieczeństwa 15 stycznia 2027. Dla firm objętych regulacjami (finanse, ochrona zdrowia, podmioty kluczowe i ważne w rozumieniu KSC) brak poprawek bezpieczeństwa w systemie przechowującym logi i dane o incydentach to temat dla audytu, nie tylko dla działu IT.

Którą wersję 9.x wybrać

Na dziś (marzec 2026) najnowszym wydaniem jest 9.3, opublikowane 3 lutego. Przy wyborze celu bierzemy pod uwagę trzy rzeczy.

1. Ścieżka. Do 9.1 i nowszych trzeba wejść z 8.19.x, więc niezależnie od celu pierwszym krokiem jest 8.19.
2. Zmiany niezgodne wstecz po drodze. Im nowszy cel, tym więcej uwag trzeba przeczytać, bo dokumentacja wymaga przejrzenia zmian dla każdego wydania do wersji docelowej. Oprócz zmian z 9.0 (TLS, Enterprise Search, nazwy w logach deprecjacji) i 9.1 (AWS SDK v2) warto znać dwie późniejsze. W 9.2 interfejs Simulate API zwraca błąd 400 dla niepoprawnych procesorów, normy nie są już włączane dla pól text w indeksach LogsDB i TSDB, a opcja exclude_source_vectors jest domyślnie włączona dla nowych indeksów. W 9.3 pola keyword ze znormalizowanymi wartościami używają natywnego syntetycznego _source, a funkcje międzyklastrowe są wyłączone dla _fleet/_fleet_search i _fleet/_fleet_msearch.
3. Funkcje, których potrzebujesz. Jeśli celem aktualizacji jest oszczędność miejsca na logach, sprawdź pole pattern_text (GA od 9.3), które opisujemy w tekście o Elastic 9.3. Jeśli nie ma konkretnej potrzeby, wybierz najnowszą łatkę wydania, które ma za sobą kilka poprawek, zamiast pierwszego wydania nowej wersji minor.

Harmonogram wstecz od 15 stycznia 2027

Dla typowego klastra produkcyjnego z kilkoma terabajtami danych proponujemy taki rozkład. To szkic do dostosowania, a nie norma.

Okres	Zadanie
kwiecień 2026	Inwentaryzacja: wersje, indeksy z 7.x, integracje, wtyczki, biblioteki klienckie, połączenia TLS, użycie Enterprise Search
maj i czerwiec 2026	Aktualizacja do najnowszego 8.19.x, Upgrade Assistant, przeindeksowanie lub archiwizacja indeksów 7.x
lipiec i sierpień 2026	Klaster testowy z kopii migawki, przejście całej ścieżki, test alertów, dashboardów, zadań ML i zbierania danych
wrzesień 2026	Decyzja o wersji docelowej, plan okna serwisowego, plan wycofania
październik 2026	Aktualizacja środowisk nieprodukcyjnych, potem produkcji
listopad i grudzień 2026	Zapas na poprawki i zamrożenie zmian na okres świąteczny

Najdłużej zwykle trwa przeindeksowanie starych danych. Dokumentacja Elastic mówi, że indeksy z wersji 7.x trzeba przed aktualizacją do 9.x przeindeksować, usunąć lub zarchiwizować, a w 9.x archiwizacja pozwala czytać migawki 7.x bez przeindeksowania. Jeśli zakładasz archiwizację, zdecyduj to wcześnie, bo wpływa na plan retencji.

Pierwszy tydzień pracy

Na start nie potrzeba okna serwisowego. Wystarczy kilka godzin pracy administratora: spisać wersje wszystkich węzłów, Kibany, Fleet Servera i agentów, uruchomić Upgrade Assistant na bieżącej wersji, sprawdzić listę indeksów utworzonych przed wersją 8.0 oraz ustalić, kto w firmie korzysta z funkcji, które znikają lub zmieniają się w 9.x. Wynik tego przeglądu mówi, czy zmieścisz się w harmonogramie, czy trzeba go skrócić albo poprosić o wsparcie z zewnątrz.

Elastic Cloud i klaster na własnej infrastrukturze

Jeśli korzystasz z Elastic Cloud, aktualizację w odpowiedniej kolejności wykonuje platforma, ale Twoja część zostaje: indeksy z 7.x, integracje, szablony, biblioteki klienckie i reguły alertów. Na własnej infrastrukturze odpowiadasz też za kolejność składników, systemy operacyjne, wtyczki i repozytoria migawek. Dla klastrów na AWS dochodzi zmiana z 9.1: wtyczki repository-s3 i discovery-ec2 używają AWS SDK v2, więc trzeba ustawić region repozytoriów i używać IMDSv2.

Czego unikać

• Czekania na ostatni kwartał. Grudzień to okres zamrożeń, a poprawki w razie kłopotów będą potrzebne, gdy wszyscy są na urlopach.
• Przeskakiwania wersji pośredniej 8.19.
• Aktualizacji produkcji bez próby na kopii z migawki.
• Zostawiania klastra na 8.x „bo działa”. Działa do dnia, w którym trzeba będzie zainstalować poprawkę bezpieczeństwa, której nie ma.

Jak możemy pomóc

Zaczynamy od przeglądu klastra: wersje, wynik Upgrade Assistant, lista indeksów do przeindeksowania, integracje i biblioteki klienckie. Na tej podstawie dajemy harmonogram i wycenę. Aktualizacje wykonujemy w ramach wdrożeń i utrzymania Elastic.