Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Доброго времени суток! Понравились ваши статьи. После прочтения их у меня появилось к Вам несколько вопросов. Не оставите мне свой контактный e-mail для связи?
Зачем использовать influxdb, у которого есть определенные проблемы со стабильность и у которого платная кластеризация?
Почему не prometheus + libvirt_exporter?
Трудно сказать, зачем использовать продукт A, а не продукт B.
Наверное, моя мысль не так развивалась, когда я решил реализовать данный модуль. Я посмотрел что есть актуального среди TSDB, посмотрел бенчмарки и выбрал InfluxDB. Разработка заняла меньше двух дней, что вполне допустимо даже для неудачного PoC.
Если взять даже грубую оценку для сбора данных 1 раз в 30 секунд для 1000 хостов с 100 VM на каждом, то получается 100000 VM (~ 500000 точек). Скорее всего, данный масштаб еще нормально [обработается](https://www.influxdata.com/announcing-influxdb-v0-10-100000s-writes-per-second-better-compression/) одним сервером InfluxDB, а возможно, что и нет… Но, если вдуматься, то это уже задача иного масштаба, потому что 1000 серверов — это 30 стоек и это вполне приличные деньги, достаточные для применения подхода к решению задачи, который займет не два дня на реализацию. Возможно, что на данном этапе это уже будет какая-то другая технология, может быть платная кластеризация InfluxDB.
Что же до проблем со стабильностью, то я, к счастью, пока что их не наблюдаю. Вполне может быть, что они есть на масштабе, который я привожу выше, но за несколько месяцев использования пока что я существенных проблем не обнаружил.
В общем, хочу лишь сказать, что описанное мной решение работает и работает хорошо, а если будет хорошо работать и для других людей — волшебно.
Это, конечно, тред про администрирование, но для супермасштабных задач я бы попробовал Apache Kafka + Spark + RocksDB
Наверное, моя мысль не так развивалась, когда я решил реализовать данный модуль. Я посмотрел что есть актуального среди TSDB, посмотрел бенчмарки и выбрал InfluxDB. Разработка заняла меньше двух дней, что вполне допустимо даже для неудачного PoC.
Если взять даже грубую оценку для сбора данных 1 раз в 30 секунд для 1000 хостов с 100 VM на каждом, то получается 100000 VM (~ 500000 точек). Скорее всего, данный масштаб еще нормально [обработается](https://www.influxdata.com/announcing-influxdb-v0-10-100000s-writes-per-second-better-compression/) одним сервером InfluxDB, а возможно, что и нет… Но, если вдуматься, то это уже задача иного масштаба, потому что 1000 серверов — это 30 стоек и это вполне приличные деньги, достаточные для применения подхода к решению задачи, который займет не два дня на реализацию. Возможно, что на данном этапе это уже будет какая-то другая технология, может быть платная кластеризация InfluxDB.
Что же до проблем со стабильностью, то я, к счастью, пока что их не наблюдаю. Вполне может быть, что они есть на масштабе, который я привожу выше, но за несколько месяцев использования пока что я существенных проблем не обнаружил.
В общем, хочу лишь сказать, что описанное мной решение работает и работает хорошо, а если будет хорошо работать и для других людей — волшебно.
Это, конечно, тред про администрирование, но для супермасштабных задач я бы попробовал Apache Kafka + Spark + RocksDB
Спасибо за статью.Только посмотрите еще в сторону аутентификации на libvirt.
В статистике по дискам есть такие поля:
«allocatedSpace»: 890,
«onDiskSpace»: 890,
«totalSpace»: 1000
Подскажите, что они значат в контексте libvirt?
«allocatedSpace»: 890,
«onDiskSpace»: 890,
«totalSpace»: 1000
Подскажите, что они значат в контексте libvirt?
В зависимости от типа Storage, например файлы в формате qcow2, диск может иметь фактический размер не совпадающий с задекларированным в связи с «ленивым» выделением. TotalSpace — размер диска как его видит vm, а onDiskSpace — сколько на диске фактически занято, allocatedSpace не могу сказать значение, надо смотреть документацию libvirt.
Для raw файлов и блочных устройств все три должны совпадать.
Для raw файлов и блочных устройств все три должны совпадать.
Вот интересно как раз понять, как onDiskSpace считается. Хотелось бы знать не только, сколько выделено диска (это можно и из бэкенда узнать, если там, например, OpenStack или просто Ceph), но и сколько его реально используется вмкой (потому что ни один бэкенд такой информации не даст, конечно же).
Для Qcow2 — сколько файл на диске занимает, столько и выдается. А вот сколько используется VM-кой (типа df -h) — на такой вопрос ответить не получится. Насколько я понимаю, qcow2 online trim не поддерживает.
Не рассматривали вариант собирать данные через collectd? Там есть плагин для libvirt, и оно умеет само сразу писать в influx
Для collectd есть действительно плагин и я сначала смотрел именно в сторону collectd, не обнаружив вменяемой и понятной документации и пользовательского опыта решил, что проще самому написать. Опять же если посмотреть в разрезе требуемых компонентов и их настройки, данное решение выглядит достаточно простым и не содержащим внешних зависимостей (кроме Docker).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение LibVirt API, InfluxDB и Grafana для сбора и визуализации статистики выполнения VM