Привет, Хабр! Я Максим Чудинов, инженер команды мониторинга в Cloud.ru. Одно из направлений нашей работы — обеспечение сбора логов с элементов инфраструктуры компании и их длительного хранения. Логи у нас хранятся в кластерах — их много и становится всё больше. Запускать новые и расширять существующие нужно быстро. Поэтому я разработал решение по автоматизации развертывания стека OpenSearch на виртуальных машинах с Ubuntu 20.04. О нем и расскажу в статье.
Почему мы выбрали OpenSearch
Зачем понадобилась автоматизация и именно OpenSearch? В начале 2022 года в Cloud.ru было уже 18 кластеров Elasticsearch для хранения логов — об этом я подробно рассказывал на Big Monitoring Meetup 9. Все кластеры работали на устаревшей версии 7.9, а перейти на более свежую версию, по сумме обстоятельств, мы не могли. В качестве альтернативы выбрали OpenSearch 1.3, поскольку это полный open source и форк Elasticsearch 7.10 без серьезных отличий в работе.
Чтобы развернуть 18 однотипных кластеров OpenSearch сейчас, N-е количество в будущем и поддерживать их дальше, появилась задача автоматизировать деплой. При разработке нужно было учесть одно важное условие — описание конфигурации всех кластеров должно было храниться в одном месте, чтобы можно было разворачивать, обновлять и вносить изменения коммитом в одном репозитории.
Как форк, OpenSearch повторяет стек Elastic: кластер хранилища, фронтенд, коллектор. Для прода производитель рекомендует конфигурацию кластера от трех нод.
Ноды — это хранилище данных и основа стека. Также частью стека являются фронтенд — для удобного поиска по индексам, и коллекторы — при необходимости предобработки и работы в распределенной инфраструктуре.
События из журналов систем и оборудования отправляются в кластер и складываются в индексы. Индексы имеют один основной шард от нуля до нескольких его реплик. Количество реплик зависит от количества нод. Кластер сам распределяет шарды таким образом, чтобы на одной ноде в один момент времени не находились основной шард и его реплика. За счет этого обеспечивается надежность хранения, а шардирование ускоряет выполнение поисковых запросов.
Описание решения
Ansible де-факто уже давно стандартный инструмент автоматизации в IT. Так что я взял его и написал две роли с плейбуком — для настройки нод кластера роль opensearch, для фронтенда роль opensearch_dashboards. Плейбук и описание кластеров сделал в отдельном репозитории.
Основой для применения ролей служит инвентарь. Как пример, в нем перечислены хосты для двух кластеров:
Сами роли применяются к группам logsearch_node и logsearch_frontend, описанным в отдельном файле.
Группы mon_logsearch_os1_dev и mon_logsearch_os2_dev являются объединением хостов соответствующих кластеров. Для каждой группы в переменных group_vars задаются специфичные для кластера значения. Также группы можно использовать для работы с отдельным кластером при выполнении плейбука с ключом –limit. Группа logsearch_logstash заложена на перспективу использования инвентаря для развертывания коллектора logstash. Вы можете развернуть в своей среде желаемые кластеры, указав соответствующие имена и адреса хостов.
Конфигурация, хотя и предполагается к применению в закрытом контуре, должна быть безопасной. Поэтому между элементами кластера устанавливаются SSL-соединения. Для них нужны предварительно сгенерированные сертификаты безопасности. О том, как самому сгенерировать сертификаты, подробно описано в документации Opensearch.
Сертификаты я вынес в групповые переменные и в будущем планирую перенести их в корпоративный Vault.
Для каждого кластера по умолчанию используются сертификаты из общих переменных. По желанию их можно переопределить в описании кластера в словаре clusters. Словарь содержит параметры всех разворачиваемых кластеров.
Кроме сертификатов для каждого кластера указываются дистрибутив, имя кластера, имя и пароль административной учетной записи, имя и пароль учетной записи для подключения фронтенда к кластеру и т. д. Пароли заданы в открытом виде для примера. В своей инфраструктуре я указываю пароли в зашифрованном с помощью ansible_vault виде. В планах заменить шифрование на хранение в корпоративном Vault, как и сертификаты.
Куски для конфигурационных файлов internal_users.yml и roles_mapping.yml описаны в виде plain text и используются в шаблонах «как есть». В internal_users указаны дефолтные пользователи из коробочной установки, их можно полностью заменить на свои предпочтения. К сожалению, прекрасный способ настройки пользователей через API появился только в последних релизах второй версии Opensearch. Из-за этого потребуется предварительно где-то выполнить установку пакета opensearch или вытащить из tar-архива opensearch скрипты plugins/opensearch-security/tools, чтобы по этой инструкции сгенерировать hash пароля для каждого пользователя.
А дальше магия Gitlab CI/CD 😀. При merge в основную ветку запускается ansible docker container. В нём выкачиваются зависимости согласно requirements.yml и выполняется плейбук от имени пользователя из переменной ${SSH_USER} с ключом из переменной ${SSH_PRIVATE_KEY}. Переменные определяются в CI/CD Settings проекта.
Сначала применяется роль opensearch к хостам группы logsearch_node. Выполняется тюнинг системных параметров целевого хоста (согласно рекомендациям разработчика), установка и настройка opensearch на целевом хосте.
Первым таском установки выполняется скачивание дистрибутива в директорию /tmp целевого хоста. Это действие пришлось добавить после ситуации, когда модуль apt не смог выполнить установку из указанного url по причине таймаута. Площадки размещения бывают разные и не всегда с хорошими каналами связи. Поэтому сначала скачивание с помощью get_url, а затем локальная установка.
Затем создаются директории для индексов и снапшотов и из шаблонов копируются конфигурационные файлы. Файлы с демосертификатами удаляются и из шаблонов копируются сертификаты, заданные в переменных описания кластера. Размер java heap автоматически вычисляется как половина от фактической памяти хоста (но не более 30 ГБ) и записывается в jvm.options. Затем ждет 10 секунд для запуска сервиса и удаляет из конфигурационного файла строку с указанием хостов для выбора мастер-ноды. Этот перечень нужен только один раз для процесса cluster bootstrapping и в дальнейшей жизни кластера не пригодится. Еще при первом запуске кластер сам инициализирует внутренних пользователей и роли, используя конфигурацию плагина безопасности.
Вторым этапом применяется роль opensearch_dashboards к хостам группы logsearch_frontend. Аналогично предыдущей роли выполняется тюнинг системных параметров целевого хоста согласно рекомендациям разработчика, установка и настройка opensearch-dashboards на целевом хосте. Так же и по тем же причинам, что и в роли opensearch, первым таском установки выполняется скачивание дистрибутива в директорию /tmp целевого хоста и затем локальная установка. После из шаблонов копируются конфигурационные файлы и сертификаты.
В ролях я предусмотрел тестирование с помощью molecule. Пока ручное 😀. При этом разворачиваются три ноды, кластер инициализируется дефолтными параметрами, проверяется возможность авторизации и возврат статуса. Аналогично для фронтенда: всё запускается в контейнерах, а если не выполнять шаг destroy, то можно получить полноценную инсталляцию, походить по интерфейсу и попробовать настройки.
Из-за отсутствия DNS в некоторых сегментах инфраструктуры в инвентаре мы используем параметр ansible_host с IP-адресом. С molecule в контейнерах такой возможности нет — адреса выдаются произвольно и сетевой доступ выполняется по именам. А мне для конфигурации каждой ноды нужно было собрать массив IP-адресов всех нод.
Чтобы роли работали и в тесте, и на виртуальных машинах, я написал код с формированием списка хостов в зависимости от значения ansible_host. Нативными командами ansible реализовать не получилось, поэтому я написал код на jinja2.
Если все переменные заданы правильно, то плейбук выполняется без ошибок и мы получаем рабочий кластер. Или набор рабочих кластеров, описанных в словаре clusters.
По факту Opensearch — это стабильный готовый продукт. Вывести его из строя может только падение операционной системы или несоблюдение рекомендаций разработчиков. Но эта стабильность не отменяет обязательного мониторинга.
Мониторинг
Я определил несколько ключевых метрик (SLI) для верхнеуровневого мониторинга состояния кластера:
Health status — доступность кластера и его способность принимать новые данные;
Indexing rate — скорость поступления событий;
Indexing latency — задержка записи событий;
Storage utilization — величина использования хранилища кластера;
Product Index size — размер индексов каждого продукта источника;
Estimated time to 15% free space — прогнозное время до достижения 15% остатка хранилища.
Для сбора метрик я использовал Zabbix и коробочный шаблон Elasticsearch, немного доработанный для целей capaсity management. Метрики собираются штатным образом через Elastisearch API. Дополнительно выполняется поиск индексов и вычисление занимаемого места на диске (через группировку по алиасу) — Product Index size. Продукт включает в себя множество источников событий, и каждый в любой момент может значительно увеличить количество генерируемых событий. Например, корпоративный кластер Confluence, Gitlab или кластер K8s для облачных сервисов.
Мы не применяем жестких ограничений и не фильтруем события — так можно потерять действительно важные данные. Что отправить в хранилище кластера — решает команда каждого продукта. Обычно отправляют всё😀. События от каждого продукта я направляю в отдельный индекс.
Поскольку хранилище не бесконечное, важно отслеживать, какой продукт и сколько места занимает. Теперь через метрику Product Index size у меня есть Logging budget: можно сразу увидеть сколько места в байтах занимают события того или иного продукта и при резком росте значения сразу понятно, в какую команду идти за разъяснениями.
Еще я добавил в шаблон метрику Estimated time, которая через прогнозную функцию timeleft вычисляет, сколько времени остается до 15% свободного места в кластере. Такой прогноз позволяет проактивно в рабочем порядке расширить кластер.
Если не мешают обстоятельства, то мои метрики оказываются в коробочном шаблоне Zabbix.
Визуализацию я настроил средствами Grafana — во-первых, потому что Grafana основной рабочий инструмент дежурной смены. Во-вторых, потому что метрики разных кластеров снимаются разными инстансами Zabbix.
С помощью разных источников данных и шаблонных наименований хостов naming convention у меня получилось сделать один динамический шаблон, который отображает SLI по каждому кластеру. Кластер выбирается из выпадающего списка. Дашборд не требует изменений при добавлении или удалении кластера.
Выводы
Автоматизация — это здорово! Теперь с помощью плейбука я могу развернуть несколько кластеров в течение часа. И большую часть времени займет заполнение инвентаря и всех нужных переменных. Добавление нод в кластер — дело 10 минут. Внедренное решение сильно сократило время на деплой, а также привело конфигурацию всех кластеров к одному виду. Единообразие сильно сокращает временные затраты на траблшутинг.
Реализация деплоя через CI/CD принесла пользу команде. Раньше только я знал все нюансы установки и мог развернуть кластер. Теперь добавив описание нового кластера в переменных и выполнив merge request это может сделать каждый.
Конечно, роли не идеальны. К ним хотелось бы добавить валидацию переменных, автогенерацию документации и установку под другие операционные системы. Будем считать это домашним заданием😀.
В планах на будущее: перенести все секреты и сертификаты в Vault, разработать и подключить роль logstash, собрать логи всех кластеров в один индекс и настроить предупреждения по аварийным событиям. Также предстоит договориться с командами разработки внутренних продуктов о формате событий приложений (contract), чтобы избежать ошибок несовпадения типов данных при индексировании.
Интересное в блоге:
Как внедрить двухфакторную аутентификацию в веб-приложения, не предусматривающие ее изначально
Бороздим облака будущего: впечатления айтишника о конференции GoCloud
Как разработать браузерное расширение в Chrome на React: разбираем на примере Cloudhood
