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

Расчет состоит из 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.

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

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

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

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

@elasticstack_ru

Decrease your storage costs with Amazon OpenSearch Service index rollups

В этой статье в блоге AWS рассмотрен механизм rollup в OpenSearch, который позволяет выполнять агрегацию данных в индексах для снижения объема хранимых данных. Это один из способов оптимизации.

@elasticstack_ru

Приглашаем вас на совместный вебинар Yandex Cloud и Галс Софтвэр, посвящённый возможностям и практическим аспектам работы с сервисом Managed OpenSearch.

📅 Дата: 2 февраля 2026 года
🕒 Формат: онлайн
🎙 Участие: бесплатное, по предварительной регистрации

👉 Зарегистрируйтесь на вебинар заранее, чтобы получить ссылку на трансляцию и материалы участников.

⚡️Спикеры вебинара:

🗣 Владислав Таболин, руководитель группы разработки Yandex Cloud, расскажет:

🚀 об архитектуре и особенностях сервиса Managed OpenSearch;
🚀 ключевых преимуществах управляемого сервиса;
🚀 сценариях использования OpenSearch в корпоративных и высоконагруженных системах;
🚀 вопросах надёжности, масштабирования и эксплуатации.

🗣Антон Касимов, основатель компании Галс Софтвэр, поделится:

🚀 методами оптимизации хранения данных в OpenSearch;
🚀 подходами к снижению затрат на хранение;
🚀 подробностями хранения данных в OpenSearch;
🚀 типичными ошибками и best practices из реальных проектов.

Кому будет полезен вебинар:

🚀 инженерам и архитекторам;
🚀 DevOps и SRE-специалистам;
🚀 руководителям ИТ-подразделений;
🚀 всем, кто использует или планирует использовать OpenSearch в продуктивных системах.

В завершение вебинара вас ждёт сессия вопросов и ответов, где спикеры разберут реальные кейсы и практические ситуации.

👉 Зарегистрируйтесь на вебинар, чтобы:

🚀 получить доступ к трансляции;
🚀 задать вопросы экспертам Yandex Cloud и Галс Софтвэр;
🚀 получить материалы и запись после мероприятия.

❗️ Будем рады видеть вас на вебинаре!

Совет дня (JVM)

ElasticSearch как и OpenSearch используют JVM для своей работы, и лучшие практики рекомендуют выделять около 50% доступной на узле памяти для JVM. JVM использует память для обеспечения быстрого доступа процесса Lucene к значениям индексов. Остальные 50% остаются для кэша файловой системы, который хранит в памяти данные, к которым часто обращаются. И еще одна рекомендация — не более 30 Гб на JVM Heap, это пороговое значение на использование сжатых указателей (ordinary object pointers (oops)). В противном случае JVM будет работать неоптимально.

Ниже мы собрали несколько статей, в которых есть полезные советы по настройке и мониторингу JVM.

Elasticsearch memory usage guide

High JVM memory pressure

JVM settings

Elasticsearch Circuit Breaker Exceptions: How to Handle Circuit Breakers

@elasticstack_ru

Вебинар по OpenSearch уже сегодня в 10 часов по московскому времени

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

Регистрация

Запись нашего сегодняшнего вебинара уже на нашем канале на Youtube! Подписка на канал горячо приветствуется👍

Все зарегистрированные участники дополнительно получат ссылку на презентации.

How to Collect, Process, and Ship Log Data with Vector

Vector — это мощный агрегатор логов с открытым исходным кодом, разработанный компанией Datadog. Он позволяет создавать конвейеры мониторинга, легко получая логи из множества источников, преобразуя данные по мере необходимости и направляя их в нужное место назначения. Vector выделяется своей легковесностью, исключительной скоростью и эффективностью использования памяти, в основном благодаря реализации на языке Rust, известном своими возможностями управления памятью.

Если вы уже используете Vector или только планируете его использовать, обратите внимание на эту статью. Здесь разбираются практические кейсы настройки этого популярного сборщика и агрегатора данных.

@elasticstack_ru

Вышел OpenSearch 3.5

Не успели мы толком развернуть и насладиться 3.4, как вышла версия 3.5.

Что нового:

🚀 Расширена поддержка Prometheus для более глубокого анализа метрик (интерфейс Prometheus внутри OSD)

🚀 Улучшенная оптимизация поиска с помощью Search Relevance Workbench

🚀 Поддержка памяти агента для самообучающихся приложений (добавили ИИ-агентам постоянную структурированную память непосредственно в OpenSearch)

🚀 Повышен контроль над производительностью и эффективностью запросов (улучшен Query insights)

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

@elasticstack_ru