Мониторинг KeyVRM¶
Для анализа состояния гипервизоров и ВМ KeyVRM использует инфраструктурные метрики. При определенных условиях работы алгоритмов HA, LB и Executor сервис отправляет событийные оповещения в Alertmanager.
Наличие метрик и оповещений не гарантирует успешное выполнение миграции или эвакуации. Проверяйте состояние событий, рекомендаций, операций и фактическое состояние инфраструктуры.
Источники данных мониторинга¶
Для принятия решений KeyVRM получает метрики CPU, RAM, сетевой нагрузки, HugePages и состояния интерфейсов через Prometheus-совместимый API настроенной системы мониторинга.
Heartbeat гипервизоров поступает из Redis Sentinel. Состояние вычислительных сервисов, виртуальных машин и ресурсов размещения KeyVRM получает из OpenStack.
При отсутствии необходимых метрик HA или LB могут не сформировать рекомендации. Отсутствие рекомендаций само по себе не означает, что перегрузки или отказов нет.
Адрес источника метрик KeyVRM получает автоматически при развертывании. Для расчета сетевой нагрузки используется интерфейс, указанный в параметре neutron_external_interface файла globals.d/REGION.yml репозитория региона. Подробнее см. раздел Создание региона.
Собственного компонента для экспорта метрик у KeyVRM нет: сервис использует метрики, уже собранные системой мониторинга.
Оповещения KeyVRM¶
Настройки отправки оповещений в Alertmanager задаются автоматически при развертывании KeyVRM.
Маршрутизация, группировка, подавление и доставка оповещений получателям настраиваются в Alertmanager. Подробнее см. Сервис управления алертами.
Каталог действующих оповещений¶
KeyVRM формирует следующие десять видов событийных оповещений.
Оповещение |
Уровень |
Условие и действия |
|---|---|---|
|
|
Обнаружена перегрузка и доступны минимум два расчетных гипервизора после исключения занятых узлов и узлов без метрик. Оповещение отправляется до подбора миграций. Проверьте событие, показатели нагрузки, пороги и наличие сформированных рекомендаций. |
|
|
Обнаружена перегрузка, но для расчета доступно менее двух гипервизоров. LB-событие завершается с состоянием Проверьте состав хост-агрегата, активные операции и полноту метрик. |
|
|
Очередь целевых гипервизоров исчерпана, и ни одна рекомендация не сформирована. Причиной могут быть ограничения фильтров, а не только недостаток физических ресурсов. Проверьте список целей, фильтры, доступные ресурсы и ограничения нагрузки. |
|
|
Очередь целей исчерпана после создания хотя бы одной рекомендации. Оповещение относится к частичному планированию, а не к успешному выполнению миграций. Проверьте результаты рекомендаций и фактическую нагрузку исходных гипервизоров. |
|
|
Алгоритм завершил перебор источников без рекомендаций, не завершившись ранее по условию Проверьте ограничения для ВМ, которые рассматривались для переноса. |
|
|
Один или несколько гипервизоров не прошли все включенные этапы фенсинга. Неуспешно обработанные узлы исключаются из эвакуации в текущем проходе. Проверьте результаты Ceph-, BMC- и Nova-фенсинга и фактическую изоляцию узлов. |
|
|
На этапе подбора ВМ отсутствуют потенциальные цели либо фильтры не разрешили размещение рассматриваемых ВМ. Оповещение отправляется до окончательной проверки ресурсного бюджета HA. Проверьте список целей, состояния гипервизоров, фильтры, запреты эвакуации и отдельно доступные ресурсы. |
|
|
Фенсинг завершен, на исходных гипервизорах есть ВМ и после фильтрации обнаружены потенциальные цели. Оповещение отправляется до окончательного создания рекомендаций с учетом ресурсов. Проверьте сформированные рекомендации, ресурсные ограничения и результаты операций Nova. |
|
|
По сигналу неисправности включенной категории интерфейсов выбран гипервизор для обработки HA. Оповещение отправляется до фенсинга. Проверьте состояние интерфейсов и соответствующие метрики мониторинга. Для Fibre Channel используется метрика |
|
|
Количество совпадающих ошибок в сохраненной истории рекомендации достигло значения Проверьте историю операций рекомендации, тип ошибки, внешние запросы и фактическое состояние ВМ. |
Оповещение HA_EvacuationStarted не подтверждает успешную эвакуацию, а LB_PartialSuccess — выполнение запланированных миграций.
RecommendationFailed не отправляется автоматически при любой финальной ошибке рекомендации. Для его отправки должно выполниться условие повторяющихся ошибок.
Поля оповещений¶
Для фильтрации оповещений KeyVRM в Alertmanager используйте label job со значением KeyVRM Service.
Дополнительные labels зависят от вида оповещения:
Оповещения |
Дополнительные labels |
|---|---|
Оповещения с префиксом |
|
|
|
|
|
|
|
В оповещении HA_FailedInterfaces label azone отсутствует.
В оповещении RecommendationFailed идентификаторы рекомендации и события передаются в description.
Поле failure_type может иметь значения port_binding, volume_attachment, ephemeral_disk или unknown, если тип ошибки не определен.
Пример оповещения¶
На рисунке показано оповещение HA_NoEvacuationTargets в Alertmanager.
Оповещение HA_NoEvacuationTargets в Alertmanager¶
Проверка состояния и диагностика¶
При получении оповещения проверьте:
Идентификаторы хост-агрегата, события, рекомендации и ВМ, если они доступны в оповещении.
Состояние события, список рекомендаций и историю операций KeyVRM.
Состояние исходного и целевого гипервизоров, доступность Nova и других задействованных сервисов.
Полноту метрик в настроенной системе мониторинга и наличие heartbeat гипервизоров.
Результаты миграции или эвакуации в Nova, а при необходимости — состояние дисков и сети.
Фактическое размещение ВМ и работоспособность гостевой ОС и приложения.
Проверка событий и рекомендаций описана в разделе Диагностика.
Если ожидаемое оповещение отсутствует, проверьте журналы KeyVRM на наличие ошибок доставки.
Учитывайте, что отдельные ошибки не обязательно сопровождаются событийными оповещениями KeyVRM. К таким ситуациям относятся:
отсутствие включенных механизмов фенсинга;
исчерпание общего количества попыток Executor;
отсутствие необходимых метрик;
ошибка инициализации LB при смешении ВМ с HugePages и обычных ВМ;
ошибка перевода гипервизора в режим обслуживания.
Отсутствие оповещений не подтверждает исправность KeyVRM.
Для проверки готовности сервиса недостаточно доступности API. Дополнительно проверьте работу worker и Temporal, подключение к PostgreSQL и OpenStack, поступление метрик и heartbeat и доступность средств фенсинга.
После восстановления работоспособности проверьте следующие проходы KeyVRM, появление рекомендаций при выполнении условий HA или LB, результаты их исполнения и фактическое состояние инфраструктуры.