Elastic Stack recipes

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

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

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

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

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

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

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

Вышел OpenSearch 3.3

Заметки к выпуску

Песочница

В этом релизе представлена ​​предварительная версия полностью переработанного интерфейса OpenSearch Dashboards. На изображении, прикрепленном к этому посту, вы как раз можете видеть переработанный раздел Discover.

На другом изображении вы видите раздел Service Map — карту сервисов, построенную на основе трейсов.

О других улучшениях читайте по ссылке выше.

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

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

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

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

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

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

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

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

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

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

Совет дня

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

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

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

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

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

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

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

Diving deep into distributed microservices with OpenSearch and OpenTelemetry

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

5 Essential considerations for an Elasticsearch to OpenSearch migration

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

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

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

Tutorial: Threat hunting with ES|QL

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

Introducing a more powerful, resilient, and observable ES|QL in Elasticsearch 8.19 & 9.1

Уже пробовали использовать ES|QL в Elasticsearch/Kibana? Штука упрощает написание запросов, когда от json уже рябит в глазах. В этой статье в блоге Elastic рассказывают об улучшениях этого языка в последний версиях продукта.

VRL — просто, подробно и понятно

Vector является очень гибким агрегатором сообщений и поддерживает собственный язык для обработки событий - VRL. В статье разобраны примеры конфигурации Vector.

Elasticsearch plugin for UBI: Analyze user behavior from search queries

UBI (User Behavioral Insights) — это стандарт, помогающий собирать и отслеживать статистику использования поисковых приложений. В этой статье рассматривается стандарт UBI и объясняется, как собирать аналитику с помощью плагина Elasticsearch.

Пошаговое руководство по миграции из одного кластера в другой

В статье в блоге Elastic разобраны 3 способа миграции данных:

🚀 Переиндексация из удаленного кластера

🚀 Передача данных с использованием снимков

🚀 Перенос данных с помощью Logstash

Вышли Elastic 9.1/8.19

Интересный подход получается с релизами двух мажорных версий. Похоже, что в Elastic не хотят расстраивать пользователей, который уже основательно сжились с 8 версией. Но, как пишут, это в последний раз. Дальнейшего развития версии 8.х не будет. Подробности в блоге Elastic.

Making ingestion smarter: System ingest pipelines in OpenSearch

В OpenSearch 3.1 представлен системный ingest pipepline — новая возможность, сделанная специально для разработчиков плагинов. Она позволяет автоматически обрабатывать документы во время заливки данных, определяя системные процессоры, которые запускаются на основе полей или параметров при сопоставлении индекса. Это позволяет встраивать логику обработки непосредственно в плагин, не требуя от пользователей ручной настройки ingest pipeline. Читать в блоге OpenSearch.

Redline-тестирование теперь доступно в OpenSearch Benchmark

Тестирование Redline содержит в себе:

🚀 Модуль управления для мониторинга пропускной способности запросов и сбоев в режиме реального времени.

🚀Саморегулирующийся механизм нагрузки, позволяющий приостанавливать и возобновлять работу клиентов на основе поведения кластера.

Читать в блоге OpenSearch

Get started with OpenSearch 3.1

Не успели мы опомнится от версии 3.0, как OpenSearch анонсировал 3.1. Лихо, что тут скажешь.

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

Загрузка

Заметки к выпуску