Вдогонку к предыдущему посту:

Tutorial: Threat hunting with ES|QL

Это уже ссылка на документацию.

5 Essential considerations for an Elasticsearch to OpenSearch migration

В этой статье опытный автор рассказывает о пяти моментах, которые, на его взгляд, являются либо наиболее важными, либо наиболее упускаемыми из виду. Таким образом, вы сможете извлечь уроки из этого опыта и исследований и использовать их при миграции с Elasticsearch на OpenSearch.

Поставьте ⚡️, если вы когда-либо выполняли такую миграцию или собираетесь ее делать.

Diving deep into distributed microservices with OpenSearch and OpenTelemetry

В этой статье из блога OpenSearch рассказывают про новые функции, представленные в плагине Trace Analytics в версии 3.1: улучшенная визуализация карты сервисов, расширенная группировка интервалов и диаграммы распределения задержек. Также вы узнаете как использовать OpenTelemetry (OTel) Collector с OpenSearch Data Prepper для инструментирования, сбора и загрузки данных телеметрии в OpenSearch и как использовать OpenSearch Dashboards для изучения, визуализации и анализа процесса наблюдаемости.

Совет дня

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

С появлением сегментной репликации и удалённого хранилища в OpenSearch эта модель получила изменения. При репликации сегментов только основной узел сегмента выполняет операции индексации и записывает файлы сегментов в удалённое хранилище объектов, например, S3-совместимое хранилище, Google Cloud Storage или Azure Blob Storage. Затем сегменты-реплики параллельно загружают файлы сегментов из хранилища объектов, устраняя необходимость повторного выполнения операций индексации на каждой реплике. Удивительно, что в ElasticSearch так и не добавили этот функционал.

С версии OpenSearch 3.0 появились новые типы шардов: реплики для записи и реплики для поиска:

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

Реплики поиска: обслуживают исключительно поисковые запросы и не могут быть повышены до основных.

Читайте подробности о том как это устроено в блоге OpenSearch.

Описание в документации.

Векторный поиск в Elasticsearch: dense_vector, HNSW и фильтрация по атрибутам

В Elasticsearch поддержка векторного поиска реализована через поле dense_vector и алгоритм HNSW (Hierarchical Navigable Small World) для быстрого приближённого поиска ближайших соседей. В этой статье разобрано, как настроить индекс с векторным полем, добавить документы с векторами и выполнять запросы kNN с возможностью фильтрации по дополнительным атрибутам.

Какие улучшения сделал Яндекс в OpenSearch

Яндекс значительно улучшил OpenSearch, который они предоставляют в своем облаке.

Посмотрели всем коллективом доклад про OpenSearch с конференции Yandex NeuroScale 2025. Коллеги улучшили OpenSearch собственным алгоритмом балансировки, ускоренной индексацией, расширенным сжатием данных и поддержкой морфологии. Причем последнее они взяли из своего яндексового поиска.

Запись доклада по ссылке (смотреть с 4:27:00), там все подробности.

Пользуясь случаем приглашаем вас на наш интенсив по OpenSearch, который состоится уже

📅 29-31 октября. Программа тренинга.

На нем мы также поговорим о разных интересных фичах OpenSearch и вы на практике освоите это решение за максимально сжатый срок. Заявки на обучение присылайте на hello@gals.software или в @gals_education_bot.

Совет дня: как рассчитать сайзинг кластера

Расчет состоит из 3 формул (ниже). В первой формуле мы рассчитываем сколько нам нужно места для хранения, во второй накидываем 20% на дополнительные нужды, а в 3 формуле уже считаем количество нод, которое нужно предусмотреть для размещения такого количества данных. Этими формулами поделился Elastic на одном из вебинаров.

Формулы

1. Общее количество данных (Гб) = Сырые данные в день * Количество дней хранения * фактор трансформации данных * (количество реплик +1)

2. Общее хранилище данных (Гб) = Общее количество данных (Гб) *(1 + 0,15 запаса + 0,05 дополнительные нужды)

3. Общее количество нод = ОКРВВЕРХ (Общее хранилище данных (Гб) / Объём памяти на ноду / соотношение памяти к данных)

Пояснения по формулам:

Фактор трансформации данных по умолчанию равен 1. Он зависит от типов данных, которые вы будете размещать в кластере: текст, кейворд, числа, даты и т.д.

ОКРВВЕРХ — округление вверх до ближайшего целого числа

Объем памяти на ноду берем стандартный 64 Гб (можно меньше). По CPU рекомендация использовать серверы с 16 ядрами.

Соотношение памяти к данным. В зависимости от фазы хранения (относительно политики управления жизненным циклом индексов, ILM), мы берем его равным 1/30 для горячей фазы, 1/100 для теплой и 1/500 для холодной.

Пример расчета

Допустим, к нам приходит 100 Гб/день и нам нужно хранить эти данные 30 дней с использованием 1 реплики. В итоге поучаем, что при таком раскладе нам нужно 4 ноды.

Общее количество данных (Гб) = 100 Гб* 30 * 1 * 2 = 6000 Гб
Общее хранилище данных (Гб) = 6000 Гб * 1,2 = 7200 Гб
Общее количество нод = ОКРВВЕРХ (7200 Гб / 64 / 30) = 4

@elasticstack_ru

Когда база устала искать: архитектура OpenSearch для больших данных

Реляционная СУБД - это ядро консистентности, но не оптимальный инструмент для полнотекстового и фасетного поиска. Логично разграничить роли: Postgres отвечает за транзакции и связи, а специализированный поисковый слой - за быстрый отклик и фильтрацию по множеству полей. 7 терабайт перестали быть проблемой: система масштабируется, а пользователи получают ответ мгновенно. OpenSearch стал не надстройкой, а естественной частью системы. Читать дальше на Хабре.

Делаем поиск более интеллектуальным с помощью системно генерируемых поисковых конвейеров

Новая статья в блоге OpenSearch. В OpenSearch 3.3 появились системно генерируемые поисковые конвейеры — новая возможность, разработанная для разработчиков плагинов. Она позволяет OpenSearch автоматически обрабатывать поисковые запросы, генерируя и подключая системные поисковые процессоры во время выполнения на основе контекста и параметров запроса.

Пошаговая настройка вывода логов из .NET-автотестов в ELK (Filebeat → Logstash → Elasticsearch → Kibana)

В этой статье разобран процесс вывода логов из приложения c автотестами на .NET в ELK с последующей визуализаций в Kibana.

ELK представляет из себя достаточно массивный инструмент для сбора, хранения, обработки и анализа логов, организации мониторингов. С наскоку разобраться с ним вряд ли получится, поэтому подготовили небольшую инструкцию с примерами - на базе простого теста прокинуть результаты до Kibana.

Интеграция OpenSearch: от функционального тестирования до проверки интеллекта поиска

В этой статье автор на реальном примере интеграции OpenSearch в LMS iSpring Learn рассказывает, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Будут разобраны не только базовые проверки, но и тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск». Читать дальше.

Better observability, deeper insights: OpenSearch’s new Piped Processing Language capabilities

Начиная с OpenSearch 3.3, язык конвейерной обработки (Piped Processing Language, PPL) включает новые и улучшенные возможности, упрощающие анализ логов и процессы наблюдения.

В этой статье рассмотрены новые команды и функции PPL на практических примерах распространённых сценариев использования аналитики логов. Вы узнаете, как эти улучшения помогают объединять несколько источников данных, обрабатывать неструктурированные данные логов и выполнять анализ временных рядов.

Вышел OpenSearch 3.4

Не успели мы опомниться от 3.3 как уже выходит новая версия.

🚀 Новый пользовательский интерфейс для агентного поиска.

🚀 Множество новых инструментов для повышения релевантности результатов поиска.

🚀 Расширенный набор  команд языка конвейерной обработки (PPL) для аналитических задач и задач мониторинга.

🚀 Значительное повышение производительности для задач агрегирования.

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

@elasticsearch_ru

Introducing resource sharing: A new access control model for OpenSearch

Начиная с OpenSearch 3.3, плагин Security дополнился системой совместного использования ресурсов и контроля доступа , которая позволяет пользователям обмениваться ресурсами с другими пользователями или ролями. Эта модель переносит авторизацию на уровне ресурсов на объекты более высокого уровня, определенные плагинами, и создает согласованный опыт совместной работы в OpenSearch.

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

Ссылка на документацию

Новый Продвинутый курс по OpenSearch

📅 Когда: 18-20 марта 2026 года

👨‍💻 Для кого: для тех, кто уже имеет опыт работы с OpenSearch и хочет углубить знания, а также улучшить кругозор в продукте.

📖 Что ждет на курсе:

🔎 День 1

🚀 Безопасность в OpenSearch. Работа с ролевой моделью. Ограничения для пользователей: настройка безопасности на уровне документов и полей документов. Аудит-лог. Интеграция с LDAP.

🚀 Распределенная архитектура OpenSearch. Кросс-кластерная репликация. Кросс-кластерный поиск. Отказоустойчивая архитектура OpenSearch. Кворум мастер-нод. Split-brain.

🚀 Продвинутые технологии репликации данных: подокументная и сегментная репликации. Разделение шардов по назначениям: индексация и поиск. Контроль рабочей нагрузки.

🚀 Доступность и восстановление. Продвинутая настройка политики ISM. Создание снапшотов и восстановление из них. Работа с searchable snapshots в хранилище S3.

🔎 День 2

🚀 Эффективная работа с данными. Оптимизация хранения данных. Типы полей. Продвинутый маппинг полей. Настройки индексов для оптимального хранения.

🚀 Загрузка данных. Работа с Vector, Logstash, DataPrepper, OpenTelemetry Collector, Ingest Pipeline. Настраиваем эффективные пайплайны и портируем пайлайны из одного ETL-инструмента в другой.

🚀 Работа с PPL, DQL и DSL. Эффективный поиск по данным.
Мониторинг кластера. Сбор ключевых метрик. Prometheus, Zabbix, Performance Analyzer.

🔎 День 3

🚀 Работа в OpenSearch Dashboards. Ролевая модель. Мультитенантность. Продвинутые визуализации. Создание PNG и PDF-отчетов.

🚀 Работа с Observability. Создание визуализаций для данных наблюдаемости (логи, трейсы, метрики). Работа с Notebooks.

🚀 Оповещения. Настройка уведомлений из OpenSearch и OpenSearch Dashboards.

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

Создание системы мониторинга Logstash с использованием Prometheus и Grafana (пошаговое руководство)

Мониторинг Logstash — это суровая необходимость. Есть множество вариантов, когда что-то может пойти не так. В этой статье пошаговая инструкция по настройке мониторинга Logstash при помощи Prometheus, Prometheus-logstash-exporter и Grafana.

🎓 Приходите на наш тренинг OpenSearch Advanced, где мы будем в том числе ставить на мониторинг Logstash и изучать его ключевые метрики.

@elasticstack_ru