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

Привет, коллеги! Я Дарья Санькова, эксперт направления инфраструктурного мониторинга в Cloud.ru. Сегодня хочу поделиться нашим опытом перехода с Elasticsearch на OpenSearch для работы с логами. Расскажу, почему мы решили это сделать, какие ключевые отличия между системами мы нашли, несмотря на их принципиальное сходство, и подробно опишу нашу архитектуру обработки логов.

Почему мы решили перейти на OpenSearch 

Как многие знают, долгое время Elasticsearch был одним из ведущих инструментов для индексирования, поиска и анализа данных. Мы активно использовали его в наших проектах, особенно для работы с большими объемами логов в реальном времени.

В январе 2021 года компания Elastic изменила лицензию Elasticsearch и перешла с открытой Apache 2.0 на двойную лицензию SSPL и Elastic License 2.0 (ELv2). Новость взволновала многие компании, включая нашу, ведь такие изменения не сулили ничего, кроме потенциальных ограничений и юридических рисков. 

Однако вскоре Amazon Web Services (AWS) объявила о создании OpenSearch — форке Elasticsearch и Kibana. Он сохранил ключевые возможности обеих систем и выходит под лицензией Apache 2.0. Кроме того, проект передали под управление Linux Foundation, что гарантирует независимое развитие и поддержку со стороны сообщества. 

Пожалуй, основные причины, почему мы решили переходить на OpenSearch очевидны, но все же перечислю то, что было особенно важно для нас:  

• Лицензия Apache 2.0 — мы могли продолжать использовать открытую лицензию без юридических рисков и ограничений.

• Контроль над системой — OpenSearch позволяет вносить изменения в код и адаптировать систему под наши потребности.

• Функции безопасности — на новом движке они оставались бесплатными.

• Активное сообщество — под эгидой Linux Foundation движок будет активно развиваться, а также поддерживаться в актуальном состоянии со стороны сообщества.

Поскольку OpenSearch основан на Elasticsearch версии 7.10, мы понимали — основные его функции и возможности будут идентичны. Но также нам было важно понять, есть ли между ними существенные различия. Это позволило бы с минимальными усилиями мигрировать на новую платформу и сохранить привычную функциональность.

Сравниваем Elasticsearch и OpenSearch

В итоге мы изучили Elasticsearch и OpenSearch вдоль и поперек и решили структурировать наши знания.

Какие есть отличия: смотрим на базовые критерии

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

В чем сходство: сравниваем работу с логами

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

Расскажу подробнее, что происходит на каждом из этапов:

1. Передача логов:

• данные поступают в Logstash через настроенные порты;

• затем эти порты назначаются для различных типов данных: устройств, агентов, продуктов и других.

2. Обработка логов:

• Logstash преобразовывает и фильтрует данные в соответствии с правилами;

• каждый пайплайн обрабатывает только соответствующие данные с помощью подключаемых модулей.

3. Отправка данных в Opensearch:

• логи отправляются в кластер в формате JSON-документов;

• данные индексируются и становятся доступными для поиска и анализа.

4. Хранение логов: используется архитектура Hot-Warm-Cold для оптимизации скорости доступа и хранения данных. Горячие ноды — для новых данных, теплые и холодные — для старых данных.

5. Передача данных для визуализации: 

• OpenSearch Dashboards ищет данные по индексам и логам с помощью запросов;

• затем передает эти данные пользователю — для изучения и анализа.

Как работаем с логами мы

Как схема выше работает на каждом из этапов у нас? Расскажу поподробнее.

Прием логов

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

Обработка логов

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

Хранение логов

События хранятся в индексах. Индексы ротируются, хранятся и мигрируют по нодам hot-warm-cold согласно следующим политикам:

• 2 недели,

• 1 месяц,

• 3 месяца,

• 6 месяцев,

• 12 месяцев.

Ротация выполняется при выполнении одного из условий:

• Размер индекса 30 ГБ.

• Возраст индекса 7 дней.

Затем индекс находится на hot-нодах две недели от даты создания и на 15-й день удаляется, если ему назначена политика «‎2 недели». Индексы с хранением больше двух недель по истечении 15 дней от даты создания перемещаются на warm-ноды. По политикам «1 месяц» и «3 месяца» индексы удаляются на 31-й и 91-й день от даты создания. Индексы с хранением больше трех месяцев на 93-й день от даты создания перемещаются на cold-ноды. По политикам «6 месяцев» и «12 месяцев» индексы удаляются на 184-й и 367-й день от даты создания. Если индекс не соответствует ни одной из предусмотренных политик хранения, могут потребоваться другие действия. Для наглядности показали весь процесс на схеме ниже:

Делимся нашей архитектурой системы логирования

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

Нашу мультирегиональную схему хранения и обработки логов мы создавали еще на стеке ELK, но затем благополучно перенесли ее в OpenSearch Stack. Чтобы не перегружать пример, мы показали только два региона с использованием георезервирования для повышения надежности:

Какие особенности есть в нашей схеме:

• Поды с Logstash — для сбора и отправка данных в региональные кластеры Opensearch.

• Сервисы визуализации (Opensearch Dashboards) — чтобы передавать данные из кластеров для анализа и визуализации.

• Георезерв — дополнительный уровень надежности, который организован через репликацию данных.

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

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

• Мастер-узлы — несколько узлов для обеспечения отказоустойчивости.

• Шардирование данных — разделение индексов на шардированные части для повышения производительности.

• Репликацию — механизмы репликации для защиты данных в случае сбоев.

Теперь расскажу подробнее, как устроены и работают регионы.

Регион №1

В первом регионе находятся два пода:

1. Под №1 включает:

• Logstash 1A: собирает данные логов от устройств и приложений первого региона.

• OpenSearch 1A: индексирует и хранит данные, полученные от Logstash 1A.

2. Под №2 включает:

• Logstash 1B: собирает данные логов от других сервисов или в качестве резервного экземпляра для Logstash 1A.

• OpenSearch 1B: индексирует и хранит данные, полученные от Logstash 1B.

• OpenSearch Dashboards 1: используется для поиска по данным из OpenSearch 1A и OpenSearch 1B. Он позволяет пользователям региона №1 выполнять запросы и анализировать логи.

Для повышения надежности и отказоустойчивости у региона №1 есть георезерв:

• Logstash Geo 1A: собирает копии данных и отправляет их в георезерв.

• OpenSearch Geo 1A: хранит реплицированные данные из OpenSearch 1A и OpenSearch 1B.

• Dashboards Георезерв №1: используется для поиска по данным в случае недоступности основного кластера.

Репликация данных: данные из OpenSearch 1A и OpenSearch 1B автоматически реплицируются в OpenSearch Geo 1A. Это обеспечивает дополнительный уровень надежности и безопасности данных.

Регион №2

Во втором регионе также находятся два пода:

1. Под №3 включает:

• Logstash 2A: собирает данные логов от устройств и приложений второго региона.

• OpenSearch 2A: индексирует и хранит данные, полученные от Logstash 2A.

2. Под №4 включает:

• Logstash 2B: собирает данные логов от других сервисов или в качестве резервного экземпляра для Logstash 2A.

• OpenSearch 2B: индексирует и хранит данные, полученные от Logstash 2B.

• OpenSearch Dashboards 2: используется для поиска по данным из OpenSearch 2A и OpenSearch 2B. Это позволяет пользователям региона №2 выполнять запросы и анализировать логи.

Для повышения надежности у региона №2 также есть георезерв:

• Logstash Geo 2A: собирает копии данных и отправляет их в георезерв.

• OpenSearch Geo 2A: хранит реплицированные данные из OpenSearch 2A и OpenSearch 2B.

• Dashboards Георезерв №2: используется для поиска по данным в случае недоступности основного кластера.

Репликация данных: данные из OpenSearch 2A и OpenSearch 2B автоматически реплицируются в OpenSearch Geo 2A.

Центральный кросс-кластер:

• Центральный OpenSearch: управляет всеми региональными и георезервными кластерами, обеспечивая централизованное управление данными и настройками кластеров.

• Центральные OpenSearch Dashboards: используются для поиска по всем собранным данным из регионов и георезервов. Предоставляют единую точку доступа для анализа и мониторинга всей системы.

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

• Отказоустойчивость: в случае сбоя в основном регионе (например, из-за технических проблем или природных катастроф), георезерв обеспечивает непрерывную работу сервисов и доступность данных.

• Бэкап и восстановление: служит дополнительным уровнем защиты, снижая риск потери данных и обеспечивает возможность быстрого восстановления в случае критических сбоев.

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

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

Заключение

Благодаря переходу на OpenSearch мы сохранили все преимущества Elasticsearch и при этом устранили ограничения и риски, связанные с лицензированием. Мы получили:

• Полный контроль над системой — возможность модифицировать и расширять функционал под наши потребности без ограничений.

• Экономию на лицензиях — все функции, включая расширенные функции безопасности, доступны бесплатно.

• Соответствие требованиям — возможность адаптировать систему под российские стандарты безопасности и хранения данных без ограничений.

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