Как стать автором
Обновить

Переезд с Elasticsearch на OpenSearch: рассказываем про нюансы и архитектуру нашей системы логирования

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров12K
Всего голосов 10: ↑10 и ↓0+13
Комментарии14

Комментарии 14

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

Привет! Рекомендую обратить внимание на статью Запускаем кластер OpenSearch для централизованного хранения логов. Там как раз мой коллега подробно описал процесс настройки и конфигурирования кластеров OpenSearch, включая особенности работы с Logstash и OpenSearch Dashboards, и показал примеры конфигурационных файлов. Данная статья дополняет и объясняет некоторые теоретические моменты, которые не были там затронуты :)

Или можно сразу залезть в репозиторий - https://gitlab.com/max-ch-88/opensearch_cluster

оу, биг спс. видно пропустил в потоке нейровбросов)

Инструкция - как на пустом месте создать себе сильного конкурента и потом вернуть все, как было, но теперь уже в мире, где он есть.

Они поменяли лицензию, т.к. им не давало покоя, что Амазон бесплатно пользуется для заработка денег и их можно понять

Понять то можно. Но почему не просчитали довольно очевидный результат?

Психанули, в топах тоже люди:) Вон с Вордпрессом аналогичная история, но там хоть лицензию не меняли

Самая классическа история этого типа - отзыв у Linux лицензии на BitKeeper, который привел к созданию GIT и смерти BitKeeper.

Расширенные функции безопасности не входят в бесплатную версию, их добавлял плагин от амазона, которого теперь нет, зато есть целый продукт от амазона :)

Ну и для того, чтобы осуществлять обратный переход нужно что-то большее, чем "мы передумали, возвращайтес!"

Спасибо за статью.
Мы год назад перешли на Open Search и конечн опокушали много кактусов.
Интересно почему мы выбрали Logstash, а не FluentBit/DataPreper?
И как вы в своем решении решаете проблему того что в индекс может прилетать одно и тоже поле с разным типом данных?
Ну и на десерт я бы посмотрел на то как вы описали кодом создание ISM, index patters, Snapshot policy и т.п?

Привет! Спасибо за интерес к материалу и классные вопросы)

Отвечу по порядку:
1. Почему мы выбрали Logstash, а не FluentBit/Data Prepper?

  • Существующая инфраструктура: На момент перехода у нас уже была настроена система на основе Logstash. Это позволило быстро мигрировать на OpenSearch без существенных изменений.

  • Гибкость обработки данных: Logstash обладает широкими возможностями по преобразованию и обогащению данных благодаря разнообразию фильтров и плагинов. Это важно для нас, так как работаем с разными типами логов и требуется сложная обработка.

  • Совместимость: Logstash хорошо интегрируется с OpenSearch, мы не столкнулись с проблемами при использовании.

2. Как мы решаем проблему разных типов данных в одном поле?

Честно говоря, это наша боль 😊 Пока "серебряная пуля" не найдена. То, что делаем сейчас:

  • Договорённости с источниками данных: Стараемся стандартизировать форматы логов и согласовывать их с командами, отправляющими данные.

  • Обработка на уровне кластера: Планируем использовать ingest pipelines в OpenSearch для преобразования данных при индексации.

На текущий момент всё ещё работаем над этим вопросом и надеемся внедрить более надёжное решение в будущем. С моим коллегой Сергеем Лацыгиным и нашим архитектором обсуждаем high-availability решение с кафкой и соглашением про логи.

3. Как мы описываем кодом создание ISM, index patterns, Snapshot policy и т.п.?

В рамках подхода IaC используется API OpenSearch для автоматизации:

  • ISM (Index State Management): Создаём политики через API, описывая их в JSON и применяя к индексам с помощью шаблонов.

  • Index Patterns: Хотя OpenSearch Dashboards не имеет полного API для управления index patterns, мы автоматизируем их создание с помощью скриптов или инструментов конфигурации.

  • Snapshot Policy: Настраиваем репозитории и политики снапшотов через API, обеспечивая регулярное резервное копирование.

Обсужу этот момент с коллегами - возможно созреем для статьи про снапшоты и политики индексов :)

Эх, вообщем все плюс минус тоже самое.
Для хоть какого то контроля IaC, те части что не поддерживаются через API, мы дергаем террагрантом используя модуль который в свою очередь дергает скрипты.
Мы так же в процессе изучения решения с кафкой, но вот с соглашением по логам пожалуй самая сложная часть.
Я иногда думаю что надо было внедрять Loki со статическим мапингом и не париться с типами данный, просто все что не попадает под шаблон режектить.
Спасибо за развернутый ответ.

Упрощённая opensearch по спецификациям.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий