elasticstack_ru | Unsorted

Telegram-канал elasticstack_ru - Elastic Stack recipes

-

Полезности по Elastic Stack. Для тех, кто работает с ElasticSearch, Kibana, Logstash или Beats. Тут вы увидите статьи, видео, анонсы мероприятий, новости. Платные консультации, администрирование, поддержка, обучение и лицензии Elastic — @galssoftware

Subscribe to a channel

Elastic Stack recipes

В 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 обязательно
🔎Поисковые запросы выполняются по всем индексам в потоке, запросы на запись к последнему индексу
🔎Вам не нужно выбирать индекс, в который записывать, записывайте данные в поток

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

Читать полностью…

Elastic Stack recipes

Если вы решили мигрировать из 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, рекомендуем ознакомиться с этой статьёй.

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

Читать полностью…

Elastic Stack recipes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать полностью…

Elastic Stack recipes

vakhtang-matskeplishvili/elasticsearch-how-to-decrease-the-reindex-time-by-more-than-90-and-simplify-reindex-process-901488851417">Elasticsearch reindex - How to decrease the reindex time by more than 90% and simplify reindex process

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

Читать полностью…

Elastic Stack recipes

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

Читать полностью…

Elastic Stack recipes

How to Upgrade Elasticsearch from Version 7 to Version 8

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

Читать полностью…

Elastic Stack recipes

Данные Elasticsearch-сервера оператора связи «Авантелеком», включая логи общения с клиентами, оказались открыты всем

В комментариях компания пишет, что это был взлом, однако, часто бывает, что кластер Elasticsearch начинает быть открытым всему интернету просто по недосмотру. У нас уже был пост про безопасность Elasticsearch в docker-контейнера. Обратите пристальное внимание на особенность работы Docker с iptables.

Читать полностью…

Elastic Stack recipes

Задачи миграции индексов между кластерами достаточно часто встают перед администраторами Elasticsearch. t-velmachos/how-to-migrate-indices-from-elasticsearch-wth-minio-438854d027b5">В этой статье на Медиуме разобрана миграция кластера при помощи утилит elasticsearch-dump, Minio и хранилища S3.

Читать полностью…

Elastic Stack recipes

Если вы используете Elastic в качестве SIEM-системы, обратите внимание на процессор translate_sid для Winlogbeat. Процессор извлекает имя учетной записи, связанной с SID, первый домен, в котором найден SID и тип учетной записи.

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

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

Читать полностью…

Elastic Stack recipes

KushanJanith/run-elastic-stack-on-kubernetes-29e295cd6531">Run Elastic Stack on Kubernetes

Это руководство по развертыванию стека Elastic на Kubernetes. В этом руководстве используется оператор ECK для создания всех связанных с Elastic ресурсов на Kubernetes.

Читать полностью…

Elastic Stack recipes

Исследование нагрузки на ELK stack и тюнинг Logstash. В этой статье автор расскажет про то, как столкнувшись с многократно увеличившейся нагрузкой на ELK stack сначала было диагностировано узкое место, а после произведён его тюнинг. Хоть и в заголовке статьи уже есть спойлер что произведен только тюнинг Logstash, но тем не менее. Читать.

Читать полностью…

Elastic Stack recipes

Wazuh-Rules. Репозиторий на Гитхабе с правилами для Wazuh, которые можно взять и использовать в Elasticsearch. Ознакомиться.

Читать полностью…

Elastic Stack recipes

Elasticsearch in Action: Loading PDFs into Elasticsearch

Допустим, есть бизнес-задача — загрузить PDF-файлы в Elasticsearch, чтобы пользователи могли проводить по ним поиск. Elasticsearch позволяет индексировать PDF-файлы с помощью специального процессора, называемого процессором attachment.

Процессор attachment, как и любой другой процессор ingest, используется в ingest-пайпланах для загрузки вложений - таких как PDF-файлы, документы Word, электронные письма и так далее. Он использует библиотеку Tika (https://tika.apache.org) от Apache для извлечения данных из файла. Ожидается, что исходные данные будут преобразованы в формат base64 перед загрузкой в конвейер. В статье вы узнате как реализовать процесс от и до. Читать.

Читать полностью…

Elastic Stack recipes

Airflow Log Integration with Fluent Bit + ELK Stack (Kubernetes). Вы можете спросить: а зачем мне это? Ключевое — можно удалить персистентность логов из подсистем airflow и обеспечить безопасное хранение критически важных логов ну и плюшки в виде аналитики/визуализаций в Kibane никто не отменял. dulshanr12/airflow-log-integration-with-fluent-bit-elk-stack-kubernetes-f2afa3a6ff00">Читать.

Читать полностью…

Elastic Stack recipes

Единственный нативный и бесплатный способ отправки оповещений из Elasticsearch — использование Kibana Alerts. Но у Kibana Alerts в лицензии Basic есть существенный минус — возможность отправки (если это можно назвать отправкой) алертов в индекс или текстовый лог, чтобы потом оттуда их чем-то выгребать. Наверное, это можно делать через Zabbix.

Если же нет желания использовать описанную выше конструкцию, на помощь может прийти ElastAlert — бесплатная оповещалка с открытым исходным кодом. trivedevops/creating-custom-alerts-with-elk-and-elastalert-integration-5e44984ca8d8">В этой статье описан небольшой воркшоп по его использованию.

Читать полностью…

Elastic Stack recipes

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

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

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

Читать полностью…

Elastic Stack recipes

Поле 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 в ваших индексах?

Читать полностью…

Elastic Stack recipes

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать полностью…

Elastic Stack recipes

juliardifh49/paginate-your-search-result-with-elasticsearch-and-go-94924f1bba2d">Paginate Your Search Result with Elasticsearch and Go

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

Читать полностью…

Elastic Stack recipes

What are the best Elasticsearch GUI clients?

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

Читать полностью…

Elastic Stack recipes

karkoubelwali/test-logstash-pipelines-filters-before-implementation-3015f9be15ec">Test Logstash Pipelines/Filters before Implementation

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

Читать полностью…

Elastic Stack recipes

Что нового в OpenSearch 2.6

28 февраля вышла новая минорная версия OpenSearch. Давайте посмотрим какие обновления она получила.

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

⚡️При создании детекций угроз в OpenSearch 2.6.0 теперь можно использовать несколько индексов или шаблонов индексов для построения детекции, а не только один индекс. Пять новых интеграций доступны для обнаружения угроз, теперь их общее количество достигло 13. Новые интеграции включают в себя Google Workspace, GitHub Actions, логи Microsoft 365, события Okta и логи Microsoft Azure. Кроме того, многие типы детекций теперь включают готовые панели, предназначенные для визуализации логов, которые они отслеживают.

⚡️Версия 2.6.0 включает новую панель здоровья ML-моделей в качестве экспериментальной функции, позволяющей просматривать местоположение и состояние ML-моделей в кластере.

⚡️Появились карты в OpenSearch Dashboards. Ранее карты можно было создавать и отображать только в плагине Maps; теперь вы можете получить доступ к картам для визуализации и анализа, не выходя из Dashboards.

⚡️OpenSearch 2.6.0 поддерживает OpenSearch Reporting CLI. Новый CLI предоставляет готовый способ программно генерировать и загружать отчеты непосредственно из OpenSearch Dashboards. Можно использовать Reporting CLI для создания отчетов в формате PDF, PNG или CSV и распространения их в виде файла в системах передачи сообщений.

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

Подробнее об обновления можно узнать в блоге OpenSearch.

Читать полностью…

Elastic Stack recipes

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

Читать полностью…

Elastic Stack recipes

Elastic SIEM fleet server implementation

Fleet Server, который отвечает за управление Elastic-агентами на хостах, является одним из основных элементов Elastic SIEM. В этой статье рассказано о том как устроен и какими возможностями обладает Fleet Server для Elastic SIEM.

Читать полностью…

Elastic Stack recipes

Overview of Syslog Parsing with Fluentd

Syslog - это широко используемый метод сбора и хранения данных. Это стандарт, который поддерживается многими приложениями и платформами. В этой статье рассмотрены основы разбора syslog с помощью Fluentd.

Читать полностью…

Elastic Stack recipes

Capacity planning an Elasticsearch Cluster — 8.6.1. Несколько картинок для расчёта сайзинга кластера. И понимания как это делать. Смотреть.

Читать полностью…

Elastic Stack recipes

1-3 марта проведем 3-дневный вводный курс по работе с Elastic Stack.

Мы добавили в курс разделы с конвертированием SQL в DSL, нагрузочное тестирование кластера Elastic при помощи утилиты Rally и SIEM.

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

Курс — это как ракета-носитель, которая за 3 дня выведет вас на заданную орбиту. Вы сможете сразу приступить к работе вместо долгого изучения документации по каждому из компонентов Elastic Stack.

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

Читать полностью…

Elastic Stack recipes

Родители и дети. Связываем документы в Elasticsearch. Статья об использовании непопулярного архитектурного решения — join field type. Может вам пригодиться, если считаете, что обновлять весь документ из-за изменения пары полей — ту мач. Важно учитывать, что родительские и дочерние документы должны находиться в одном шарде, что может отразиться в дальнейшем на масштабировании. Читать.

Читать полностью…

Elastic Stack recipes

Vector: руководство по уходу за граблями. Если уже используете или собираетесь использовать в качестве шиппера Vector вместе с OpenSearch/Elasticsearch, нужно обязательно прочитать эту статью на Хабре.

Читать полностью…

Elastic Stack recipes

Одно из ключевых предназначений Elastic — использование в качестве SIEM системы. В связи с этим возникает необходимость настройки детекций, которые бы оповещали о подозрительной активности. По этой ссылке вы найдете список сетевых портов, которые могут быть использованы при атаке при помощи троянского зловреда. Список можно использовать для ваших детекций.

Читать полностью…
Subscribe to a channel