Historia awarii Elastic Cloud

1. 23 października 2026 04:04 UTCinvestigating

   Obecnie badamy kwestię uniemożliwiającą dostęp do portalu wsparcia elastycznego. W tym czasie klienci mogą doświadczać problemów uwierzytelniających portal wsparcia.

2. 23 października 2026 04:59 UTCidentified

   Zidentyfikowaliśmy problem uniemożliwiający dostęp do portalu Elastycznego Wsparcia, spowodowanego przez dostawcę wyższego szczebla. Dostawca potwierdził rozwiązanie, które przywróciło dostęp dla niektórych z jego dotkniętych środowisk i jest obecnie toczenia go do reszty. W tym czasie klienci mogą doświadczać problemów uwierzytelniających portal wsparcia.

3. 23 października 2026 06:33 UTCresolved

   Dostawca z wyższego szczebla zakończył swoją naprawę, a dostęp do portalu Elastic Support został przywrócony. Klienci mogą ponownie uwierzytelnić portal wsparcia. Rozważamy rozwiązanie tej kwestii i nie będziemy dostarczać dalszych aktualizacji. Jeśli nadal masz problemy, skontaktuj się z nami.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 października 2026 11:19 UTCinvestigating

   Badamy problem dotykający AutoOps dla nowo utworzonych kont w regionie AWS - East-1. Konta utworzone po godzinie 00: 00 UTC w dniu 22 października 2026 r. mogą nie być w stanie uzyskać dostępu do AutoOps i mogą zobaczyć błąd (HTTP 403) podczas jego otwierania. Elastyczna chmura Hosted: AutoOps nie jest dostępny dla nowych kont. Elastyczna Cloud Serverless: AutoOps nie jest dostępny dla nowych kont. Istniejące instalacje i projekty oraz wszystkie inne funkcje Elastycznej Chmury nie są naruszone. Nasze zespoły inżynieryjne pracują nad zidentyfikowaniem przyczyny i przywróceniem dostępu. Dostarczymy kolejną aktualizację w ciągu 60 minut, lub wcześniej, jeśli nastąpi znacząca zmiana

2. 22 października 2026 12:00 UTCidentified

   Zidentyfikowaliśmy przyczynę problemu dotykającego AutoOps i wprowadzamy rozwiązanie. Elastic Cloud Hosted i Elastic Cloud Serverless: Klienci, którzy stworzyli nowe konto w regionie AWS us- east-1 od około 00: 30 UTC w dniu 22 października 2026 roku nie byli w stanie uzyskać dostępu do AutoOps i mogli widzieć błąd (HTTP 403) podczas jego otwierania. Naprawiamy problem i oczekujemy, że sytuacja zostanie w pełni rozwiązana do 13: 00 UTC. Istniejące instalacje i projekty oraz wszystkie inne funkcje Elastycznej Chmury nie są naruszone.

3. 22 października 2026 20:50 UTCresolved

   Rozwiązaliśmy problem dotyczący AutoOps o 12: 30 UTC. Elastic Cloud Hosted i Elastic Cloud Serverless: Klienci, którzy stworzyli nowe konto w regionie AWS us- east-1 od około 00: 30 UTC w dniu 22 października 2026 roku nie byli w stanie uzyskać dostępu do AutoOps i mogli widzieć błąd (HTTP 403) podczas jego otwierania.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 października 2026 20:07 UTCinvestigating

   Badamy kwestię wpływającą na zdolność do skalowania istniejących wdrożeń Elastycznych Cloud Hosted oraz bezusługowych projektów w Azure. Nowe projekty i wdrażanie w Azure mogą być opóźnione.

2. 20 października 2026 21:24 UTCidentified

   Zidentyfikowaliśmy problem mający wpływ na zdolność do skalowania istniejących już wdrożeń Elastycznych Cloud Hosted i bezusługowych projektów w Azure. Nowe projekty i wdrażanie w Azure mogą być opóźnione. Inżynierowie aktywnie pracują nad złagodzeniem problemu.

3. 20 października 2026 22:27 UTCmonitoring

   Inżynierowie zidentyfikowali i złagodzili problem wpływający na zdolność do skalowania istniejących elastycznych aplikacji w chmurze Hosted oraz bezusługowych projektów w Azure. Monitorujemy tę kwestię, aby zapewnić normalne prowadzenie operacji.

4. 21 października 2026 03:05 UTCresolved

   Inżynierowie złagodzili problem wpływający na zdolność do skalowania istniejących już wdrożeń Elastycznych Cloud Hosted i bezsercowych projektów w Azure. Skalowanie działa zgodnie z oczekiwaniami.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 października 2026 06:51 UTCinvestigating

   Badamy problem dotyczący jednej strefy dostępności w regionie GCP Europe- west2 (Londyn). Począwszy od około 06: 15 UTC, niektóre Elastyczne Cloud Hosted i bezusługowe rozmieszczenie z przepustowością w tej strefie może doświadczyć degradacji dostępności lub łączności. Można również opóźnić monitorowanie i wylogowanie w celu wdrożenia w regionie. Nie ma to wpływu na rozmieszczenie w innych strefach i regionach. Nasi inżynierowie aktywnie pracują nad tym zagadnieniem i jesteśmy w kontakcie z naszym dostawcą chmur.

2. 20 października 2026 07:56 UTCidentified

   Nasz dostawca chmur potwierdził incydent infrastrukturalny mający wpływ na jedną strefę dostępności (europe- west2- b) w regionie GCP europe- west2 (Londyn), powodując utratę połączeń sieciowych i niedostępność zasobów w tej strefie. Elastic Cloud Hosted wdrożeń i Elastic Bezserwisowe projekty z zasobami w strefie dotkniętej mogą być niedostępne lub doświadczenie pogorszone wydajność. Podjęliśmy kroki w celu uniknięcia umieszczania nowych projektów bez usług w strefie dotkniętej kryzysem i pracujemy nad przywróceniem usług, które od nich zależą. Zmniejszone zdolności produkcyjne w regionie mogą opóźniać skalowanie i tworzenie nowych zasobów. Nie mamy jeszcze szacowanego czasu na wyzdrowienie z naszego dostawcy chmur. Współpracujemy z nimi ściśle i w ciągu godziny dostarczymy kolejne aktualizacje.

3. 20 października 2026 09:15 UTCidentified

   Incydent infrastrukturalny w naszym dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) jest w toku. Elastyczna chmura Hosted: Większość wdrożeń z zasobami w strefie dotkniętej pozostaje niedostępna lub zdegradowana. Widzimy wczesne, ograniczone oznaki powrotu do zdrowia, a niewielka liczba początkowo dotkniętych wdrożeń wraca do zdrowia. Kontynuujemy nasze działania w zakresie łagodzenia zmiany klimatu i będziemy się dzielić w miarę postępów w zakresie odbudowy. Elastyczne serverless: Podjęliśmy działania mające na celu uniknięcie umieszczania nowych projektów w strefie dotkniętej kryzysem, a obecnie dostosowujemy istniejące projekty do innych stref dostępności. Widzimy oznaki ożywienia - niektóre projekty pozostają w międzyczasie niedostępne lub zdegradowane. Zmniejszone zdolności produkcyjne w regionie mogą opóźniać skalowanie i tworzenie nowych zasobów. Nie mamy jeszcze szacowanego czasu na pełne odzyskanie od naszego operatora chmur. Współpracujemy z nimi i dostarczymy kolejną aktualizację do 10: 15 UTC.

4. 20 października 2026 10:32 UTCidentified

   Incydent infrastrukturalny w naszym dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) jest w toku. Elastic Cloud Hosted wdrożeń i Elastic Bezserwisowe projekty z zasobami w strefie dotkniętej mogą pozostać niedostępne lub zdegradowane. Nasze zespoły kontynuują prace nad łagodzeniem skutków i odbudową, a my ściśle współpracujemy z naszym dostawcą chmur. Nie mamy jeszcze szacowanego czasu na pełne wyzdrowienie. Dostarczymy kolejną aktualizację do 12: 00 UTC, lub wcześniej, jeśli nastąpi znacząca zmiana.

5. 20 października 2026 12:24 UTCidentified

   Incydent infrastrukturalny w naszym dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) jest w toku. Widzimy niewielkie oznaki ożywienia zarówno od naszego dostawcy chmur, jak i od naszych własnych działań łagodzących. Elastyczna chmura Hosted: Niektóre z dotkniętych wdrożeń wracają do zdrowia. Klienci, których plany zmian lub innych operacji nie powiodły się podczas incydentu, powinni ponownie spróbować z konsoli Elastic Cloud. Operacje, które zależą od strefy dotkniętej chorobą, mogą trwać dłużej niż zwykle lub ponownie się nie powieść, aż do dalszego powrotu do zdrowia. Niektóre rozmieszczenia mogą pozostać niedostępne lub zdegradowane. Elastic Serverless: Niektóre projekty mogą pozostać niedostępne lub zdegradowane.

6. 20 października 2026 14:15 UTCidentified

   Incydent infrastrukturalny w naszym dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) wraca do normy. Nasz dostawca usług w chmurze informuje o odzyskaniu usług dla większości miejsc pracy w regionie, a my widzimy postęp po naszej stronie, gdy dotknięta strefa wraca. Elastyczna chmura Hosted: Coraz większa liczba dotkniętych wdrożeń wracają do zdrowia. Klienci, których plany zmian lub innych operacji nie powiodły się podczas incydentu, powinni ponownie spróbować z konsoli Elastic Cloud. Niektóre z wdrożeń mogą być nadal niedostępne lub zdegradowane, a niektóre mogą wymagać dodatkowych kroków naprawczych, które nasz zespół wsparcia przeprowadzi w poszczególnych przypadkach. Jeśli twój program jest nadal niezdrowy, skontaktuj się ze wsparciem. Operacje mogą trwać dłużej niż zwykle, gdy zdolności przewozowe są przywrócone.

7. 20 października 2026 17:27 UTCidentified

   Incydent infrastrukturalny u naszego dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) został rozwiązany. Nadal pracujemy nad pełnym odzyskaniem naszych usług. Elastyczna chmura Hosted: Coraz większa liczba dotkniętych wdrożeń wracają do zdrowia. Klienci, których plany zmian lub innych operacji nie powiodły się podczas incydentu, powinni ponownie spróbować z konsoli Elastic Cloud. Niektóre z wdrożeń mogą być nadal niedostępne lub zdegradowane, a niektóre mogą wymagać dodatkowych kroków naprawczych, które nasz zespół wsparcia przeprowadzi w poszczególnych przypadkach. Jeśli twój program jest nadal niezdrowy, skontaktuj się ze wsparciem. Operacje mogą trwać dłużej niż zwykle, gdy zdolności przewozowe są przywrócone.

8. 20 października 2026 21:54 UTCresolved

   Incydent infrastrukturalny u naszego dostawcy chmur wpływający na strefę dostępności Europe- west2- b w regionie GCP Europe- west2 (Londyn) został rozwiązany. Inżynieria zakończyła odzyskiwanie infrastruktury w strefie dostępności dotkniętej. Elastic Cloud Hosted: Klienci, których plan się zmienił lub inne operacje nie powiodły się podczas incydentu, powinni ponownie spróbować z konsoli Elastic Cloud. Niektóre z wdrożeń mogą być nadal niedostępne lub zdegradowane i mogą wymagać dodatkowych kroków naprawczych, które nasz zespół wsparcia przeprowadzi w poszczególnych przypadkach. Jeśli twój program jest nadal niezdrowy, skontaktuj się ze wsparciem.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 października 2026 16:42 UTCinvestigating

   Badamy problem dotykający niektórych elastycznych projektów Cloud Serverless w regionie GCP us- central1. Klienci mogą doświadczyć opóźnionej lub niedostępnej operacji projektu.

2. 8 października 2026 17:21 UTCidentified

   Zidentyfikowaliśmy problem z pamięci masowej w chmurze dotykającą niektórych elastycznych projektów Cloud Serverless w regionie GCP us- central1. Klienci mogą doświadczać opóźnionych lub niedostępnych operacji projektowych. Dostawca bada sprawę, a my monitorujemy regenerację. Dostarczymy kolejną aktualizację, gdy więcej informacji będzie dostępnych.

3. 8 października 2026 19:17 UTCidentified

   Niektóre elastyczne projekty Cloud Serverless w regionie GCP us- central1 mogą nadal doświadczać opóźnionych lub niedostępnych operacji projektu. Dostawca nadal bada tę kwestię. Monitorujemy sytuację i dostarczymy kolejną aktualizację, gdy będzie dostępna więcej informacji.

4. 8 października 2026 20:47 UTCmonitoring

   Zaobserwowaliśmy poprawę po tym, jak nasz dostawca pamięci masowej w chmurze wyższego szczebla zastosował ograniczenia. Niektóre elastyczne projekty Cloud Serverless w regionie GCP us- central1 mogą nadal doświadczać opóźnionych lub niedostępnych operacji projektowych, podczas gdy odzysk jest kontynuowany. Monitorujemy sytuację i dostarczymy kolejną aktualizację, gdy będzie dostępna więcej informacji.

5. 9 października 2026 00:54 UTCresolved

   Rozwiązano problem pamięci masowej w chmurze na wcześniejszych etapach, dotykający niektórych elastycznych projektów typu Cloud Serverless w regionie GCP us- central1. Operacje projektowe wróciły do normy i nie widzimy już dotkniętych projektów w stanie czerwonym.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 14:04 UTCinvestigating

   Klienci z bezusługowymi projektami w regionie Azure ZEA North mogą zobaczyć opóźnienia w zakresie pomiarów wyświetlanych w Cloud UI. Zespół bada sprawę i opublikujemy aktualizację w ciągu 2 godzin lub wcześniej, jeśli to konieczne

2. 6 października 2026 17:54 UTCresolved

   Problem dotyczący dostępności metrycznej projektów bezusługowych w Azure ZEA North został rozwiązany. Opóźnione pomiary "użycia i wydajności" są już odzyskiwane, a w kolejce są przetwarzane zapisy użytkowania. Nie oczekuje się utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 września 2026 14:04 UTCinvestigating

   Obecnie mamy opóźnienia w dostarczaniu nowych zasobów w chmurze ze względu na powolność z zewnętrznym dostawcą obrazu kontenera. Może to prowadzić do opóźnień przy tworzeniu nowych wdrożeń, skalowaniu istniejących lub przenoszeniu przypadków, których dotyczy utrzymanie infrastruktury. Jako środek łagodzący, możesz spróbować ponownie uruchomić nieudany plan zmiany. Istniejące rozmieszczenie nie ma wpływu. Nasz zespół aktywnie monitoruje sytuację i pracuje nad złagodzeniem problemu. Za 12 godzin dostarczymy nowe informacje.

2. 23 września 2026 16:03 UTCresolved

   Kwestia ta została rozwiązana.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 września 2026 15:50 UTCinvestigating

   Badamy raporty brakujących wskaźników poziomu węzłów (CPU, pamięć, dysk, pule gwintów) dla ostatnich przedziałów czasowych w podzbiorze regionów AutoOps. Może to być wiadomość "Brak danych" w widoku węzłów. Dane dotyczące zdrowia klastrów, odłamków i rozmieszczenia nie ulegają zmianie i nie doszło do utraty danych. Dostarczymy aktualizację w ciągu najbliższych 2 godzin lub wcześniej.

2. 17 września 2026 16:13 UTCidentified

   Zidentyfikowaliśmy przyczynę brakujących wskaźników poziomu węzłów (CPU, pamięć, dysk, pule nici) w dotkniętych regionach. Dane dotyczące zdrowia klastrów, odłamków i rozmieszczenia nigdy nie zostały naruszone i nie doszło do utraty danych. Ustawienie zostało zatwierdzone w jednym regionie i jest obecnie przenoszone do pozostałych dotkniętych regionów. Dostarczymy kolejną aktualizację po zakończeniu.

3. 17 września 2026 16:31 UTCresolved

   Kwestia powodująca brak wskaźników poziomu węzłów (CPU, pamięć, dysk, pule gwintów) dla ostatnich przedziałów czasowych w podzbiorze regionów AutoOps została w pełni rozwiązana. Dane dotyczące zdrowia klastrów, odłamków i rozmieszczenia nie zostały naruszone przez cały okres, a dane nie zostały utracone.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 września 2026 13:17 UTCinvestigating

   Jesteśmy obecnie świadomi, że niektórzy klienci mogą nie być w stanie uzyskać dostępu do Elastycznego Portalu Wsparcia. Pracujemy z naszym dostawcą, aby zbadać sprawę. W razie potrzeby skontaktuj się ze wsparciem @ elastic.co.

2. 16 września 2026 14:49 UTCmonitoring

   Widzimy oznaki ożywienia na Elastycznym Portalu Wsparcia, a klienci powinni mieć teraz dostęp jak zwykle. Będziemy kontynuować monitorowanie przez 30 minut, zanim ten incydent zostanie rozwiązany.

3. 16 września 2026 15:38 UTCresolved

   Elastyczny Portal Wsparcia pozostaje dostępny i stabilny - w tym czasie rozważamy rozwiązanie tego incydentu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 12 września 2026 23:21 UTCinvestigating

   Badamy opóźnienia pomiaru w konsoli.

2. 13 września 2026 00:18 UTCidentified

   Zidentyfikowaliśmy i ustaliliśmy przyczynę opóźnienia pomiaru. Kolejka jest w trakcie przetwarzania i opóźnione pomiary będą widoczne po zakończeniu.

3. 13 września 2026 02:55 UTCmonitoring

   Kolejki metryczne są przetwarzane, a opóźnione dane znów się pokazują. Będziemy monitorować, czy wszystko idzie zgodnie z oczekiwaniami.

4. 13 września 2026 07:45 UTCresolved

   Opóźnienie pomiaru spożycia w systemie GCP - east4 zostało w pełni rozwiązane. Wszystkie dane w kolejce zostały przetworzone, a metryka wyświetlana jest w konsoli w czasie rzeczywistym.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 września 2026 01:30 UTCidentified

   Zidentyfikowaliśmy i są w trakcie procesu naprawiania + łagodzenie błąd w naszym zarządzaniu uprawnieniami UI, który jest zapobieganie użytkownikom z funkcji właściciela organizacji i Cloud Console, Elasticsearch i Kibana dostępu do Kibana w Hosted Deloyments.

2. 10 września 2026 06:03 UTCidentified

   Aktualizacja: Ten incydent nadal trwa, a my kontynuujemy śledztwo.

3. 10 września 2026 09:51 UTCmonitoring

   Aktualizacja: Ustawienie zostało wprowadzone do produkcji i zastosowaliśmy korektę danych na kontach dotkniętych, przywracając Kibana dostęp dla użytkowników dotkniętych. Monitorujemy, by potwierdzić pełną rezolucję.

4. 10 września 2026 22:31 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 9 września 2026 20:44 UTCidentified

   Zidentyfikowaliśmy błąd w Fleet Server 9.5.3 (również obecny w 9.4.6), który może spowodować, że Elastic Agents się zapętli i offline, gdy Fleet naciska na aktualizację konfiguracji, w tym zapisanie, zmiany polityki, lub rutynowe zmiany. Dotyczy to tylko polityki, które wykorzystują zdalną funkcję wyjścia Fleet Elasticsearch. Zalecenie: Jeśli używasz zdalnego wyjścia Fleet Elasticsearch, nie uaktualniaj do 9.5.3 lub 9.4.6 dopóki nie będzie dostępna wersja stała. Jeśli jesteś już na dotkniętej wersji i doświadczając agenta check- w niepowodzeniach, skontaktuj się Wsparcie dla kroków naprawczych. Zwiastowanie zostało połączone i zostanie wysłane w kolejnych 9.5.x i 9.4.x uwolnień. Znana dokumentacja wydania: fleet- server # 7791, elastic- agent # 16542.

2. 11 września 2026 14:25 UTCidentified

   Poprawiliśmy wersje Flota Server 9.5.3 i 9.4.6 z poprawionymi wersjami wprowadzonymi od 10 września 2026 o 21: 20 UTC. - Aktualizacja do aktualnych wersji 9.4.6 lub 9.5.3 nie będzie miała wpływu na ten błąd, ponieważ zaktualizowana wersja zawiera fix. - W przypadku aktualizacji do 9.4.6 lub 9.5.3 przed 21: 20 UTC w dniu 10 września 2026 r. należy zastosować następujące środki łagodzące: 1. Wymuś ponowne uruchomienie komponentu Serwera Integracji, który wpłynął na wdrożenie 2. Uruchom procedury czyszczenia na dotkniętych agentów elastycznych (patrz https: / / support.elastic.co / knowledge / bee1c75c) - wymagane, jeśli agenci nie zameldowali się lub pozostawali offline po ponownym uruchomieniu serwera integracyjnego

3. 11 września 2026 16:00 UTCidentified

   Poprawiliśmy wersje Flota Server 9.5.3 i 9.4.6 z poprawionymi wersjami wprowadzonymi od 10 września 2026 o 21: 20 UTC. - Aktualizacja do aktualnych wersji 9.4.6 lub 9.5.3 nie będzie miała wpływu na ten błąd, ponieważ zaktualizowana wersja zawiera fix. - W przypadku aktualizacji do 9.4.6 lub 9.5.3 przed 21: 20 UTC w dniu 10 września 2026 r. należy zastosować następujące środki łagodzące: 1. Wymuś ponowne uruchomienie komponentu Serwera Integracji, który wpłynął na wdrożenie 2. Uruchom procedury czyszczenia na dotkniętych agentów elastycznych (patrz https: / / support.elastic.co / knowledge / bee1c75c) - wymagane, jeśli agenci nie zameldowali się lub pozostawali offline po ponownym uruchomieniu serwera integracyjnego WAŻNE: Poprawiony serwer Floty nie jest dostępny poza Elastic Cloud Enterprise (ECE) Stack Packs i Elastic Cloud Hosted (ECH).

4. 17 września 2026 10:30 UTCresolved

   Potwierdziliśmy, że agenci Elastyczni nie doświadczają już niepowodzeń związanych z tą kwestią. Od 10 września 2026 r. w pakietach Elastic Cloud Hosted i Elastic Cloud Enterprise dostępne są poprawione wersje Flota Server (9.5.4 / 9.4.6). Jeżeli przed upływem tego czasu nie zastosowałeś jeszcze środków łagodzących, dostępne są wytyczne: https: / / support.elastic.co / knowledge / bee1c75c.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 września 2026 00:04 UTCresolved

   Od 21: 50 do 23: 42 UTC, napotkaliśmy podwyższony poziom błędów dla antropicznego Claude 'a Haiku 4.5, OpenAI GPT- 5.6 i Google Gemini 2.5 Błysk z usługi elastycznego wnioskowania w regionach UE. Kwestia ta została już rozwiązana.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 15:18 UTCinvestigating

   Obecnie badamy problem wpływający na usługi uruchomione w GCP us- central1. Dostarczymy dodatkowe aktualizacje, jak dowiemy się więcej na temat zakresu oddziaływania.

2. 1 września 2026 15:51 UTCidentified

   Trwającym problemem jest wpływ usług działających w GCP us- central1. Obejmuje to, ale nie ogranicza się do Elastycznych Cloud Hosted i Bezusługowych projektów w regionie i naszej Docker Registry Service. Kontynuujemy monitorowanie sytuacji i dostarczymy aktualizacje, gdy będą dostępne.

3. 1 września 2026 16:15 UTCidentified

   Trwały problem CSP jest wpływ usług działających w GCP us- central1. Obejmuje to, ale nie ogranicza się do Elastycznych Cloud Hosted i Bezusługowych projektów w regionie i naszej Docker Registry Service. Kontynuujemy monitorowanie sytuacji i dostarczymy aktualizacje, gdy będą dostępne.

4. 1 września 2026 16:22 UTCmonitoring

   Widzimy oznaki odzysku usług w GCP us- central1, na które wpływ ma kwestia CSP. Kontynuujemy monitorowanie sytuacji i będziemy dostarczać aktualizacje w miarę ich dostępności.

5. 1 września 2026 20:05 UTCresolved

   Kwestia ta została rozwiązana.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 08:16 UTCinvestigating

   Zdajemy sobie sprawę z błędu dotykającego klientów w wersjach Elasticsearch 9.5.0, 9.5.1 i 9.5.2, gdzie operacje indeksu luzem przetwarzane na podstawowym odłamku mogą prowadzić do rozbieżności na repliki, co prowadzi do wysokiego wykorzystania dysku i długotrwałego odzyskiwania. Zespół pracuje nad naprawą. Więcej informacji można znaleźć na stronie https: / / www.elastic.co / docs / release- notes / elasticsearch / known-issues # elasticsearch- 9.5.2- known-issues Następna aktualizacja nastąpi za 2 godziny lub wcześniej, jeśli zajdzie taka potrzeba.

2. 1 września 2026 11:07 UTCidentified

   Zidentyfikowaliśmy przyczynę i zespół pracuje nad ustaleniem, które ma zostać wydane w wersji Elasticsearch 9.5.3 Co możesz zrobić: - Jeśli nie zostały jeszcze zmodernizowane do 9.5. *, nie są dotknięte, ponieważ uaktualnienia do 9.5 zostały wyłączone aż do 9.5.3 jest zwolniony - Jeśli jesteś już uruchomiony 9.5 i doświadczyć objawów tego problemu, prosimy o kontakt Elastic Support. Więcej informacji można znaleźć na stronie https: / / www.elastic.co / docs / release- notes / elasticsearch / known-issues # elasticsearch- 9.5.2- known-issues

3. 1 września 2026 15:46 UTCidentified

   Fix został zidentyfikowany i przeniesiony do oddziału Elasticsearch 9.5 patch. Zespoły wykonują wymagane zatwierdzenia przed planowaniem i rozpoczęciem wydania 9.5.3.

4. 3 września 2026 12:13 UTCmonitoring

   Elasticsearch 9.5.3 został wydany i wszystkich klientów obecnie działa 9.5.0, 9.5.1 lub 9.5.2 zaleca się, aby zaktualizować do tej nowej wersji jak najszybciej.

5. 3 września 2026 15:47 UTCmonitoring

   Elasticsearch 9.5.3 został wydany i wszystkich klientów obecnie działa 9.5.0, 9.5.1 lub 9.5.2 zaleca się, aby zaktualizować do tej nowej wersji jak najszybciej. Po aktualizacji zaleca się klientom, którzy wywierają wpływ, aby wykonali czynności związane z przebiegiem prac z https: / / github.com / elasticsearch / issues / 158212.

6. 30 września 2026 20:44 UTCresolved

   Problem ten został rozwiązany w 9.5.3 wydania Elasticsearch. Klienci uruchamiający wersje 9.5.0, 9.5.1 lub 9.5.2 Elasticsearch powinni jak najszybciej zaktualizować do nowszej wersji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 sierpnia 2026 17:11 UTCmonitoring

   26 sierpnia, około 00: 00 UTC wprowadziliśmy zmianę w zarządzanych wejściach, która wpłynęła na niektóre zasady w naszym wewnętrznym dostawcy DNS, usuwając .apm punktów końcowych niektórych naszych klientów bez usług. Usługa została przywrócona około 9 rano UTC tego samego dnia. W tym czasie niektórzy klienci doświadczyli niedostępności punktu końcowego .apm przez okres 9 godzin. Wprowadzamy pewne kontrole i alarmy, aby to się nie powtórzyło.

2. 27 sierpnia 2026 18:33 UTCresolved

   To już rozwiązane

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 sierpnia 2026 20:22 UTCinvestigating

   Obecnie badamy podwyższone poziomy błędów wpływające na zarządzany OTLP na Elastycznej Cloud Serverless. Nasz zespół aktywnie bada przyczynę. Dostarczymy aktualizację w ciągu 30 minut.

2. 20 sierpnia 2026 20:53 UTCinvestigating

   Kontynuujemy badanie podwyższonych wskaźników błędów mających wpływ na zarządzany OTLP na Elastycznej Cloud Serverless. Dostarczymy aktualizację w ciągu 1 godziny.

3. 20 sierpnia 2026 21:59 UTCidentified

   Zidentyfikowaliśmy główną przyczynę podwyższonych wskaźników błędów mających wpływ na zarządzany bez usług OTLP. Zastosowano środki łagodzące i monitorujemy, aby potwierdzić powrót błędów do poziomu odniesienia. Opierając się na naszym dochodzeniu, nie wpłynęło to na pracę klientów.

4. 20 sierpnia 2026 22:13 UTCresolved

   Ten incydent został rozwiązany. Przyczyna została zidentyfikowana i rozwiązana. Podczas tego incydentu nie wpłynęły na to obciążenia pracą klienta.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 sierpnia 2026 12:48 UTCinvestigating

   Zidentyfikowano problem mający wpływ na tworzenie nowych bezusługowych projektów w regionie Azure na wschodzie. Nasz zespół prowadzi śledztwo, by ustalić przyczynę. Dostarczymy aktualizację statusu w ciągu następnej godziny lub zaraz po ustaleniu przyczyny, w zależności od tego, co nastąpi wcześniej.

2. 20 sierpnia 2026 14:05 UTCmonitoring

   Ustaliliśmy, że problem ten wynika z problemu ze składnikiem Azure. Po zbadaniu, wpływ jest ściśle ograniczony do nowych czasów inicjalizacji projektu, co powoduje dłuższe czasy tworzenia projektów bez usług w regionie Azure Eastus. Po rozwiązaniu tej kwestii przedstawimy kolejną aktualizację.

3. 20 sierpnia 2026 16:22 UTCresolved

   Zagadnienia dotyczące elementów magazynowych Azure w regionie wschodnim zostały rozwiązane. W związku z tym czas tworzenia projektów bez usług powrócił do normy i funkcjonuje zgodnie z oczekiwaniami.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 14 sierpnia 2026 09:22 UTCidentified

   Elasticsearch 9.5.1 zawiera znane zagadnienie, w którym bolońskie zapytania zawierające moszcz, filtrowanie lub powinny zawierać klauzulę przy użyciu wielowartościowych terminów zapytania, obok klauzuli must _ not o polach z wyłączonym indeksowaniem, mogą nadal zwracać fałszywe dodatnie dopasowania. Podczas gdy patch w pkt 9.5.1 (https: / / github.com / elasticsearch / pull / 155936) rozwiązał usterkę bulk- scorer dla terminologii i zakresów ścieżki zapytania; wielowartościowe zapytania wykorzystują inny typ zapytania Lucene, który nie był objęty tym ustawieniem. Strumienie danych z serii Time (TSDB) oraz indeksy kolumnowe / strumienie danych nadal mają wpływ na ten wzorzec zapytania, ponieważ indeksowanie jest domyślnie wyłączone na tych polach. Określenia te mogą odpowiadać fałszywie dodatnim dopasowaniom (w tym dokumentom, które powinny zostać wyłączone) i zgłaszać liczbę dokumentów wyższą niż oczekiwano. Żaden błąd nie jest podniesiony, więc pytania wydają się zakończyć pomyślnie. Co możesz zrobić: - Jeśli nie zostały jeszcze zaktualizowane do 9.5. *, zalecamy odroczenie aktualizacji aż do wersji 9.5.2 jest dostępna. - Jeśli jesteś już uruchomiony 9.5. *, skontaktuj się z Elastic Support, jeśli potrzebujesz pomocy w ustaleniu, czy Twoje wyszukiwanie jest naruszone. Zidentyfikowaliśmy przyczynę, jest w toku, i przygotowujemy zwolnienie łaty. Dostarczymy kolejną aktualizację, gdy naprawimy.

2. 20 sierpnia 2026 17:09 UTCresolved

   Elasticsearch 9.5.2 został wydany i zawiera rozwiązanie tego problemu. Klienci pracujący na 9.5.0 lub 9.5.1 powinni podnieść do 9.5.2. W tym momencie rozważamy rozwiązanie tej kwestii i nie będziemy dostarczać dalszych aktualizacji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 sierpnia 2026 08:32 UTCinvestigating

   Widzimy podwyższony poziom błędów ze strony dostawcy wyższego szczebla dla modelu mikrosoft- multilingual - e5- duze osadzanie. Wyszukiwarka załączania żądań do tego modelu może się nie udać. Prowadzimy śledztwo

2. 13 sierpnia 2026 14:45 UTCinvestigating

   Obserwujemy poprawę dostępności, ale nadal monitorujemy sytuację. W odpowiednim czasie przejdziemy do dalszych informacji.

3. 13 sierpnia 2026 18:26 UTCmonitoring

   Niestety, nie możemy już dłużej wspierać modelu E5 Multilingual Large na Elastic Inference Service ze względu na ciągłe problemy z dostawcami wyższego szczebla. Każdy klient wymagający tego modelu powinien skonfigurować niestandardowe punkty końcowe przy użyciu własnych kluczy API.

4. 17 sierpnia 2026 11:40 UTCresolved

   Model microsoft- multilingual - e5- duze został wycofany z usługi Elastic Inference Service. Wnioski do tego modelu teraz zwrócić błąd. Klienci, którzy chcą korzystać z tego modelu z elastyczną chmurą, muszą stworzyć niestandardowy punkt końcowy, używając własnego klucza API. Więcej informacji na ten temat znajduje się w naszej dokumentacji wniosku: https: / / www.elastic.co / docs / api / doc / elasticsearch / group / endpoint- inference

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.