Меня зовут Андрей, я работаю в группе резервного копирования в компании «Ростелеком-ЦОД». Мы отвечаем за хранение и целостность резервных копий наших клиентов и поддержку инфраструктуры РК в оптимальном состоянии. В этой статье я хочу рассказать о том, как мы смогли значительно упростить мониторинг статуса заданий в системе резервного копирования Veeam, создав мощный инструмент на основе Grafana. Этот инструмент позволяет нам получать ценные метрики и статистику о производительности и состоянии нашей инфраструктуры резервного копирования.

Основные инструменты, которые мы используем в работе:

• Veeam Backup and Replication (VBR);

• Nagios — позволяет оперативно получать оповещения об ошибках по электронной почте и автоматически создавать тикеты в сервис-деске нашей группы.

Проблемы

Ранее мы столкнулись с несколькими проблемами в нашем мониторинге. Тикеты в сервис-деске и письма в почте не давали нам полной картины о производительности системы, например, о количестве невыполненных заданий за сутки. С учетом того, что у нас более 10 консолей Veeam, надо было собрать всю информацию в одном месте и наглядно представить ее на дашборде в Grafana.

Решение

Мы упростили мониторинг, сосредоточившись на сборе и визуализации метрик в Grafana. Эти данные позволили следить за общей производительностью системы РК и оперативно реагировать на любые проблемы или задержки в выполнении задач.

Вот основные шаги, которые мы предприняли:

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

• Связали Veeam с Grafana: настроили интеграцию между Veeam и Grafana, чтобы получать данные о метриках и статусе заданий в реальном времени. Это позволило нам собирать информацию со всех консолей Veeam в единую систему и визуализировать ее на дашборде.

• Разработали набор наглядных графиков и дашбордов в Grafana, которые позволили быстро оценивать текущую ситуацию и выполнение задач.

Что собирать?

Для сбора необходимых метрик мы обратились к базе данных VBR. В нашем случае — использование полноценного модуля Veeam.Backup.PowerShell не подходило, так как компания Veeam не рекомендует непосредственное использование данных из их базы данных.

Чтобы ясно определить структуру и необходимые метрики из БД Veeam, мы нарисовали план в draw.io. Это помогло лучше понять, какие конкретно метрики надо искать в базе данных и какую информацию мы хотим получить в итоге.

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

Получив ясное представление о структуре и требуемых метриках, мы перешли непосредственно к сбору метрик из БД VBR.

Вместе с нашим инженером DBA мы определили необходимые таблицы из БД. Мы знали, что использование этих таблиц напрямую не рекомендуется, так как при изменении версий VBR они могут быть изменены или удалены.

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

• Model.JobSessions. Из этой таблицы мы выбрали несколько метрик: время выполнения задания, статус заданий и скорость заданий.

• Backup.Repositories. Из этой таблицы мы выбрали две метрики: общую емкость (Total capacity) и свободную емкость (Free capacity).

Чтобы сопоставить значения, представленные цифрами в таблице статусов задач, с реальным статусом в консоли, пришлось, конечно, попотеть. В итоге мы декодировали статусы и определили, что нам важен столбец Result.

Собрав необходимые метрики из выбранных таблиц, мы приступили к постройке наглядного и информативного дашборда.

Как собирать?

Для сбора, хранения и анализа метрик и логов мы выбрали VictoriaMetrics. В числе ее преимуществ — поддержка различных протоколов и форматов данных, таких как Prometheus, Graphite, InfluxDB и Open TSDB. Она также позволяет работать как в кластерной конфигурации, так и на одном сервере, и в целом дает гибкость и масштабируемость в обработке метрик и логов.

Мы смогли интегрировать систему с различными источниками данных и унифицировать их, собрав в одном месте. Это позволило удобно визуализировать и анализировать информацию с помощью Grafana.

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

Мы развернули кластерную версию VictoriaMetrics с использованием нескольких vmagent, которые параллельно собирают информацию с различных сервисов в нашей инфраструктуре, связанных с VBR, MS SQL для Veeam Backup and Replication (VBR-SQL) и Backup Repository Server с файловой системой REFS.

Для сбора состояния заданий с MS SQL мы использовали sql_exporter. Коллеги из отдела DBA разработали для него коллектор, который включал все запросы для получения нужных метрик.

Для эффективной работы windows_exporter, который собирает метрики производительности Windows, мы настроили параметры запуска, включив следующие коллекторы: CPU, Memory, Network, Disk и System. Всегда можно изменить параметры коллекторов, внеся соответствующие изменения в реестр системы.

После настройки и включения экспортеров и коллекторов мы перезапустили их для проверки сбора и отображения всех метрик. Для проверки работы windows_exporter использовался адрес localhost:9182, а для sql_exporter – localhost:9399 в браузере.

Что получилось?

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

Этот дашборд показывает информацию по конкретному VBR серверу:

1. Панель Job Historcial Info показывает статус последних заданий за 24 часа.

2. Панель OS Version показывает версию ОС на VBR-сервере.

3. Панель Uptime показывает время непрерывной работы VBR-сервера.

4. Панель Average Job Duration показывает график среднего времени по всем заданиям, за которое они перешли в завершенный статус.

5. Панель CPU Usage показывает утилизацию CPU за последние 10 секунд. Этот параметр относится к SQL-серверу. Утилизацию CPU можно посмотреть на общем дашборде по всем VBR.

6. Панель Average Job Speed показывает график средней скорости выполнения всех заданий.

7. Панель Physical Memory показывает утилизацию RAM за последние 10 секунд. Этот параметр относится к SQL-серверу. Утилизацию RAM можно посмотреть на общем дашборде по всем VBR.

8. Панель Running Jobs показывает количество запущенных заданий за последние 24 часа.

9. Панель Average CPU Usage (%) показывает график средней утилизации CPU. Этот параметр относится к SQL серверу. Утилизацию CPU можно посмотреть на общем дашборде по всем VBR.

10. Панель Time Series Jobs показывает гистограмму статуса заданий.

11. Панель Success Jobs показывает количество выполненных заданий за последние 24 часа.

12. Панель Warning Jobs показывает количество заданий, завершенных с предупреждением, за последние 24 часа.

13. Панель Error Jobs отображает количество заданий, завершенных с ошибкой, за последние 24 часа.

14. Панель Average Memory Usage показывает график средней утилизации RAM. Этот параметр относится к SQL-серверу. Утилизацию RAM можно посмотреть на общем дашборде по всем VBR.

15. Панель Running Jobs показывает график количества запущенных заданий.

16. Панель Used space on repos показывает процент занятого места в репозитории и общий объем репозитория.

17. Панель Netcard показывает загруженность сети. Параметр относится к SQL-серверу. Утилизацию сети можно посмотреть на общем дашборде по всем VBR.

18. Панель Top fail at week показывает список заданий и сколько раз за неделю они завершились с ошибкой.

19. Панель Top warning at week отображает список заданий и сколько раз за неделю они завершились с предупреждением.

20. Панель Top fail at week показывает список заданий и расшифровку ошибки, из-за которой не завершились задания за неделю.

21. Панель Top warning at week показывает список заданий и расшифровку предупреждений за неделю.

На основе дашборда по конкретному VBR-серверу мы создали также общий дашборд, чтобы видеть информацию по всем VBR-серверам.

22. Success jobs показывает количество выполненных заданий за последние 24 часа.

23. Error jobs показывает количество заданий, завершенных с ошибкой за последние 24 часа. Дополнительно я написал запрос в коллекторе, который исключает задания, завершенные с ошибкой VM not found.

24. Running jobs показывает количество запущенных заданий за последние 24 часа.

25. Warning jobs показывает количество заданий, завершенных с предупреждением за последние 24 часа.

Что дальше?

Алертинг. Мы постоянно работаем над улучшением этого инструмента и в ближайшем будущем планируем настроить алертинг на основе AlertManager. Это позволит получать моментальные уведомления о любых проблемах и аномалиях в системе и принимать необходимые меры.

Бот для Telegram. Куда же без бота в наши дни. Мы разработали и внедрили бота для Telegram, который оказался незаменимым инструментом. Он позволяет получать графики и данные из нашего дашборда по VBR-серверам в любое время в любом месте. Мы начали разработку бота месяц назад и постепенно совершенствуем его функциональность.

Функциональность бота включает:

• выбор конкретного дашборда;

• выбор панели на выбранном дашборде;

• выбор временного промежутка для отображения данных на панели;

• отправку скриншота с графиком.

В наших планах добавить выбор Hostname. Это позволит пользователям получать через бот данные и графики для конкретных серверов.

Будем рады вопросам и советам.