Aktualizacja Elastic z 8.x do 9.x: kolejność i pułapki

Elastic 9.0 jest dostępny od 15 kwietnia 2025 roku, a od 29 lipca mamy także 9.1 i 8.19, czyli ostatnią wersję z linii 8.x. Wiele firm nadal pracuje na 8.x i słusznie nie spieszy się z aktualizacją, ale sama zmiana głównej wersji ma kilka reguł, o których lepiej wiedzieć przed zaplanowaniem okna serwisowego. Poniżej opisujemy, jak ją przeprowadzamy w klastrach zarządzanych samodzielnie (self-managed), i na co zwracamy uwagę. Na Elastic Cloud Hosted i Enterprise platforma sama wykonuje aktualizację w odpowiedniej kolejności.

Ścieżka: najpierw 8.19

Zasada z dokumentacji Elastic jest prosta. Do 9.0.x wchodzi się z wersji 8.18.x, ponieważ 8.18 i 9.0 wydano jednocześnie. Do 9.1 i nowszych trzeba najpierw być na 8.19.x. W praktyce oznacza to, że niezależnie od celu najpierw aktualizujemy się do najnowszej łatki 8.19, a dopiero potem do 9.x. Warto to zrobić także wtedy, gdy już działa jakaś wersja 8.19, bo Upgrade Assistant (narzędzie opisane niżej) jest częścią tej wersji i poprawki w nim trafiają do kolejnych łatek.

Jest jeszcze jedna reguła, która zaskakuje przy łatkach: aktualizować można tylko do wersji wydanej po wersji bieżącej. Z 9.0.5 na 9.1.0 nie przejdziesz, bo 9.1.0 wyszła wcześniej niż 9.0.5. Trzeba poczekać na 9.1.1 lub nowszą.

Kolejność składników

Dokumentacja podaje następującą kolejność:

1. Elasticsearch,
2. Kibana (w tej samej wersji co Elasticsearch),
3. Fleet Server i Elastic APM, jeśli ich używasz,
4. Elastic Agent, Beats, Logstash i biblioteki klienckie.

Elasticsearch obsługuje aktualizację kroczącą, węzeł po węźle, więc klaster z replikami rozłożonymi na kilka węzłów pozostaje dostępny. Kibana wymaga przerwy: wszystkie jej instancje trzeba zatrzymać na czas aktualizacji. Do okna serwisowego warto też dopisać osobny klaster monitorujący (jeśli go masz), który aktualizujemy przed produkcyjnym, oraz klastry zdalne używane w wyszukiwaniu między klastrami, które dokumentacja każe aktualizować w pierwszej kolejności.

Elastic Agent, Beats i Logstash w wersji 8.19 działają ze wszystkimi wersjami 9.x Elasticsearch. Biblioteki klienckie 8.x domyślnie używają trybu zgodności REST API. Dzięki temu nie trzeba przełączać wszystkich agentów w jednym oknie, a w kolejnych etapach można je aktualizować w tempie wygodnym dla zespołu.

Upgrade Assistant i indeksy z wersji 7.x

To najważniejszy krok przygotowawczy i jedyny, którego nie wolno pomijać. Upgrade Assistant to strona w Kibanie, która zbiera ostrzeżenia o przestarzałych ustawieniach z trzech źródeł: API informacji o deprecjacjach Elasticsearch, jego logów deprecjacji i API deprecjacji Kibany. Uruchamiamy go na najnowszej łatce 8.19.

Dla wielu klastrów decyduje jedna kwestia. Indeksy utworzone w wersji 7.x lub wcześniejszej nie są kompatybilne z 9.x. Przed aktualizacją trzeba je przeindeksować, usunąć albo zarchiwizować (oznaczyć jako tylko do odczytu), a węzły Elasticsearch nie wystartują, jeśli takie indeksy zostaną. Upgrade Assistant potrafi przeindeksować lub oznaczyć jako archiwalne stare indeksy. Ostrzeżenie dotyczy też aplikacji: po przeindeksowaniu mogą zmienić się nazwy indeksów, więc trzeba sprawdzić alerty, transformacje i kod, który się do nich odwołuje. W wersji 9.x można też korzystać z funkcji archiwizacji, która udostępnia migawki (snapshots) indeksów 7.x do odczytu bez przeindeksowania.

Zmiany z listy breaking changes, które widzimy najczęściej

Przed aktualizacją przejrzyj w całości listę zmian niezgodnych wstecz dla Elasticsearch 9.0 i Kibany. Z listy wybraliśmy punkty, które mogą zaskoczyć w typowym środowisku firmowym:

• Protokoły TLS: z domyślnych ustawień usunięto TLSv1.1, a przy JDK 24 zestawy szyfrów TLS_RSA nie są już obsługiwane. Starsze systemy, które łączą się z klastrem (stare skrypty, urządzenia, aplikacje klienckie), mogą przestać się połączyć, więc sprawdź, jakich protokołów używają.
• Uwierzytelnianie LDAP i Active Directory: skonfigurowanie bind DN bez hasła w realmie LDAP lub AD powoduje, że węzeł nie wystartuje.
• Zamrożone indeksy: zniknęła możliwość odczytu indeksów zamrożonych (frozen) oraz punkt końcowy unfreeze. Przed aktualizacją sprawdź, czy któryś z Twoich indeksów jest zamrożony.
• Przekroczenia czasu: Elasticsearch zwraca teraz kod 429 zamiast 5xx przy części przekroczeń czasu, co ma znaczenie dla klientów, które inaczej obsługują te kody.
• Nazwy w logach deprecjacji: zmieniono nazwę słowa kluczowego i szablonu indeksu logów deprecjacji, więc reguły i dashboardy, które na nich bazują, wymagają poprawki.
• Uczenie maszynowe: na macOS x86_64 funkcje uczenia maszynowego są wyłączone. W środowiskach produkcyjnych to rzadkość, ale dotyczy laboratoriów i testów.

Przy aktualizacji do 9.1 dochodzi jedna zmiana dla chmury AWS: wtyczki repozytorium migawek repository-s3 i wykrywania discovery-ec2 przeszły na AWS SDK v2. Dokumentacja zaleca przetestowanie nowej wersji przed aktualizacją produkcji, bo SDK nie są w pełni zgodne.

LogsDB nie włączy się sam na starych strumieniach

W Elasticsearch 9.0 nowe strumienie danych logów, których nazwa pasuje do wzorca logs-*-*, dostają tryb indeksu LogsDB, dzięki któremu logi zajmują mniej miejsca (w testach Elastic nawet do 60 procent mniej, z niewielkim spadkiem wydajności zapisu; wynik zależy od danych). Po aktualizacji z 8.x istniejące strumienie, także te tworzone przez integracje, nie zostają automatycznie przełączone. Według dokumentacji nowe strumienie logs-*-* dostają LogsDB w klastrze zaktualizowanym z 8.x tylko wtedy, gdy w chwili aktualizacji nie było w nim istniejących strumieni o takich nazwach, więc po aktualizacji warto to sprawdzić. Włączenie to zmiana w szablonie indeksu (dla integracji w komponencie @custom). Oszczędność miejsca na logach to realna część zwrotu z aktualizacji, więc dopisujemy ten krok do planu.

Jak wygląda nasz plan

1. Inwentarz: wersje, indeksy z 7.x, integracje, wtyczki, biblioteki klienckie, połączenia TLS.
2. Migawka klastra. Po rozpoczęciu aktualizacji nie da się wrócić do poprzedniej wersji węzła, a odtworzenie jest możliwe wyłącznie z migawki wykonanej przed.
3. Aktualizacja do najnowszej łatki 8.19, Upgrade Assistant, usunięcie krytycznych problemów.
4. Próba na środowisku testowym, które odwzorowuje produkcję: szablony, ILM, alerty, dashboardy, uwierzytelnianie, wydajność.
5. Aktualizacja produkcji w kolejności z dokumentacji, a po niej kontrola alertów, zadań uczenia maszynowego i zbierania danych.
6. Dopiero potem zmiany opcjonalne, takie jak LogsDB na starych strumieniach czy nowości z 9.1.

Kiedy nie spieszyć się z aktualizacją

Jeśli klaster działa stabilnie na 8.19, wersja jest objęta wsparciem, a nie potrzebujesz nowości z 9.x, nie ma powodu aktualizować w pośpiechu. Rozsądnie jest ustalić termin i przygotować klaster (Upgrade Assistant, indeksy z 7.x), zamiast czekać na moment, w którym wersja zbliży się do końca wsparcia. Co zyskasz po aktualizacji, opisujemy w tekście o LOOKUP JOIN w ES|QL.

Aktualizacje i przeglądy klastrów wykonujemy w ramach wdrożeń i utrzymania Elastic.