Test Logstash Pipelines/Filters before Implementation

Эта статья намекает, что logstash можно запустить с ключом -f и протестировать конфигурацию перед запуском.

How to Upgrade Elasticsearch from Version 7 to Version 8

Если очень нужно, то вот пошаговая инструкция по обновлению.

What are the best Elasticsearch GUI clients?

Перечень GUI-клиентов для Elasticsearch

​Яндекс Облако сегодня проводили вебинар по OpenSearch. Рассказали об отличиях с Elasticsearch, как выполнить миграцию в OpenSearch и, конечно, о своём управляемом сервисе.

Paginate Your Search Result with Elasticsearch and Go

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

​Elasticsearch reindex - How to decrease the reindex time by more than 90% and simplify reindex process

В этой статье обзор существующих решений для Elasticsearch и решение с открытым исходным кодом, которое помогает упростить процесс переиндексации. Судя по контрольным показателям, использование этого приложения сэкономит до 90% времени!

Внедряем и сопровождаем 🔎ElasticSearch 🔎OpenSearch

Разбираемся в кейсах безопасности, логирования, поиска и APM-мониторинга.

На базе одной из этих бесплатных систем создадим для вас систему управления событиями информационной безопасности.

Вы всегда будете знать:

⚡️ кто и когда создал удалил новую учетную запись или группу в AD или Linux

⚡️ кто открывал, создавал или удалял файлы на файловом хранилище

⚡️ кто и когда подключался к 1С, веб-ресурсам компании, рабочим станциям, серверам или по VPN

⚡️ какие веб-ресурсы посещали пользователи (например, по данным прокси Касперского)

⚡️ когда происходит подбор пароля

⚡️ и о многих других событиях.

Все собранные данные мы аккуратно визуализируем в Kibana/OpenSearch Dashboards, чтобы вы могли видеть полную картину происходящего. По каждому событию настроим уведомления в почту или телеграм. Также мы проконсультируем по эффективному использованию этих систем в качестве SIEM-системы.

Если у вас уже есть в эксплуатации ElasticSearch/OpenSearch, мы займёмся его развитием и сопровождением или проведем для вас обучение на специализированных курсах по ElasticSearch и OpenSearch.

Запрос можно оставить через форму обратной связи на нашем сайте, отправить в адрес welcome@gals.software либо написать в телеграм @galssoftware.

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

Когда одна из дата- нод покидает кластер, мастер-нода реагирует следующим образом:

⛵️ Повышает реплика-шарды до праймари-шардов, чтобы заместить все праймари, которые были на потерянной ноде.
⛵️Распределяет реплика-шарды для замены потерянных реплик (при условии, что имеется достаточное количество нод).
⛵️Выполняет перераспределение шардов поровну между оставшимися нодами.

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

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

⛵️Нода теряет сетевое соединение.
⛵️Мастер-нода переводит реплика-шарды в праймари для каждого праймари-шарда, находившегося на выпавшей ноде.
⛵️Мастер распределяет новые реплики по другим нодам кластера.
⛵️Каждая новая реплика создает полную копию праймари-шарда.
⛵️Шарды ребалансируются на другие ноды кластера.
⛵️Потерянная нода возвращается через несколько минут.
⛵️Мастер-нода восстанавливает баланс кластера, выделяя шарды потерянной ноде.

Если бы мастер-нода подождала несколько минут, то потерянные шарды можно было бы перераспределить на потерянную ноду с минимальным сетевым трафиком.

Распределение реплик-шардов, которые становятся нераспределенными из-за отключения ноды, может быть отложено с помощью настройки index.unassigned.node_left.delayed_timeout, которая по умолчанию равна 1минуте. Этот параметр может быть обновлен без перезагрузки.

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

При включенном отложенном распределении вышеописанный сценарий выглядит следующим образом:

⛵️Нода теряет сетевое подключение.
⛵️Мастер-нода переводит реплика-шарды в праймари для каждого праймари-шарда, который находился на выпавшей ноде.
⛵️Мастер-нода регистрирует сообщение о том, что распределение неназначенных шардов было отложено и на какой срок.
⛵️Кластер остается желтым, потому что есть нераспределенные шарды-реплики.
⛵️Потерянная нода возвращается через несколько минут, до истечения тайм-аута.
⛵️Потерянные реплики повторно распределяются на выпадавшую ноду.

Эта настройка не влияет на повышение реплика-шардов до праймари, равно как и на назначение реплик, которые не были назначены ранее. Тут всё без изменений.

Если время отложенного распределения истекло, мастер-нода запускает процесс по первому сценарию.

Сталкивались ли вы с проблемами периодического кратковременного выпадения ноды из кластера?

Поле text на минималках или как сэкономить до 10% дискового пространства

Начиная с версии 7.14 в Elasticsearch появился новый тип поля match_only_text, который может быть использован в качестве замены поля типа text. Тип поля match_only_text обладает следующими характеристиками:

⚡️Оценка релевантности рассчитывается как количество совпадающих выражений.

⚡️Span-запросы не поддерживаются. Все остальные типы запросов, которые поддерживаются для полей типа text, также поддерживаются для полей match_only_text.

⚡️Фразовые и интервальные запросы выполняются медленнее, чем в текстовых полях, но намного быстрее, чем линейное сканирование. Другие типы запросов выполняются так же быстро.

Так за счет чего достигается оптимизация хранения? match_only_text — это тип поля, который отсекает некоторые характерные типу text вещи:

⚡️коэффициенты нормализации длины

⚡️частотности выражений

⚡️позиции в выдаче

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

P.S. Про 10% Elastic заявляет в своей статье блога. Для оптимизации хранения мы рекомендуем использовать поля типа keyword и удалять поле message после того как вы вытащили оттуда всё необходимое. В целом, match_only_text выглядит как некий компромисс, который вроде бы и не особо нужен при работе с текстовыми логами.

Приходилось ли вам использовать поле типа match_only_text в ваших индексах?

​Если вы решили мигрировать из ElasticSearch в OpenSearch, важно знать, что эти две системы хоть и близкие родственники, имеют некоторые отличия. Например, в принципах работы политик управления жизненным циклом индексов. В этом посте мы вкратце об этом расскажем.

В ElasticSearch технология управления жизненным циклом индексов называется Index Lifecycle Management (ILM), в OpenSearch она же называется Index State Management (ISM). Обе технологии построены на ролловере в рамках датастрима по критериям возраста, размера или количества документов в индексе. В обоих случаях при ролловере можно выполнять действия над индексами: изменять количество шардов, мерджить сегменты, менять количество реплик, изменять приоритет восстановления, делать индекс readonly, создавать снапшоты и, наконец, удалять индекс.

Теперь поговорим про отличия.

⚡️В OpenSearch типы узлов hot/warm/cold настраиваются как атрибуты узлов (то же самое, что и Shard Allocation Awareness в ElasticSearch). В Elasticsearch типы узлов hot/warm/cold настраиваются как роли узлов.

⚡️Elasticsearch ILM поставляется с фазами hot/warm/cold/delete, определенными из коробки. В Opensearch вам нужно создавать и называть фазы самостоятельно. Зато какой полет фантазии возможен: разогретая фаза, чуть подостывшая, замерзшая и далее по списку.

⚡️В Opensearch действия, состояния и переходы настраиваются вами самостоятельно в рамках ISM. В Elasticsearch предустановлены фазы и действий внутри каждой фазы.

⚡️Opensearch ISM поддерживает уведомления для каждого из фазовых переходов и ошибок. В Elasticsearch нельзя создавать уведомления из конфигурации ILM.

⚡️В ISM индексы назначаются непосредственно из политики, т.е. в политике хранятся индексы, которые будут ей аффектиться. В Elasticsearch сам индекс хранит политику, которой он управляется.

Если вы хотите подробнее узнать про настройки ISM в OpenSearch, рекомендуем ознакомиться с этой статьёй.

А какую технологию используете вы?

Пагинация в ElasticSearch поддерживается тремя разными способами: pagination, search-after и scroll.

Один из наших клиентов в своей системе поиска тендеров использует пагинацию. После того, как пользователь выполнил поиск в веб-интерфейсе и отобразились страницы с постраничными результатами, они заранее загружают следующую страницу. То есть, при нахождении на первой странице с результатами, при переходе на вторую страницу, она отображается мгновенно. Когда пользователь загружает вторую страницу, сразу же подгружается третья и так далее. Такой подход весьма улучшает UX. В этом посте рассмотрим все три вида пагинации и определимся с предназначением каждого типа.

Опубликовали статью на Хабре.

В ElasticSearch и OpenSearch могут храниться данные как в виде временных рядов с полем времени (например, логи приложений) так и без специального поля с указанием времени (например, каталог товаров интернет-магазина). Данные, которые содержат время, удобнее всего хранить в виде потоков данных (data streams). В этом посте на примере OpenSearch мы расскажем чем потоки данных отличаются от обычных индексов и когда их можно использовать.

Данные в виде временных рядов обладают следующими свойствами:
🔎 есть поле @timestamp и оно обязательное
🔎 документы не обновляются
🔎 документы делятся на индексы, основываясь на времени
🔎 поиск по старым документам менее вероятен, чем по новым

В OpenSearch для перемещения данных используется ISM (Index State Management). Эта технология позволяет определять политики для автоматизации перемещения данных между узлами или их удаления при определенных условиях. Таким образом, можно разделить данные по возрасту и определить их перемещение, например, с SSD-дисков на HDD-диски и, в конечном итоге, их удалить.

В этот момент в игру вступают потоки данных. Нужен какой-то способ указать ISM как разделить данные на индексы и это как раз он. Потоки данных используют шаблоны индексов. Для начала создадим шаблон индекса и определим поток данных:

PUT _index_template/logs-template
{
  "index_patterns": [
    "logs-*"
  ],
  "data_stream": {}
}

Выше мы определили, что все индексы, начинающиеся с logs будут потоками данных. Теперь запишем документ в индекс logs-messages

POST logs-messages/_doc
{
  "@timestamp": "2023-04-26T09:30:33.132+03:00",
  "message": "съешь ещё этих мягких французских булок да выпей чаю"
}

А теперь магия! Извлечем этот документ и увидим, что он оказался в потоке данных:

{
  "_index" : ".ds-logs-messages-000001",
  "_id" : "y0UApX0BzzHCVHV5VzYo",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

Что здесь произошло? Мы записали документ в поток данных, а Opensearch создал базовый индекс, в котором будут храниться записанные данные. Имя потока данных — это псевдоним. Можно даже не беспокоиться о том, какой индекс мы выполнили запись. Нужно просто выполнять запись в поток данных, настроить политику ISM, а OpenSearch сам разберется куда записать. Согласитесь, удобно.

Если ISM будет настроен выполнять перенос через день, то через 1 день появится индекс .ds-logs-messages-000002 и так далее. Обратите внимание, что индекс начинается с точки, это означает, что индекс скрыт. Не нужно взаимодействовать с индексом напрямую. Две следующие команды помогут извлечь полезную статистику по использованию потоков данных:

GET _data_stream/logs-messages
GET _data_stream/logs-messages/_stats

Искать в потоке данных тоже просто:

GET

logs-messages

/_search

Takeaway, как говорится:

🔎Потоки данных предназначены для неизменных данных, которые только дополняются
🔎Поле @timestamp обязательно
🔎Поисковые запросы выполняются по всем индексам в потоке, запросы на запись к последнему индексу
🔎Вам не нужно выбирать индекс, в который записывать, записывайте данные в поток

Ребята, накидайте, пожалуйста огней, если пост был вам полезен😊

Сколько шардов на ноду ок и сколько не ок — такой вопрос нам часто задают на обучении или в ходе проектов. Самый простой совет — 20 шардов на каждый Гб JVM Heap. В этом посте мы попытались разобраться что же в действительности утилизирует аппаратные ресурсы на ноде, когда мы говорим про овершардинг.

Каждый индекс и каждый шард требуют определенных ресурсов памяти и процессора. Небольшой набор крупных шардов использует меньше ресурсов, чем множество мелких шардов. Сегменты также играют большую роль в использовании ресурсов шарда. Большинство шардов содержат несколько сегментов, в которых хранятся данные. Elasticsearch хранит некоторые метаданные сегментов в JVM Heap, чтобы их можно было быстро извлечь при поиске. По мере роста шарда его сегменты объединяются в меньшее количество более крупных сегментов. Это уменьшает количество сегментов, а значит, меньше метаданных хранится в JVM Heap.

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

Ещё один момент состоит в том, что более крупные шарды дольше восстанавливаются после сбоя. Когда нода выходит из строя, Elasticsearch восстанавливает баланс между шардами. Этот процесс копирует содержимое шарда по сети, поэтому для восстановления шарда размером 100 ГБ потребуется в два раза больше времени, чем для шарда размером 50 ГБ. В отличие от этого, маленькие хранилища несут пропорционально больше накладных расходов и менее эффективны при поиске. Поиск в пятидесяти хранилищах размером 1 ГБ займет значительно больше ресурсов, чем поиск в одном хранилище размером 50 ГБ, содержащем те же данные. Важен баланс.

Не существует жестких ограничений на размер шарда, но опыт показывает, что для логов и данных временных рядов обычно подходят шарды размером от 10 до 50 ГБ. Вы можете определять размеры шардов в зависимости от ёмкости сети и условий использования. Если используете ILM, установите порог max_primary_shard_size действия rollover на 50 ГБ, чтобы избежать использования шардов размером более 50 ГБ. А чтобы узнать текущий размер шардов, используйте cat shards API.

Запомнить:

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

Удаляйте целые индексы
Elasticsearch может немедленно удалить удаленные индексы непосредственно из файловой системы и освободить ресурсы.

Используйте потоки данных и ILM для временных рядов данных
Потоки данных позволяют хранить данные временных рядов в нескольких индексах, основанных на времени. В рамках ILM можно настраивать размеры шардов.

Если тема вам интересна, рекомендуем пару статей к прочтению:

How many shards should I have in my Elasticsearch cluster? (блог Elastic)
Size your shards (документация Elastic)

Два интересных API для получения детальной информации по хранению данных

Field usage stats API — возвращает детальную информацию о полях документа для каждого шарда и индекса.

Analyze index disk usage API — анализирует использование диска каждым полем индекса или потока данных.

​Если вы планируете использовать или уже используете Elasticsearch в качестве поискового сервиса для вашего ecommerce-проекта, то статья о структуре о схеме документов вам определённо будет полезна. Здесь описан здравый подход по формированию вложенности полей в зависимости от цвета, размера и SKU товаров.

Если вы считаете, что ваш поиск работает медленно или у вас есть понимание необходимости его оптимизации — приходите к нам на консультацию (запрос можно отправить в телеграм @galssoftware или через форму обратной связи на сайте).

Используете Elasticsearch в качестве поискового движка?

Как понять, что с вашим поисковым запросом в ElasticSearch что-то не так? Правильный ответ — попробуйте профилирование запроса. Profile API дает низкоуровневое представление о том, как выполняются поисковые запросы, чтобы понять, почему определенные запросы выполняются медленно и как-то их улучшить. Profile API не измеряет сетевую задержку, время, затраченное на фазу выборки поискового запроса, время, затраченное на нахождение запросов в очереди или на объединение ответов шардов на координирующей ноде. Пример выполнения:

GET /products/_search
{
  "profile": true,
  "query" : {
    "match" : { "position" : "огурцы" }
  }
}

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

Помогало ли вам в работе профилирование поискового запроса?

​Векторный поиск, дополняющий полнотекстовый, помогает находить семантически схожие документы. В этой статье описано создание гибридного поиска, сочетающего в себе возможности полнотекстового и векторного поиска. Используемый стек состоит из OpenSearch и Sentence Transformers.

Статья для тех, кто хочет повысить релевантность поиска в своём проекте.

​❗️Вышел OpenSearch 2.7.0

В этом посте мы расскажем, что появилось нового. Ключевое — это переход из беты в GA* возможностей репликации сегментов и поиска по снэпшотам. В конце поста вы найдете ссылки на пост в блоге OpenSearch и заметки к релизу. Поехали!

*General Available — возможность использования фичи в продуктивных средах

🔎Поиск по снэпшотам

Такая возможность в качестве экспериментальной появлась в OpenSearch 2.4.0, а с текущей версии в GA. Снэпшоты с возможностью поиска позволяют выполнять поиск по индексам, которые хранятся в виде снэпшотов в удаленных репозиториях в режиме реального времени, без необходимости предварительно загружать набор проиндексированных данных в кластер. Кстати, в оригинальном Elastisearch такая функция входит в подписку Enterprise.

🔎Репликация сегментов

Эта функциональность также перешла в режим GA из экспериментальной (появилась начиная с версии 2.3). Репликация сегментов — это иная стратегия репликации данных в отличие от репликации документов. Репликация сегментов копирует файлы сегментов Lucene с основного шарда на реплики. Сегментная архитектура Lucene, основанная на принципе «запись только один раз», означает, что копировать нужно только новые сегменты, вместо того, чтобы дописывать новые документы в существующие шарды. Этот подход позволяет повысить производительность индексирования и снизить нагрузку на аппаратные ресурсы.

Визуализация данных из нескольких источников

Запущенная в качестве экспериментальной в OpenSearch 2.4.0, эта функция также перешла в режим GA и позволяет использовать несколько источников данных для OpenSearch Dashboards. Теперь можно динамически управлять источниками данных на нескольких кластерах OpenSearch, создавать шаблоны индексов на основе этих источников, запускать запросы к определенному источнику данных и объединять визуализации в единый дашборд.

🔎Мультитенантость в OS Dashboards

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

Анализ событий безопасности с помощью встроенных инструментов корреляции

Данные из логов, содержащие события безопасности, могут охватывать несколько индексов и потоков данных, а визуализация взаимосвязей между связанными событиями даст ценные сведения для аналитиков безопасности. Механизм корреляции позволяет определять взаимосвязи в данных о событиях безопасности из различных источников данных, таких как DNS, Netflow, Active Directory и др. Построенный граф можно использовать для определения закономерностей и исследования взаимосвязей между различными системами в контролируемой инфраструктуре.

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

🔍Статья с описанием релиза в блоге OpenSearch

🔍Заметки к релизу

🔍Загрузка новой версии OpenSearch

🔍Песочница OpenSearch

Какая у вас версия OpenSearch в продуктивной среде?

​Репликация сегментов в OpenSearch стала доступна для использования в продуктивных средах начиная с версии 2.7. Этот подход заключается не в подокументной индексации документов в реплики, а в копировании файлов сегментов полностью. В этой статье на Хабре рассказали немного подробнее об этом подходе.

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

Возможности:

🔍 Запуск эталонных тестов производительности и запись результатов

🔍 Настройка и отключение кластеров OpenSearch для проведения бенчмарков

🔍 Управление данными и спецификациями бенчмарков в разных версиях OpenSearch

🔍 Обнаружение проблем с производительностью путем подключения телеметрических устройств

🔍 Сравнение результатов производительности

🔍 Создание специализированных нагрузок