Самомониторинг
Самомониторинг - это модуль, включающий в себя набор дашбордов для централизованного контроля состояния кластера. Он позволяет своевременно выявлять и устранять отклонения в работе кластера и слоя сбора данных до возникновения сбоев.
Условные обозначения
SM_INSTALLER- директория, куда разархивируется установочный пакетSmart MonitorUSER- пользователь системы с правами администратора, обычно этоadminOS_HOME- домашняя директория OpenSearch, обычно это/app/opensearch/OSD_HOME- домашняя директория OpenSearch Dashboards, обычно это/app/opensearch-dashboards/LOGSTASH_HOME- домашняя директория Logstash, обычно это/app/logstash/SBM_HOME- домашняя директория Smart Beat Manager, обычно это/app/smartBeatManager/SB_HOME- домашняя директория Smart Beat, обычно это/app/smartBeat/
Полезные ссылки
- Установка SM Master Node
- Установка SM Data Storage
- Установка SM Data Collector
- Установка Smart Beat Manager (SBM)
- Установка Smart Beat для Linux
- Настройка Cross Cluster Search
Использование самомониторинга
Он представляет собой набор дашбордов, которые отображают различные значимые метрики целевого (отслеживаемого) кластера, позволяя оперативно реагировать на любые изменения и проблемы.
Отслеживаемыми компонентами являются:
- SM Data Storage: для мониторинга всех процессов, связанных с функционированием кластера
- SM Data Collector: для мониторинга поступления событий и корректности их сбора
- SM Master Node: для мониторинга состояния управляющих компонентов и координации работы кластера
Архитектура
При развертывании самомониторинга могут использоваться два различных типа архитектуры:
- развертывание на отдельно
выделенный кластер - развертывание внутри
целевого кластера
Целевой кластер - кластер для которого настраивается мониторинг метрик.
Архитектура I типа (Выделенный кластер)
Рекомендуется размещать все компоненты сервера самомониторинга на одном узле, особенно для небольших и средних по размеру решений — это упрощает развертывание и сопровождение.
Минимальные характеристики сервера самомониторинга:
-
CPU: от 4 ядер
-
RAM: от 16 ГБ
-
Диск: от 100 ГБ
Размер хранилища зависит от объема собираемых данных, количества отслеживаемых кластеров и периода хранения информации. При необходимости параметр может быть увеличен.
При первом типе архитектуры сервер самомониторинга - полноценный изолированный кластер, который включает в себя следующие компоненты:
- SM Data Storage - отвечает за хранение и полнотекстовый поиск собранных данных
- SM Dashboards - для визуализаций на основе собранных данных
- SM Data Collector - для получения данных от агентов целевого кластера и его опроса по REST API
- SmartBeatManager - для управления агентами, установленных на целевом кластере
Преимущества
Когда сервер самомониторинга развернут на отдельном выделенном кластере, это позволяет достичь нескольких важных преимуществ:
-
Доступность в случае сбоя целевого кластера
- Поскольку сервер самомониторинга работает независимо от целевого кластера, он остается доступным для обращения даже в случае, если целевой кластер перестанет функционировать по каким-либо причинам
-
Разгрузка ресурсов целевого кластера
- Отдельное размещение сервера самомониторинга исключает нагрузку на ресурсы целевого кластера. Это особенно актуально, поскольку процессы сбора метрик и мониторинга сами по себе ресурсоемкие. Разделение инфраструктуры помогает избежать конкуренции за ресурсы и обеспечивает стабильную работу основного кластера
Недостатки
Несмотря на то, что схема с выносом сервера самомониторинга на отдельный кластер рекомендуется по умолчанию, она все же имеет ряд особенностей, которые следует учитывать:
-
Дополнительные ресурсы для инфраструктуры
- Для развертывания отдельного кластера потребуется выделенный сервер или дополнительные вычислительные мощности. Это требует больше ресурсов и может привести к дополнительным расходам
-
Более сложная настройка и сопровождение
- Для получения данных о самомониторинге с целевого кластера необходимо настроить механизм
cross-cluster search(информацию по настройке можно найти в разделе полезные ссылки). Это добавляет шаги в процессе конфигурации и требует отдельного внимания при сопровождении системы
- Для получения данных о самомониторинге с целевого кластера необходимо настроить механизм
Архитектура II типа (Основной кластер)
При втором типе архитектуры, все вышеописанные действия происходят в рамках одного кластера, для которого и разворачивается самомониторинг.
Преимущества
-
Отсутствие необходимости в дополнительном сервере и его настройке
- Не требуется выделять и настраивать дополнительные ресурсы для размещения сервера самомониторинга, что может уменьшить затраты на инфраструктуру и упростить процесс развертывания
-
Доступность данных самомониторинга на целевом кластере
- Данные самомониторинга сразу становятся доступными внутри целевого кластера, что упрощает доступ и анализ данных для операторов и администраторов системы
Недостатки
-
Недоступность самомониторинга в случае сбоя целевого кластера
- В случае аварийного сбоя целевого кластера, сервер самомониторинга также становится недоступным, что может затруднить мониторинг состояния и производительности системы.
-
Дополнительная нагрузка на целевой кластер
- Эксплуатация самомониторинга на целевом кластере может повлечь за собой дополнительную нагрузку на ресурсы этого кластера, что может снизить производительность приложений или сервисов
Сбор данных
Собираемые самомониторингом данные можно разделить на 2 категории:
- Файлы журналов (логи)
- Метрики и прочая статистика
Сбор логов
Сбор логов происходит со всех узлов SM Data Storage, SM Data Collector и SM Master Node целевого кластера. На хосты целевого кластера устанавливаются и настраиваются агенты SmartBeat (информацию по установке можно найти в разделе полезные ссылки). При их настройке указывается адрес SmartBeatManager сервера самомониторинга, содержащий необходимые конфигурации для агентов сбора и отправки данных. Эти компоненты будут установлены и запущены на хостах кластера. В части сбора логов используется Filebeat, настроенный на сбор таких логов, как:
Для хостов с SM Data Storage:
- логи кластера
- логи sme
- логи sme-re
- логи job scheduler
Для хостов с SM Data Collector:
- логи самого SM Data Collector
- логи SM Data Collector пайплайнов
Сбор метрик
Для сбора метрик SM Data Storage используется http_poller input-плагин в SM Data Collector. Он позволяет с определенной переодичностью опрашивать указанные REST эндпоинты.
В шаблонах пайплайнов самомониторинга можно увидеть, что плагин http_poller может отправлять одинаковый запрос ко всем master-узлам целевого кластера, а затем использовать throttle filter-плагин для фильтрации дублирующихся ответов. Это необходимо для обеспечения получения данных даже в случае отказа одного или нескольких master-узлов, поскольку запросы будут выполнены к оставшимся работающим узлам.
Для сбора метрик с SM Data Collector используется Metricbeat.
Конфигурация
В комплект самомониторинга входят скрипты генерации пайплайнов, конфигураций агентов и включают автоматизацию других необходимых манипуляций:
-
generate_pipelines.py: этот скрипт отвечает за генерацию пайплайнов и конфигураций агентов. Он автоматически создает необходимые элементы для сбора данных и настройки агентов -
generate_opensearch_configs.py: этот скрипт предназначен для генерации политик Index State Management (ISM), создания шаблонов индексов и копирования дашбордов. Он также может выполнять подключение к SM Data Storage и создавать соответствующие политики, шаблоны индексов и индексы при необходимости -
import_certs.sh: этот скрипт позволяет добавить сертификаты хостов в truststore. Это необходимо для обеспечения безопасного TLS-соединения при обращении SM Data Collector к целевым хостам по API
Файл конфигурации
Все упомянутые выше скрипты извлекают настройки из файла конфигурации config.ini.
Описание полей файла конфигурации приведены ниже в таблице:
| Поле | Параметр |
|---|---|
| rest | Данные для загрузки ISM-политик, шаблонов индексов и создания индексов в SM Data Storage (для скрипта
|
| ism | Данные для настройки ISM-политики на индексы с данными самомониторинга:
|
| index_templates | Данные для создания шаблонов индексов с данными самомониторинга:
|
| poller | Данные для
|
| logstash | Параметры конфигурации SM Data Collector на сервере самомониторинга:
|
| beats | Параметры конфигурации агентов:
|
Установка
Компоненты SM Master Node, SM Data Storage, SM Data Collector и Smart Beat Manager (SBM) (информацию по установке можно найти в разделе полезные ссылки) должны быть установлены и корректно настроены до начала выполнения данной инструкции.
Компонент selfmonitoring входит в базовую поставку Smart Monitor и расположен в директории ${SM_INSTALLER}/utils/selfmonitoring/. Для запуска рекомендуется использовать Python, который также входит в состав установщика и расположен в директории ${SM_INSTALLER}/utils/python/bin/python3.
Заполнение конфигурации
Заполните конфигурационный файл config.ini реальными параметрами.
Бóльшая часть параметров, связанных с путями, настройками поллинга, ISM и шаблонами индексов, может оставаться без изменений. Изменения, если они требуются, касаются в основном IP-адресов. Тем не менее, перед использованием настоятельно рекомендуется внимательно просмотреть каждый параметр и убедиться, что значения указаны корректно и соответствуют текущим требованиям вашей системы.
Запуск скриптов
Генерация файлов для SM Data Storage
Если запустить скрипт без аргументов, то он сгенерирует файлы ISM-политик, шаблонов индексов и дашбордов, сохранив их в директорию ${SM_INSTALLER}/utils/selfmonitoring/generated_data:
${SM_INSTALLER}/utils/python/bin/python3 ${SM_INSTALLER}/utils/selfmonitoring/generate_opensearch_configs.py
Если запустить скрипт с аргументом --upload, то помимо генерации файлов, контент также загрузится в SM Data Storage самомониторинга (дополнительно создадутся и сами индексы):
${SM_INSTALLER}/utils/python/bin/python3 ${SM_INSTALLER}/utils/selfmonitoring/generate_opensearch_configs.py --upload
Вы можете сначала запустить скрипт без флага --upload, посмотреть результаты, и, убедившись в их корректности, загрузить их в SM Data Storage, выполнив повторный запуск скрипта с флагом --upload.
Генерация файлов для SM Data Collector и SmartBeatManager
Запустите скрипт ${SM_INSTALLER}/utils/selfmonitoring/generate_pipelines.py:
${SM_INSTALLER}/utils/python/bin/python3 ${SM_INSTALLER}/utils/selfmonitoring/generate_pipelines.py
После его запуска в той же директории ${SM_INSTALLER}/utils/selfmonitoring/generated_data появятся директории с данными для SM Data Collector и SmartBeatManager.
Импортирование сертификатов
Запустите скрипт ${SM_INSTALLER}/utils/selfmonitoring/import_certs.sh:
cd ${SM_INSTALLER}/utils/selfmonitoring/ && chmod +x import_certs.sh
sudo -u logstash ./import_certs.sh
Важно выполнять запуск скрипта от имени пользователя logstash.
Ход выполнения скрипта:
- Создание нового
truststore. При запуске скрипта будет запрошено дважды ввести новый пароль для создаваемого хранилища сертификатов. Этот пароль необходимо запомнить, так как он понадобится на следующих этапах - Для каждого хоста будет выполнено подключение и получение сертификата. На вопрос
Trust this certificate? [no]:необходимо отвечатьyes - Добавление паролей в
keystore. Скрипт запросит на ввод пароли дляts_pwdиos_pwd. Для первого токена вводится пароль, который вы задали на первом шаге, для второго токена - пароль для пользователя SM Data Storage, логин которого вы указали в конфигурацииconfig.ini
Если пароли пользователей для подключения к целевому кластеру и самомониторинга отличаются, а в конфигурации указан в поле logstash.pwd_token другой токен, то его надо добавить вручную на сервере с SM Data Collector самомониторинга с помощью команды:
sudo -u logstash ${LOGSTASH_HOME}/bin/logstash-keystore add <TOKEN_NAME>
-
Если на момент запуска скрипта на SM Data Collector уже был создан truststore, по пути указанному в конфигурации, то скрипт единожды запросит у вас его текущий пароль
-
Если на момент запуска скрипта на SM Data Collector не был инициализирован keystore, вы получите сообщение
The keystore password is not set... Continue without password protection on the keystore? [y/N]. Ответьтеy. Если keystore был инициализирован и на нем был задан пароль, то скрипт запросит его ввод. Если же пароль на нем не был задан, то дополнительно вводить ничего не потребуется
Размещение сгенерированных файлов
После предыдущих шагов в директории ${SM_INSTALLER}/utils/selfmonitoring/generated_data будут находится все необходимые файлы (готовая сборка). Директории, упомянутые ниже, будут указаны относительно нее, исключая случаи, когда указан абсолютный путь.
Настройка SM Data Storage
Создайте ISM-политику и шаблоны индексов на основе данных в директориях ism и index_templates соответственно. Создайте индексы.
Если вы загружали конфигурации SM Data Storage в автоматическом режиме (запускали скрипт generate_opensearch_configs.py c флагом --upload), то пропустите этот шаг
Настройка SM Data Collector
- Перенесите пайплайны из директории
${SM_INSTALLER}/utils/selfmonitoring/generated_data/logstash/pipelines/в${LOGSTASH_HOME}/config/conf.d/ - Перенесите скрипты из директории
${SM_INSTALLER}/utils/selfmonitoring/generated_data/logstash/scripts/в директорию, указанную в конфигурации в параметреlogstash.scripts_path(по умолчанию${LOGSTASH_HOME}/config/conf.d/scripts/) - Добавьте содержимое файла
pipelines.ymlв${LOGSTASH_HOME}/config/pipelines.yml - Измените владельца перенесенных файлов
После проделанных шагов перезапустите сервис SM Data Collector:
sudo chown -R logstash:logstash ${LOGSTASH_HOME}/
sudo systemctl restart logstash.service
Настройка SmartBeatManager
-
Перенесите содержимое директории
${SM_INSTALLER}/utils/selfmonitoring/generated_data/sbmв${SBM_HOME}/apps/ -
Скачайте архивы с filebeat и metricbeat (при возникновении затруднений с загрузкой рекомендуем обратиться в техническую поддержку), поместите их в директорию
${SBM_HOME}/binaries/ -
Отредактируйте файл
${SBM_HOME}/etc/serverclasses.yml. Добавьте в него группыlinux_selfmonиlinux_selfmon_logstashсо следующим содержимым:
groups:
- name: linux_selfmon
filters:
- "<IP 1-го узла opensearch>"
- "<IP 2-го узла opensearch>"
...
- "<IP N-го узла opensearch>"
apps:
- filebeat_selfmon
binaries:
- filebeat-oss-8.9.2-linux-x86_64.tar.gz
- name: linux_selfmon_logstash
filters:
- "<IP 1-го logstash>"
- "<IP 2-го logstash>"
...
- "<IP N-го logstash>"
apps:
- filebeat_logstash
- metricbeat_logstash
binaries:
- filebeat-oss-8.9.2-linux-x86_64.tar.gz
- metricbeat-oss-8.9.2-linux-x86_64.tar.gz
Обратите внимание на разделы filters и binaries. В filters для первой группы необходимо указать IP-адреса всех узлов целевого кластера, а для второй - IP-адреса всех logstash'ей целевого кластера. В разделах binaries проверьте что имена архивов совпадают с теми, что вы загрузили в директорию ${SBM_HOME}/binaries/.
После проделанных шагов перезапустите сервис SmartBeatManager:
sudo systemctl restart smartBeatManager.service
Добавление дашбордов
Необходимо установить SmartBeat (информацию по установке можно найти в разделе полезные ссылки) на все узлы SM Data Collector, SM Data Storage и SM Master Node целевого кластера. В качестве сервера для SmartBeatManager следует указать SBM сервера самомониторинга.
- В веб-интерфейсе сервера самомониторинга перейдите в раздел
Дашборды(Навигационное меню-Основное-Дашборды) и создайте новые дашборды используя содержимое json-файлов в директорииdashboards - Обновите параметры фильтров выбора узлов кластера в дашбордах согласно актуальным данным
- В разделе
Настройка модулейперейдите в пунктШаблоны индексов(Навигационное меню-Параметры системы-Настройки модулей-Шаблоны настроек индексов) и создайте шаблоны, аналогичные алиасам индексов (clusterstats,clusterhealth, и т.д.)
После данного этапа установку самомониторинга можно считать завершенной.
При реализации архитектуры с отдельным сервером самомониторинга рекомендуется настроить cross-cluster search (информацию по настройке можно найти в разделе полезные ссылки) для обращения с целевого кластера.