Год назад к инженерам YADRO обратился клиент с просьбой помочь с настройкой мониторинга для СХД TATLIN.UNIFIED. Для семейства TATLIN у компании есть продукт TATLIN.SATELLITES (спутники) — это инструменты, включающие драйверы, плагины и шаблоны для интеграции систем хранения данных со сторонними системами. Но пользователю требовалось готовое интегрированное решение, которое бы не нагружало инженеров компании. Так появился Monitoring Appliance — приложение для мониторинга систем хранения данных, которое можно развернуть на сервере за пять минут. В статье рассказываем, как собирать с СХД все возможные данные и где могут быть подводные камни.
Задача клиента
Пользователю более сотни систем хранения данных нужно было выделять дисковое пространство СХД на различные задачи: операционную деятельность, тестирование, резервное копирование. Кроме этого, было необходимо следить за переподпиской пулов, так как тома СХД быстро заполнялись.
Для самостоятельного решения задачи клиент использовал стандартные возможности известных систем мониторинга и скрипты на базе электронных таблиц, но на это уходило немало времени, а доступные инструменты не решали проблему в полной мере.
Инженеры YADRO решили взять эту задачу на себя и включить в состав продукта TATLIN.SATELLITES интегрированное решение для мониторинга. Разрабатываемый мониторинг должен был включать компоненты для сбора и хранения метрик со множества массивов, а также их визуализацию и алертинг.
Требования к системе
Она должна быть простой в использовании, не требовать долгого изучения документации и затрат ресурсов инженеров клиента.
Состоять из доступных open source-решений.
Позволять мониторить состояния массивов данных и принимать решения об их дополнении или расширении.
Иметь понятную и простую для заказчика визуализацию.
Итогом стала система, получившая название Monitoring Appliance. Клиенту она может поставляться как Docker Compose или образ виртуальной машины (по отдельному запросу).
Архитектура приложения для мониторинга
По сути, это приложение — набор инструментов с открытым исходным кодом, которые связаны между собой и упакованы, например в Docker Compose. На схеме — общее представление того, как связаны между собой сервисы.
Далее расскажем, почему выбрали тот или иной инструмент и как они взаимодействуют между собой.
Итак, у нас есть какое-то количество систем хранения данных TATLIN.UNIFIED, с которых мы хотим собирать метрики и мониторить их состояние. Информацию о состоянии СХД мы можем получать разными способами.
Сбор информации через SNMP get. Нам нужен был инструмент, который бы отправлял запросы до TATLIN.UNIFIED. В спутниках TATLIN (TATLIN.SATELLITES) есть Zabbix-шаблоны, которые помогут настроить мониторинг с помощью Zabbix. Но полученными данными сложно манипулировать штатными средствами. Даже подключив Grafana к Zabbix, мы сильно ограничены функционалом плагина для Zabbix. Поэтому мы выбрали Prometheus-метрики, так как язык запросов PromQL дает нам большую свободу при манипуляции данными.
Но есть нюанс: Prometheus не умеет работать с протоколом SNMP напрямую. Поэтому в архитектуре сервиса появился дополнительный компонент — Prometheus SNMP Exporter. Он трансформирует полученные метрики в формат, который может считывать Prometheus. Через SNMP get мы обычно получаем с TATLIN.UNIFIED инвентарную информацию, серийные номера, статусы дисков, полок, процессоров, метрики производительности.
В архитектурной схеме Monitoring Appliance приложение Prometheus вы не найдете. Все потому, что в нашем случае мы используем агент, встроенный в Victoria Metrics. Он опрашивает СХД TATLIN через SNMP Exporter и забирает метрики, а полученные данные хранятся в базе данных Victoria Metrics — хорошем решении для хранения time series-данных. Частоту запросов через SNMP get пользователь может определить самостоятельно.
В целом, мы понимаем, что получение данных только по протоколу SNMP накладывает ряд ограничений. Поэтому разрабатываем решение, которое позволит собирать данные через API.
Сбор SNMP trap-сообщений. Через SNMP trap обычно приходят сообщения о неисправностях в системе, в том числе хардварных, — например, о проблемах с PSU (Power Supply Unit).
Для сбора SNMP trap нет готового решения, поэтому мы написали отдельный Python-скрипт — Python Handler. Он трансформирует трапы, полученные при помощи snmptrapd, в метрики, которые можно положить в Victoria Metrics, или упаковывает в логи и кладет в Grafana Loki. На сообщение в таком формате уже можно настроить алертинг и сообщать пользователю, если что-то пошло не так.
Сбор Syslog-сообщений. Кроме SNMP, TATLIN может передавать информацию через Syslog — этот «канал» также можно использовать. На стороне СХД настраиваются таргеты, куда отправлять Syslog. В нашей системе их принимает Rsyslog и трансформирует в формат, пригодный для Promtail. Последний, в свою очередь, это агент, который может принимать логи и класть их в уже упомянутую Grafana Loki, базу для хранения логов. В основном Syslog передает данные аудита СХД и такие же сообщения, как SNMP trap, только в специфичном для Syslog формате.
Базы данных системы
Для хранения данных мониторинга в системе два основных инструмента: Grafana Loki и Victoria Metrics (в будущем, мы планируем перейти на VictoriaLogs вместо Grafana Loki). Первая хранит логи работы, с помощью которых можно ретроспективно посмотреть работу систем хранения данных. Помимо Syslog, здесь можно хранить и SNMP-трапы, если сконвертировать их именно в логи, а не метрики. Victoria Metrics — просто хорошая база данных, известная на рынке и популярная для работы именно в системах мониторинга. Но ее можно легко заменить на иную БД, подходящую для хранения временных рядов, — например, Cortex Metrics.
Сопутствующие инструменты и настройка алертов
Получившаяся система может работать в Docker Compose. Чтобы начать им пользоваться, достаточно развернуть на сервере — задача на 10-15 минут. При этом в Monitoring Appliance заложен мониторинг не только систем хранения данных, но и сервера, на котором оно стоит. Для этого есть Telegraf — агент, мониторящий сервер-хост: как утилизируется мощность процессора, сколько памяти еще свободно и подобные метрики «здоровья».
Мониторинг и красивые дашборды — это замечательно, но редкий специалист готов изучать графики каждую рабочую минуту. Поэтому нам нужна система алертинга. Это не обязательно должны быть сообщения об ошибках, алерт можно настроить и на достижение определенного порога «заполнения» пулов и ресурсов в СХД. Здесь на помощь приходят VM Alert и Alert Manager.
В VM Alert от Prometheus формируется определенный набор алертов, в котором прописаны пороговые значения для метрик. По заданному пользователем интервалу VM Alert запрашивает метрики в VictoriaMetrics и проверяет, не достигнуто ли условие срабатывания правила алертинга. Если да, то он генерирует алерт, который можно увидеть в Grafana или дашборде с алертами. Также можно настроить оповещение через внешние системы (Alert Manager) — Telegram (или другой мессенджер), почту и так далее.
Инженеры YADRO разработали примеры конфигурационных файлов и шаблонов сообщений для алертов, которые может использовать клиент. И он вправе расширять их или изменять.
Ну, и наконец в систему добавлен Nginx — веб-сервер, который работает как reverse proxy. Он позволяет настроить TLS-шифрование — так пользователь может через Nginx ходить либо по доменным именам на каждой компонент, либо по путям (например, /grafana, /alertmanager и так далее).
Возможности YADRO Monitoring Appliance
Если обобщать возможности собранной системы, то можно составить следующий список. Наша система мониторинга может:
Собрать метрики производительности компонентов СХД по протоколу SNMP.
Принять и обработать SNMP traps от СХД.
Принять и обработать Syslog-сообщения от СХД.
Мониторить состояние сервера, на котором установлен Monitoring Appliance.
Отображать данные мониторинга в виде дашбордов.
Оповещать о внештатных ситуациях и пороговых состояниях.
А теперь посмотрим, какие дашборды в итоге получается делать благодаря этому мониторингу «из коробки».
Главная страница. На ней отображаются основные метрики «здоровья» систем хранения данных, на которых хочет сфокусироваться пользователь. Мы предоставляем «шаблон» дашборда. Можно выбрать нужную СХД и получить данные конкретно по ней. Но этот дашборд легко пересобрать, исходя из своих целей.
Пулы. Здесь можно собрать информацию по пулам со множества массивов: посмотреть свободную физическую емкость и oversubscription. При нажатии на пул мы проваливаемся к списку ресурсов.
Также есть отдельный дашборд с общим списком пулов, в каждый из которых можно провалиться и посмотреть, какие ресурсы находятся в этом пуле.
А если кликать по ресурсам, то отобразится перформанс по каждому ресурсу.
Отчет по алертам. Это Grafana-дашборд, который использует DataSource, который работает с Alertmanager по API.
WWID-лист. Список с ID каждого ресурса, соответствующим хостам, пулам и так далее.
Перфоманс ресурсов. Дашборд по ресурсам и задержкам (latency).
Это лишь несколько примеров дашбордов, которые можно получить с помощью приложения для мониторинга. В целом, их список может ограничиваться только фантазией пользователя и его умением пользоваться Grafana.
Удобный и бесплатный мониторинг для пользователей TATLIN
В итоге у нас получился простой и легкий в управлении и масштабировании инструмент. Его могут использовать бесплатно все клиенты YADRO.
У приложения есть неочевидный дополнительный плюс. Использование каждого компонента в отдельности (например, Grafana или Victoria Metrics) требует отдельного согласования с департаментом по информационной безопасности компании (так как они не входят в Росреестр одобренного ПО). Упакованный же в Appliance готовый сервис проще согласовать как единую систему, поставляемую YADRO.
Так один частный запрос клиента спровоцировал появление полезного инструмента, который пополнил список продуктов-спутников TATLIN. Теперь этот клиент пользуется мониторингом ежедневно и экономит время на отслеживание метрик «здоровья» и утилизации СХД. Задачи, которые раньше занимали часы и даже дни, решаются за минуты с помощью дашбордов. Теперь компания понимает, как лучше распределить по массивам новые ресурсы: где емкости не хватает, а где есть свободные слоты.
Это вводная статья про эффективный мониторинг ресурсов СХД. В следующих статьях мы хотим подробнее осветить технические моменты сборки этого мониторинга в ряде инструкций. Сможете повторить, если перед вами стоит подобная задача.
Интересен ли вам такой материал? Пишите в комментариях, какую связку системы осветить в первую очередь, или просто ставьте плюсик этой публикации. Так мы поймем, что вы заинтересованы в продолжении.