История сбоев Elastic Cloud

1. 23 октября 2026 г. в 04:04 UTCinvestigating

   В настоящее время мы расследуем проблему, препятствующую доступу к порталу Elastic Support. В это время клиенты могут столкнуться с проблемами аутентификации на портале поддержки.

2. 23 октября 2026 г. в 04:59 UTCidentified

   Мы выявили проблему, препятствующую доступу к порталу Elastic Support, вызванную провайдером. Поставщик подтвердил исправление, которое восстановило доступ к некоторым из его пострадавших сред и теперь развертывает его для остальных. В это время клиенты могут столкнуться с проблемами аутентификации на портале поддержки.

3. 23 октября 2026 г. в 06:33 UTCresolved

   Поставщик upstream завершил исправление, и доступ к порталу Elastic Support был восстановлен. Клиенты могут повторно пройти аутентификацию на портале поддержки. Мы рассматриваем этот вопрос и не будем предоставлять никаких дальнейших обновлений. Если у вас продолжаются проблемы, пожалуйста, свяжитесь с нами.

Автоматический перевод официального обновления инцидента.

1. 22 октября 2026 г. в 11:19 UTCinvestigating

   Мы расследуем проблему, затрагивающую AutoOps для вновь созданных учетных записей в регионе AWS us-east-1. Учетные записи, созданные после 00:00 UTC 22 октября 2026 года, могут не иметь доступа к AutoOps и могут видеть ошибку (HTTP 403) при ее открытии. Elastic Cloud Hosted: AutoOps недоступен для новых учетных записей. Elastic Cloud Serverless: AutoOps недоступен для новых учетных записей. Существующие развертывания и проекты, а также все другие функции Elastic Cloud не затронуты. Наши инженерные команды работают над выявлением причины и восстановлением доступа. Мы предоставим следующее обновление в течение 60 минут или раньше, если произойдет значительное изменение

2. 22 октября 2026 г. в 12:00 UTCidentified

   Мы определили причину проблемы, затрагивающей AutoOps, и внедряем исправление. Клиенты, которые создали новую учетную запись в регионе AWS us-east-1 примерно с 00:30 UTC 22 октября 2026 года, не смогли получить доступ к AutoOps и, возможно, видели ошибку (HTTP 403) при ее открытии. Сейчас идет исправление, и мы ожидаем, что ситуация будет полностью решена к 13:00 UTC. Существующие развертывания и проекты, а также все другие функции Elastic Cloud не затронуты.

3. 22 октября 2026 г. в 20:50 UTCresolved

   Мы решили проблему, касающуюся AutoOps, в 12:30 UTC. Клиенты, которые создали новую учетную запись в регионе AWS us-east-1 примерно с 00:30 UTC 22 октября 2026 года, не смогли получить доступ к AutoOps и, возможно, видели ошибку (HTTP 403) при ее открытии.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 20:07 UTCinvestigating

   Мы изучаем вопрос, влияющий на возможность масштабирования существующих развертываний Elastic Cloud Hosted и проектов без серверов в Azure. Создание новых проектов и развертывание в Azure может быть отложено.

2. 20 октября 2026 г. в 21:24 UTCidentified

   Мы выявили проблему, которая влияет на возможность масштабирования существующих развертываний Elastic Cloud Hosted и проектов без серверов в Azure. Создание новых проектов и развертывание в Azure может быть отложено. Инженеры активно работают над смягчением проблемы.

3. 20 октября 2026 г. в 22:27 UTCmonitoring

   Инженеры выявили и смягчили проблему, затрагивающую возможность масштабирования существующих развертываний Elastic Cloud Hosted и проектов без серверов в Azure. Мы следим за этим вопросом, чтобы обеспечить нормальное функционирование.

4. 21 октября 2026 г. в 03:05 UTCresolved

   Инженеры смягчили проблему, связанную с возможностью масштабирования существующих развертываний Elastic Cloud Hosted и проектов без серверов в Azure. Масштабирование работает, как и ожидалось.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 06:51 UTCinvestigating

   Мы расследуем вопрос, затрагивающий одну зону доступности в регионе GCP Europe-west2 (Лондон). Начиная примерно с 06:15 UTC, некоторые развертывания Elastic Cloud Hosted и Serverless с пропускной способностью в этой зоне могут испытывать ухудшение доступности или подключения. Мониторинг и регистрация развертываний в регионе также могут быть отложены. Развертывания в других зонах и регионах не затрагиваются. Наши инженеры активно работают над этим вопросом, и мы находимся в контакте с нашим облачным провайдером.

2. 20 октября 2026 г. в 07:56 UTCidentified

   Наш облачный провайдер подтвердил инцидент с инфраструктурой, затрагивающий единую зону доступности (europe-west2-b) в регионе GCP europe-west2 (Лондон), что приводит к потере сетевого подключения и недоступности ресурсов в этой зоне. Развертывание Elastic Cloud Hosted и проекты Elastic Serverless с ресурсами в затронутой зоне могут быть недоступны или испытывать ухудшение производительности. Мы предприняли шаги, чтобы избежать размещения новых проектов без серверов в зоне поражения, и мы работаем над восстановлением сервисов, которые от этого зависят. Сокращение потенциала в регионе может задержать масштабирование и создание новых ресурсов. У нас пока нет времени на восстановление от нашего облачного провайдера. Мы тесно сотрудничаем с ними и предоставим следующее обновление в течение часа.

3. 20 октября 2026 г. в 09:15 UTCidentified

   Инфраструктурный инцидент в зоне доступности europe-west2-b в регионе GCP europe-west2 (Лондон) продолжается. Elastic Cloud Hosted: Большинство развертываний с ресурсами в зоне поражения остаются недоступными или деградируют. Мы наблюдаем ранние, ограниченные признаки восстановления, и небольшое количество первоначально затронутых развертываний восстанавливается. Мы продолжаем нашу работу по смягчению последствий и будем делиться больше по мере восстановления. Elastic Serverless: Мы предприняли шаги, чтобы избежать размещения новых проектов в пострадавшей зоне, и теперь мы перебалансируем существующие проекты в другие зоны доступности. Мы видим признаки восстановления - некоторые проекты пока остаются недоступными или деградируют. Сокращение потенциала в регионе может задержать масштабирование и создание новых ресурсов. У нас пока нет времени для полного восстановления от нашего облачного провайдера. Мы тесно сотрудничаем с ними и предоставим следующее обновление к 10:15 утра UTC.

4. 20 октября 2026 г. в 10:32 UTCidentified

   Инфраструктурный инцидент в зоне доступности europe-west2-b в регионе GCP europe-west2 (Лондон) продолжается. Развертывание Elastic Cloud Hosted и проекты Elastic Serverless с ресурсами в зоне поражения могут оставаться недоступными или деградировать. Наши команды продолжают работать над смягчением последствий и восстановлением, и мы тесно сотрудничаем с нашим облачным провайдером. У нас пока нет времени на полное восстановление. Мы предоставим следующее обновление к 12:00 UTC, или раньше, если произойдет существенное изменение.

5. 20 октября 2026 г. в 12:24 UTCidentified

   Инфраструктурный инцидент в зоне доступности europe-west2-b в регионе GCP europe-west2 (Лондон) продолжается. Мы видим незначительные признаки восстановления, как от нашего облачного провайдера, так и от нашей собственной работы по смягчению последствий. Elastic Cloud Hosted: некоторые из затронутых развертываний восстанавливаются. Клиентам, чьи планы были изменены или другие операции не увенчались успехом во время инцидента, рекомендуется использовать консоль Elastic Cloud. Операции, которые зависят от пораженной зоны, могут занять больше времени, чем обычно, или снова выйти из строя, пока восстановление не прогрессирует дальше. Некоторые развертывания могут оставаться недоступными или деградировать. Elastic Serverless: некоторые проекты могут оставаться недоступными или деградировать.

6. 20 октября 2026 г. в 14:15 UTCidentified

   Инфраструктурный инцидент в нашем облачном провайдере, влияющий на зону доступности europe-west2-b в регионе GCP europe-west2 (Лондон), восстанавливается. Наш облачный провайдер сообщает о восстановлении услуг для большинства рабочих нагрузок в регионе, и мы видим прогресс на нашей стороне. Упругий облачный хостинг: все большее число затронутых развертываний восстанавливается. Клиентам, чьи планы были изменены или другие операции не увенчались успехом во время инцидента, рекомендуется использовать консоль Elastic Cloud. Некоторые развертывания все еще могут быть недоступны или ухудшены, а некоторые могут нуждаться в дополнительных шагах по восстановлению, которые наша команда поддержки будет выполнять в каждом конкретном случае. Если ваше развертывание все еще нездорово, обратитесь в службу поддержки. Операции могут занять больше времени, чем обычно, пока восстанавливается мощность.

7. 20 октября 2026 г. в 17:27 UTCidentified

   Инфраструктурный инцидент в нашем облачном провайдере, влияющий на зону доступности europe-west2-b в регионе GCP europe-west2 (Лондон), был устранен. Мы продолжаем работать над полным восстановлением наших услуг. Упругий облачный хостинг: все большее число затронутых развертываний восстанавливается. Клиентам, чьи планы были изменены или другие операции не увенчались успехом во время инцидента, рекомендуется использовать консоль Elastic Cloud. Некоторые развертывания все еще могут быть недоступны или ухудшены, а некоторые могут нуждаться в дополнительных шагах по восстановлению, которые наша команда поддержки будет выполнять в каждом конкретном случае. Если ваше развертывание все еще нездорово, обратитесь в службу поддержки. Операции могут занять больше времени, чем обычно, пока восстанавливается мощность.

8. 20 октября 2026 г. в 21:54 UTCresolved

   Инфраструктурный инцидент в нашем облачном провайдере, влияющий на зону доступности europe-west2-b в регионе GCP europe-west2 (Лондон), был устранен. Инженерные работы завершили восстановление инфраструктуры, работающей в зоне доступности. Клиентам, чьи планы или другие операции не увенчались успехом во время инцидента, рекомендуется повторно использовать их с консоли Elastic Cloud. Некоторые развертывания все еще могут быть недоступны или ухудшены, и могут потребоваться дополнительные шаги по восстановлению, которые наша команда поддержки будет выполнять в каждом конкретном случае. Если ваше развертывание все еще нездорово, обратитесь в службу поддержки.

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 16:42 UTCinvestigating

   Мы расследуем проблему, затрагивающую некоторые проекты Elastic Cloud Serverless в регионе GCP us-central1. Клиенты могут столкнуться с задержкой или недоступностью работы проекта.

2. 8 октября 2026 г. в 17:21 UTCidentified

   Мы выявили проблему с облачным хранилищем, затрагивающую некоторые проекты Elastic Cloud Serverless в регионе GCP us-central1. Клиенты могут испытывать задержки или недоступность проектных операций. Поставщик исследует проблему, и мы отслеживаем восстановление. Мы предоставим еще одно обновление, когда появится дополнительная информация.

3. 8 октября 2026 г. в 19:17 UTCidentified

   Некоторые проекты Elastic Cloud Serverless в регионе GCP us-central1 могут по-прежнему испытывать задержки или недоступность проектных операций. Провайдер продолжает расследование этого вопроса. Мы следим за ситуацией и предоставим еще одно обновление, когда будет доступна дополнительная информация.

4. 8 октября 2026 г. в 20:47 UTCmonitoring

   Мы наблюдали улучшения после того, как меры по смягчению последствий были применены нашим поставщиком облачных хранилищ. Некоторые проекты Elastic Cloud Serverless в регионе GCP us-central1 могут по-прежнему испытывать задержки или недоступность операций проекта, пока продолжается восстановление. Мы следим за ситуацией и предоставим еще одно обновление, когда будет доступна дополнительная информация.

5. 9 октября 2026 г. в 00:54 UTCresolved

   Проблема облачного хранения данных в верхнем потоке, затрагивающая некоторые проекты Elastic Cloud Serverless в регионе GCP us-central1, решена. Операции проекта вернулись в нормальное состояние, и мы больше не видим пострадавших проектов в красном состоянии здоровья.

Автоматический перевод официального обновления инцидента.

1. 6 октября 2026 г. в 14:04 UTCinvestigating

   Клиенты с проектами без серверов в регионе Azure UAE North могут столкнуться с задержками в показателях, отображаемых в облачном интерфейсе. Команда изучает проблему, и мы опубликуем обновление через 2 часа или раньше, если это необходимо

2. 6 октября 2026 г. в 17:54 UTCresolved

   Проблема, затрагивающая доступность метрик для проектов без серверов в Azure UAE North, решена. Отсроченные показатели «Использование и производительность» теперь восстанавливаются, а записи об использовании в очереди обрабатываются. Потеря данных не ожидается.

Автоматический перевод официального обновления инцидента.

1. 23 сентября 2026 г. в 14:04 UTCinvestigating

   В настоящее время мы испытываем задержки в предоставлении новых облачных ресурсов из-за замедления работы с внешним поставщиком изображений контейнеров. Это может привести к задержкам при создании новых развертываний, масштабировании существующих или перемещении объектов, затронутых обслуживанием инфраструктуры. В качестве смягчения вы можете попробовать повторно запустить неудачные изменения плана. Существующие развертывания не затронуты. Наша команда активно следит за ситуацией и работает над смягчением проблемы. Мы предоставим обновление в ближайшие 12 часов.

2. 23 сентября 2026 г. в 16:03 UTCresolved

   Этот вопрос решен.

Автоматический перевод официального обновления инцидента.

1. 17 сентября 2026 г. в 15:50 UTCinvestigating

   Мы изучаем сообщения о недостающих показателях уровня узлов (CPU, память, диск, пулы потоков) для последних временных диапазонов в подмножестве областей AutoOps. Это может выглядеть как сообщение «Нет данных» в представлении узлов. Данные о здоровье кластеров, осколках и развертывании не затронуты, и потери данных не произошло. Мы предоставим обновление в течение следующих 2 часов или ранее.

2. 17 сентября 2026 г. в 16:13 UTCidentified

   Мы определили причину недостающих показателей уровня узлов (CPU, память, диск, пулы потоков) в пострадавших регионах. Данные о здоровье кластеров, осколках и развертывании никогда не были затронуты, и потери данных не произошло. В одном регионе было утверждено исправление, которое в настоящее время внедряется в остальные пострадавшие регионы. Мы предоставим дополнительное обновление после завершения развертывания.

3. 17 сентября 2026 г. в 16:31 UTCresolved

   Проблема, вызывающая недостающие метрики уровня узлов (CPU, память, диск, пулы потоков) для последних временных диапазонов в подмножестве областей AutoOps, была полностью решена. Данные о здоровье кластеров, осколках и развертывании не были затронуты, и никакие данные не были потеряны.

Автоматический перевод официального обновления инцидента.

1. 16 сентября 2026 г. в 13:17 UTCinvestigating

   В настоящее время мы знаем, что некоторые клиенты могут быть не в состоянии получить доступ к Elastic Support Portal. Мы работаем с нашим провайдером для расследования. Если вам необходимо связаться со службой поддержки, пожалуйста, свяжитесь с [email protected].

2. 16 сентября 2026 г. в 14:49 UTCmonitoring

   Мы видим признаки восстановления на портале Elastic Support Portal, и клиенты теперь должны иметь доступ как обычно. Мы продолжим мониторинг в течение 30 минут, прежде чем отметим этот инцидент как разрешенный.

3. 16 сентября 2026 г. в 15:38 UTCresolved

   Портал Elastic Support Portal остается доступным и стабильным - на данный момент мы рассматриваем этот инцидент как разрешенный.

Автоматический перевод официального обновления инцидента.

1. 12 сентября 2026 г. в 23:21 UTCinvestigating

   Мы изучаем метрики задержек в консоли.

2. 13 сентября 2026 г. в 00:18 UTCidentified

   Мы определили и устранили причину задержки метрик. Очередь обрабатывается, и отложенные метрики будут видны при завершении.

3. 13 сентября 2026 г. в 02:55 UTCmonitoring

   Очереди метрик обрабатываются, и отложенные данные снова начинают показываться. Мы будем следить, чтобы убедиться, что все настигнет, как ожидалось.

4. 13 сентября 2026 г. в 07:45 UTCresolved

   Метрики задержки приема в GCP us-east4 были полностью решены. Все данные очередей были обработаны, и метрики теперь отображаются в консоли в режиме реального времени.

Автоматический перевод официального обновления инцидента.

1. 10 сентября 2026 г. в 01:30 UTCidentified

   Мы определили и находимся в процессе исправления ошибки в нашем пользовательском интерфейсе управления разрешениями, которая предотвращает доступ пользователей с ролью владельца организации и облачной консолью, Elasticsearch и Kibana к Kibana в размещенных развертываниях.

2. 10 сентября 2026 г. в 06:03 UTCidentified

   Обновление: Этот инцидент продолжается, и мы продолжаем расследование.

3. 10 сентября 2026 г. в 09:51 UTCmonitoring

   Обновление: исправление было развернуто в производстве, и мы применили коррекцию данных к затронутым учетным записям, восстановив доступ к Kibana для пострадавших пользователей. Мы следим за тем, чтобы подтвердить полную резолюцию.

4. 10 сентября 2026 г. в 22:31 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 9 сентября 2026 г. в 20:44 UTCidentified

   Мы выявили ошибку в Fleet Server 9.5.3 (также присутствует в 9.4.6), которая может привести к аварийному циклу и отключению Elastic Agents, когда Fleet продвигает обновление конфигурации, включая регистрацию, изменение политики или обычную ревизию. Это влияет только на политики, которые используют функцию удаленного вывода Elasticsearch от Fleet. Рекомендация: Если вы используете удаленный выход Elasticsearch, не обновляйте до 9.5.3 или 9.4.6, пока не будет доступна фиксированная версия. Если вы уже находитесь на затронутой версии и испытываете сбои при регистрации агента, обратитесь в службу поддержки для этапов восстановления. Фиксация была объединена и будет поставляться в следующих выпусках 9.5.x и 9.4.x. Известен выпуск документации: флот-сервер #7791, эластичный-агент #16542.

2. 11 сентября 2026 г. в 14:25 UTCidentified

   Мы исправили версии Fleet Server 9.5.3 и 9.4.6 с исправленными релизами, развернутыми по состоянию на 10 сентября 2026 года в 21:20 UTC. Обновление до текущих выпусков 9.4.6 или 9.5.3 не будет затронуто этой ошибкой, поскольку обновленный выпуск содержит исправление. Если вы перешли на 9.4.6 или 9.5.3 до 21:20 UTC 10 сентября 2026 года, выполните следующие действия: 1.Принудительный перезапуск компонента Интеграционного сервера, который повлиял на развертывание 2. Запускайте процедуры очистки на пораженных Эластичных Агентах (см. https://support.elastic.co/knowledge/bee1c75c) - требуется, если агенты не смогли войти или остались в автономном режиме после перезапуска Интеграционного Сервера

3. 11 сентября 2026 г. в 16:00 UTCidentified

   Мы исправили версии Fleet Server 9.5.3 и 9.4.6 с исправленными релизами, развернутыми по состоянию на 10 сентября 2026 года в 21:20 UTC. Обновление до текущих выпусков 9.4.6 или 9.5.3 не будет затронуто этой ошибкой, поскольку обновленный выпуск содержит исправление. Если вы перешли на 9.4.6 или 9.5.3 до 21:20 UTC 10 сентября 2026 года, выполните следующие действия: 1.Принудительный перезапуск компонента Интеграционного сервера, который повлиял на развертывание 2. Запускайте процедуры очистки на пораженных Эластичных Агентах (см. https://support.elastic.co/knowledge/bee1c75c) - требуется, если агенты не смогли войти или остались в автономном режиме после перезапуска Интеграционного Сервера ВАЖНО: исправленный Fleet Server не доступен за пределами пакетов стека Elastic Cloud Enterprise (ECE) и Elastic Cloud Hosted (ECH).

4. 17 сентября 2026 г. в 10:30 UTCresolved

   Мы подтвердили, что Elastic Agents больше не испытывают сбоев в регистрации, связанных с этой проблемой. Исправленные версии Fleet Server (9.5.4 / 9.4.6) были доступны в пакетах стека Elastic Cloud Hosted и Elastic Cloud Enterprise с 10 сентября 2026 года. Если вы перешли на пораженный релиз до этого времени и еще не применили смягчение, руководство доступно здесь: https://support.elastic.co/knowledge/bee1c75c.

Автоматический перевод официального обновления инцидента.

1. 2 сентября 2026 г. в 00:04 UTCresolved

   С 21:50 до 23:42 UTC мы столкнулись с повышенными показателями ошибок для Anthropic Claude Haiku 4.5, OpenAI GPT-5.6 и Google Gemini 2.5. Flash с Elastic Inference Service в регионах ЕС. Сейчас этот вопрос решен.

Автоматический перевод официального обновления инцидента.

1. 1 сентября 2026 г. в 15:18 UTCinvestigating

   В настоящее время мы расследуем проблему, затрагивающую службы, работающие в GCP us-central1. Мы предоставим дополнительные обновления, поскольку мы узнаем больше о масштабах воздействия.

2. 1 сентября 2026 г. в 15:51 UTCidentified

   Продолжающаяся проблема затрагивает службы, работающие в GCP us-central1. Это включает в себя, но не ограничивается, проекты Elastic Cloud Hosted и Serverless в регионе и наш сервис Docker Registry. Мы продолжаем следить за ситуацией и будем предоставлять обновления, когда они будут доступны.

3. 1 сентября 2026 г. в 16:15 UTCidentified

   Текущая проблема CSP влияет на услуги, работающие в GCP us-central1. Это включает в себя, но не ограничивается, проекты Elastic Cloud Hosted и Serverless в регионе и наш сервис Docker Registry. Мы продолжаем следить за ситуацией и будем предоставлять обновления, когда они будут доступны.

4. 1 сентября 2026 г. в 16:22 UTCmonitoring

   Мы видим признаки восстановления услуг в GCP us-central1, на которые влияет проблема CSP. Мы продолжаем следить за ситуацией и будем предоставлять обновления по мере их поступления.

5. 1 сентября 2026 г. в 20:05 UTCresolved

   Этот вопрос решен.

Автоматический перевод официального обновления инцидента.

1. 1 сентября 2026 г. в 08:16 UTCinvestigating

   Мы знаем об ошибке, затрагивающей клиентов в версиях Elasticsearch 9.5.0, 9.5.1 и 9.5.2, когда операции с объемным индексом, обработанные на первичном осколке, могут привести к расхождению на репликах, что приводит к высокому использованию диска и длительному восстановлению. Команда работает над исправлением. Более подробную информацию можно найти на https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues Следующее обновление будет в ближайшие 2 часа или раньше, если это необходимо.

2. 1 сентября 2026 г. в 11:07 UTCidentified

   Мы определили первопричину, и команда работает над исправлением, которое должно быть выпущено в версии Elasticsearch 9.5.3. Что вы можете сделать: Если вы еще не обновились до 9.5.*, вы не пострадаете, поскольку обновления до 9.5 были отключены до тех пор, пока не будет выпущено 9.5.3. Если вы уже используете 9.5 и испытываете симптомы этой проблемы, пожалуйста, свяжитесь с Elastic Support. Более подробную информацию можно найти на https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues

3. 1 сентября 2026 г. в 15:46 UTCidentified

   Это исправление было идентифицировано и возвращено в ветвь пластыря Elasticsearch 9.5. Команды выполняют необходимые проверки перед планированием и развертыванием выпуска 9.5.3.

4. 3 сентября 2026 г. в 12:13 UTCmonitoring

   Elasticsearch 9.5.3 был выпущен, и всем клиентам, работающим в настоящее время под управлением 9.5.0, 9.5.1 или 9.5.2, рекомендуется как можно скорее обновить эту новую версию.

5. 3 сентября 2026 г. в 15:47 UTCmonitoring

   Elasticsearch 9.5.3 был выпущен, и всем клиентам, работающим в настоящее время под управлением 9.5.0, 9.5.1 или 9.5.2, рекомендуется как можно скорее обновить эту новую версию. Пострадавшим клиентам рекомендуется следовать обходным шагам от https://github.com/elastic/elasticsearch/issues/158212 после обновления.

6. 30 сентября 2026 г. в 20:44 UTCresolved

   Этот вопрос был решен в 9.5.3 выпуске Elasticsearch. Клиентам, использующим версии 9.5.0, 9.5.1 или 9.5.2 Elasticsearch, рекомендуется как можно скорее обновиться до новой версии.

Автоматический перевод официального обновления инцидента.

1. 27 августа 2026 г. в 17:11 UTCmonitoring

   26 августа около 00:00 UTC мы внедрили изменения в управляемых вводах, которые повлияли на некоторые правила нашего внутреннего поставщика DNS, удалив конечные точки .apm. Служба была восстановлена около 9 утра по Гринвичу в тот же день. В течение этого времени некоторые клиенты испытывали недоступность конечной точки .apm в течение периода в 9-часовом окне. Мы проводим проверки и оповещения, чтобы это не повторилось.

2. 27 августа 2026 г. в 18:33 UTCresolved

   Теперь это решено

Автоматический перевод официального обновления инцидента.

1. 20 августа 2026 г. в 20:22 UTCinvestigating

   В настоящее время мы изучаем повышенные показатели ошибок, влияющие на управляемый OTLP на Elastic Cloud Serverless. Наша команда активно исследует первопричину. Мы предоставим обновление в течение 30 минут.

2. 20 августа 2026 г. в 20:53 UTCinvestigating

   Мы продолжаем исследовать повышенные показатели ошибок, влияющие на управляемый OTLP на Elastic Cloud Serverless. Мы предоставим обновление в течение 1 часа.

3. 20 августа 2026 г. в 21:59 UTCidentified

   Мы определили первопричину повышенной частоты ошибок, влияющих на безсерверный управляемый OTLP. Было применено смягчение последствий, и мы отслеживаем, чтобы подтвердить, что частота ошибок возвращается к исходному уровню. Основываясь на нашем расследовании, рабочие нагрузки клиентов не были затронуты.

4. 20 августа 2026 г. в 22:13 UTCresolved

   Этот инцидент был урегулирован. Коренная причина была выявлена и устранена. Рабочие нагрузки клиентов не были затронуты во время этого инцидента.

Автоматический перевод официального обновления инцидента.

1. 20 августа 2026 г. в 12:48 UTCinvestigating

   Выявлена проблема, затрагивающая создание новых проектов без серверов в восточном регионе Azure. Наша команда активно исследует, чтобы определить первопричину. Мы предоставим последующее обновление статуса в течение следующего часа или как только будет установлена первопричина, в зависимости от того, что произойдет раньше.

2. 20 августа 2026 г. в 14:05 UTCmonitoring

   Мы определили, что проблема связана с проблемой хранения Azure. При исследовании влияние строго ограничено временем инициализации нового проекта, что приводит к увеличению времени создания проектов без серверов в регионе Azure Eastus. Мы предоставим дополнительную информацию, как только проблема будет решена.

3. 20 августа 2026 г. в 16:22 UTCresolved

   Вопросы хранения компонентов Azure в восточном регионе были решены. Следовательно, время создания проектов без серверов вернулось к норме и работает, как и ожидалось.

Автоматический перевод официального обновления инцидента.

1. 14 августа 2026 г. в 09:22 UTCidentified

   Elasticsearch 9.5.1 содержит известную проблему, в которой булевые запросы, содержащие пункт must, filter или should с использованием многозначного запроса терминов, наряду с пунктом must not на полях с отключенной индексацией, все еще могут возвращать ложноположительные совпадения. В то время как патч в 9.5.1 (https://github.com/elastic/elasticsearch/pull/155936) устранил дефект оптовой колонки для путей запросов терминов и диапазонов; многозначные запросы терминов используют другой тип запроса Lucene, который не был охвачен этим исправлением. Потоки данных временного ряда (TSDB) и столбцовые индексы / потоки данных остаются затронутыми для этого шаблона запросов, поскольку индексация по умолчанию отключена на этих полях. Пострадавшие запросы терминов могут возвращать ложноположительные совпадения (включая документы, которые должны были быть исключены) и сообщать о более высоком количестве документов, чем ожидалось. Ошибок не возникает, поэтому запросы будут успешно выполняться. Что вы можете сделать: Если вы еще не обновились до 9.5.*, мы рекомендуем отложить обновление до версии 9.5.2. Если вы уже используете 9.5.*, свяжитесь с Elastic Support, если вам нужна помощь в определении того, затронуты ли ваши поиски. Мы определили первопричину, исправление продолжается, и мы готовим патч-релиз. Мы предоставим дополнительное обновление, когда исправление будет готово.

2. 20 августа 2026 г. в 17:09 UTCresolved

   Elasticsearch 9.5.2 был выпущен и содержит исправление этой проблемы. Клиенты, работающие под управлением 9.5.0 или 9.5.1, должны обновиться до 9.5.2. На данный момент мы рассматриваем этот вопрос и не будем предоставлять никаких дальнейших обновлений.

Автоматический перевод официального обновления инцидента.

1. 13 августа 2026 г. в 08:32 UTCinvestigating

   Мы видим повышенные показатели ошибок от восходящего провайдера для модели встраивания microsoft-multilingual-e5. Поисковые запросы на встраивание в эту модель могут потерпеть неудачу. Мы расследуем

2. 13 августа 2026 г. в 14:45 UTCinvestigating

   Мы видим некоторое улучшение доступности, но продолжаем следить за ситуацией. Мы будем следить за дополнительной информацией в надлежащее время.

3. 13 августа 2026 г. в 18:26 UTCmonitoring

   К сожалению, мы больше не можем поддерживать модель E5 Multilingual Large на Elastic Inference Service из-за продолжающихся проблем с поставщиками. Любые клиенты, нуждающиеся в этой модели, должны настроить пользовательские конечные точки вывода, используя свои собственные ключи API.

4. 17 августа 2026 г. в 11:40 UTCresolved

   Модель microsoft-multilingual-e5-large была удалена из Elastic Inference Service. Запросы на эту модель теперь возвращают ошибку. Клиенты, которые хотят использовать эту модель с Elastic Cloud, должны создать пользовательскую конечную точку вывода, используя свой собственный ключ API. См. нашу справочную документацию для получения дополнительной информации: https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference

Автоматический перевод официального обновления инцидента.