ES|QL Workshop

Регистрируйтесь на воркшоп от Elastic, который состоится 23 июня в 11 часов по московскому времени.

ES|QL вскоре будет основным языком запросов для Elasticsearch. Он разработан таким образом, чтобы его было легко освоить и использовать конечным пользователям, командам SRE, аналитикам безопасности, разработчикам приложений и администраторам. Используя ES|QL, вы сможете находить конкретные события, проводить статистический анализ и создавать визуализации.

@elasticstack_ru

Проведем тренинг ElasticSearch 8-10 июля

Освойте Elasticsearch на практике за 3 дня, научитесь уверенно использовать его в промышленной эксплуатации и быстро погрузитесь в тему.

За 3 дня вы:

✅ Разберётесь с архитектурой Elasticsearch и принципами работы кластера.

✅ Научитесь правильно проектировать mappings и выбирать типы данных.

✅ Освоите Query DSL — от простых запросов до сложных агрегаций и полнотекстового поиска.

✅ Поймёте, как работают анализаторы, токенизаторы и скоринг.

✅ Настроите отказоустойчивый кластер, репликацию, резервное копирование и восстановление.

✅ Разберёте ILM, Data Streams, Ingest Pipelines и другие механизмы жизненного цикла данных.

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

Тренинг уже на следующей неделе! Следующий такой только в октябре.

Программа ElasticSearch 8-10 июля

Вопросы можно задать @galssoftware или через форму обратной связи на странице с программой тренинга.

Два полезных плагина VSCode для OpenSearch и OpenSearch

OpenSearch DevTools & Support

Elasticsearch DevTools & Support

Оба плагина поддерживают выполнение запросов и команд, автодополнение, оборачивание фрагменты запроса логическими условиями (filter, should, must_not), проверка типа поля
анализ влияния на производительность. и содержат генератор фиктивных данных.

@elasticstack_ru

OpenSearch Demystified

Знакомьтесь — удобный путеводитель по возможностям OpenSearch. Здесь вы можете ознакомиться с разными возможностями системы в интерактивном формате. Подойдет тем, кто только начинает знакомство с OpenSearch.

opensearch.9cld.com

А если вы хотите изучить OpenSearch в простом и удобном формате — приходите 📅 23-25 сентября на наш 3-дневный интенсив 🎓 OpenSearch База, где вы познакомитесь с этой системой. Программа интенсива.

@elasticstack_ru

Вышел OpenSearch 3.8

Что нового:

🚀 Расширение MCP-интеграций на большее количество типов агентов

🚀 Потоковая передача результатов машинного обучения с меньшей задержкой с использованием транспортного протокола gRPC

🚀 Ускоренная обработка векторов в 4,16 раз быстрее и повышение производительности радиального поиска до 2,1 раз

🚀 Масштабирование оценки релевантности поиска за счет доступа к большему количеству крупных поставщиков LLM

🚀 Оптимизация анализа логов с помощью визуального конструктора языка конвейерной обработки (PPL), SQL-запросов и шаблона

🚀 Формирование, преобразование и сравнение данных временных рядов с помощью новых команд PPL

Подробности в блоге OpenSearch

@elasticsearch_ru

Вышел Elastic 9.5

Уж не знаем договаривались они или нет, но анонс по новым релизам у Elastic и OpenSearch случился в один и тот же день — вчера.

Обновления Elastic более масштабные:

🚀 Elasticsearch теперь умеет хранить данные аки колоночная база данных

🚀 Появился режим индексирования VectorDB и автоматическая калибровка векторного поиска

🚀 Появилась встроенная поддержка Prometheus и PromQL

🚀 Реализован принцип «нулевого почтового ящика» — очередь важных событий со встроенным анализом событий

🚀 Улучшенный Elastic Agent Builder , включая мониторинг и отслеживание действий агентов, а также расширенные возможности утверждения с участием человека

🚀 и несколько других улучшений.

Подробности в блоге Elastic

@elasticsearch_ru

Проведем аудит систем логирования Elasticsearch / OpenSearch

Системы централизованного логирования редко ломаются в один день. Обычно проблемы накапливаются постепенно: растут индексы, увеличивается нагрузка на CPU и диски, ingestion начинает отставать, очереди переполняются, а часть логов незаметно теряется. В итоге компания платит больше за инфраструктуру, а в момент инцидента может оказаться, что нужных данных либо нет, либо система логирования сама недоступна.

Мы предлагаем услугу комплексного аудита систем логирования на базе Elasticsearch и OpenSearch.

В рамках аудита мы анализируем не только сам кластер, но и весь путь данных — от источника до индекса:
— архитектуру и конфигурацию Elasticsearch / OpenSearch;

— распределение ролей, shards и replicas;
— sizing CPU, RAM, heap и дисковой подсистемы;
— политики ILM / ISM, rollover и retention;
— mappings, templates и структуру индексов;
— использование compression и эффективность хранения;
— скорость indexing и search workloads;
— риски отказа отдельных узлов и потерю доступности кластера;
— snapshot / backup strategy и возможность восстановления;
— конфигурации Filebeat, Vector и OpenTelemetry Collector;
— pipelines Logstash и Vector;
— batching, buffering, retry, backpressure и очереди;
— ситуации, при которых данные могут быть потеряны между источником и Elasticsearch / OpenSearch.

Что это даёт вам?

Во-первых — возможность снизить стоимость инфраструктуры. Очень часто кластер потребляет больше CPU, RAM и дисков не потому, что данных действительно много, а из-за неэффективной структуры индексов, слишком большого количества shards, неправильного rollover или избыточной обработки событий.

Во-вторых — понимание реальной надёжности pipeline. Например:

Vector/Filebeat → Kafka → Vector/Logstash → ElasticSearch/OpenSearch

может выглядеть надёжно на схеме, но достаточно неправильно настроенного memory buffer, отсутствия persistent queue или некорректного retry — и при кратковременной недоступности OpenSearch или ElasticSearch часть логов просто исчезнет.

В-третьих — снижение риска ситуации, когда во время аварии система логирования становится недоступна именно тогда, когда она нужна больше всего.

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

Наша цель — ответить на три простых вопроса:

Не переплачиваете ли вы за хранение и обработку логов?

Не теряются ли ваши данные по дороге?

Переживёт ли система логирования реальный отказ?

Если у вас Elasticsearch или OpenSearch уже давно работает в production и никто системно не пересматривал его архитектуру — аудит обычно быстро показывает, где находятся самые дорогие и самые рискованные места.

Вопросы можно задать @galssoftware или на почту hello@gals.software.

Поиск в глубину: какие инструменты помогают работать поиску в Uzum Market

Интересная статья про подход к поиску в Uzum Market (маркетплейс из Узбекистана). Под капотом там ElasticSearch, но не только он. Они как раз и рассказывают как устроен поиск до момента непосредственного запроса в ElasticSearch.

@elasticsearch_ru

Wazuh без ограничений дашборда: работаем напрямую с индексами

Wazuh хорош ровно до тех пор, пока вам хватает того, что умеют его штатные дашборды. А потом внезапно выясняется, что все нужные данные уже давно лежат в обычном OpenSearch.

В статье — как работать с Wazuh Indexer напрямую: читать алерты и состояния, строить агрегации, выгружать большие объёмы данных, делать свои отчёты, алертинг и обогащение.

Отдельно полезен разбор того, чем отличается Server API от Indexer, как не положить кластер тяжёлыми запросами и к чему готовиться в Wazuh 5.0, где схему индексов заметно поменяли.

Ссылка на статью

@elasticsearch_ru

Online index migration and shard scaling in OpenSearch with the AOSC plugin

AOSC — это open-source плагин от Atlassian для OpenSearch, который автоматизирует онлайн-миграцию индекса внутри одного кластера. Он позволяет перенести live-индекс в новый индекс с другими маппингом, настройками, количеством шардов или изменённой структурой документов. При этом исходный индекс большую часть времени продолжает принимать записи.

AOSC решает ключевую проблему с _reindex, который копирует только текущее состояние данных и сам по себе не умеет докопировать новые записи и учитывать удаленные документы, появившиеся во время миграции. _split и _shrink тоже имеют ограничения, которые не позволяют перенести данные онлайн.

Миграция в AOSC проходит по нескольким фазам: проверка источника/цели/алиасов, подготовка целевого индекса, заливка существующих документов, повтор новых операций и удалений, финальная проверка количества документов и переключение alias на новый индекс.

Во время заливки документов AOSC использует retention lease, чтобы история операций не была удалена, а затем воспроизводит изменения, которые произошли в источнике во время копирования. Это позволяет целевому индексу постепенно догнать live-индекс перед переключением.

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

Ну, и основное ограничение, AOSC работает только внутри одного OpenSearch-кластера и требует, чтобы приложение работало через alias, а не обращалось напрямую по имени индекса.

Статья в блоге OpenSearch

Репо на Гитхабе

@elasticsearch_ru

A visual guide to troubleshooting search performance using Query Insights dashboards

В статье рассмотрены варианты визуализаций Query Insights и показано как использовать их для диагностики и устранения реальных проблем с производительностью.

Query Insights — специализированный плагин, который позволяет отслеживать производительность кластера OpenSearch в режиме реального времени.

Ссылка в блог OpenSearch

@elasticsearch_ru