Всем привет! Я Павел Логинов, руководитель группы облачных решений EdgeЦентр. Сегодня расскажу вам о нашем кастомном мониторинге гипервизоров: как мы его сделали, как он работает и какую пользу приносит нам и нашим клиентам.

У каждого из нас рано или поздно появляется задача о мониторинге гипервизоров на предмет их работы «изнутри». Нет? Странные вы какие-то.

А вот у нас в компании иногда возникали такие ситуации: на улице +20 градусов, но ощущается как +10. По нашим приборам всё хорошо. Но клиент нашего облака, который арендует у нас виртуальную машину, жалуется: сеть медленно работает, или диск, или процессор. Приходилось идти и разбираться, в чём дело. Это отнимало время. И клиенты были недовольны. К тому же объемы росли. На данный момент у нас 5 регионов с Openstack и больше 250 гипервизоров.

В какой-то момент мы решили, что дальше так жить нельзя. И сделали собственный мониторинг гипервизоров — систему, с помощью которой мы теперь узнаём о проблемах не от клиентов или L1, а (вот это достижение!) из алертов.

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

Почему мы решили, что нам нужен свой мониторинг гипервизоров

Для мониторинга серверов есть разные готовые программы. Наш мониторинг построен вполне стандартно: Exporters -> Prometheus -> Alertmanager/Grafana. Соответственно возникает вопрос: почему, например, не брать данные из Node exporter?

Node Exporter — прекрасная вещь. Он показывает состояние самого гипервизора, и мы, конечно же, берем оттуда данные для мониторинга, но для другого. А в нашей ситуации нужно было понять, как чувствует себя виртуальная машина на конкретном гипервизоре.

Но есть же libvirt exporter, скажете вы. Да есть. Но в нём лишь общие данные по использованию CPU, RAM и т.п. А нам было важно понимать Steal time и скорость сети непосредственно в ВМ.

Для чего нам это было нужно? Как я уже писал выше, для понимания состояния виртуальных машин. Например, бывает что scheduler ошибается и перегружает один гипервизор. Или появляется «шумный сосед». Или клиент говорит, что у него приложение работает плохо.

В таких ситуациях и помогает наш мониторинг:

• Найти перегруженный гипервизор и разгрузить его.

• Как можно быстрее найти «шумного соседа» и «отселить».

• Разобраться с проблемой клиента и объяснить, что нам очень жаль, но проблема всё-таки на стороне приложения.

• Либо подтвердить проблему на нашей стороне и исправить её.

Как мы автоматизировали мониторинг в нашей системе

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

У нас есть pipeline, который ходит в нужный регион, берет из Openstack список активных гипервизоров, фильтрует (так как не на всех гипервизорах нужен мониторинг),  удаляет ненужные ВМ мониторинга, или создаёт ВМ мониторинга только на тех гипервизорах, где это необходимо.

В pipeline намешано очень много: bash, python, Ansible и Terrafom. Логика работы здесь такая:

1. Берем список всех гипервизоров.

2. Фильтруем их и оставляем только необходимые.

3. Генерим tfvars-файл со списком виртуальных машин и гипервизоров.

4. Создаем silence в Alertmanager, чтобы не получать алерты об удаленных машинах.

5. Создаем или удаляем ВМ мониторинга.

6. Генерим SD-файл для Prometheus с актуальными таргетами.

7. Делаем список ВМ мониторинга, чтобы машины пинговали друг друга и проверяли сеть между гипервизорами.

8. Загружаем список IP-адресов виртуальных машин в S3. ВМ будут брать из S3 этот список и обновлять конфигурацию. Для этого мы написали скрипт — о нём дальше расскажу подробнее.

9. Загружаем файл с таргетами на сервер Prometheus и перезагружаем Prometheus.

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

Для ВМ мониторинга у нас есть свой образ с установленным Ping, Node, IO экспортерами и скриптом, который запускается раз в пол часа. Скрипт необходим для пересоздания файла конфигурации для Ping экспортера. Скрипт, кстати, приезжает через cloud-init, и для его изменений не надо пересобирать образ.

Теперь подробней про скрипт. Так как мы не хотим пересоздавать ВМ мониторинга на гипервизорах, где ничего не меняется, а Terraform нам это позволяет, был написан bash-скрипт. Он запускается по крону, ходит в S3 и пересоздает часть конфига, в котором описаны ВМ мониторинга. Это позволяет нам точечно добавлять или удалять гипервизоры из мониторинга, не задевая всё остальное. А ещё это дает неплохой прирост в скорости изменений, и мы не остаемся надолго без мониторинга.

Что в итоге

В итоге мы всегда имеем актуальный набор ВМ мониторинга на актуальных гипервизорах и с лёгкостью вносим все нужные изменения. С помощью актуальных и полных данных, а именно: Steal time, I/O latency, Local network latency, Public network latency, Ping lost rate, мы можем превентивно обнаружить проблему, если она возникнет, и помочь клиентам решить её.

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