Краткий список того, что нужно контролировать на хосте виртуализации под управлением Xen'а. На полноценное «почитать» не тянет, но тем, кто с Зеном работает, будет полезно. Дополнения и уточнения приветствуются.
В заметке идёт о мониторинге именно хоста, а не запущенных на нём виртуальных машин или их сервисов.
Итак, начнём с простого:
- Пинг до хоста, доступность management ssh. Комментариев не требует.
- Сообщения ipmi/ilo иной системы менеджмента. Отлавливает MCE (аппаратные сбои процессора, материнской платы), ошибки памяти, отказы блоков питания, вентиляторов, чужие шаловливые ручки, вскрывающие корпуса и т.д. Мониторить лучше по внешним интерфейсам IPMI, хотя по бедности сойдёт и ipmitool sel list на хосте.
- Состояние dom0 (типовое):
- LA (его превышение свидетельствует о проблемах, на нормальном dom0 la не должно выходить за 0.1, больше 2-3 — проблема)
- cpu usage. Мониторить обычно дискомфортно (т.к. требует интервала замера), чаще всего реализуется через zabbix/cacti/munin
- Свободное место на разделах с логом. Например, XenServer'ы любят уходить в режим «бибикать» если на /var заканчивается место, а по умолчанию у них там на всё про всё 4Гб
- Свободную память (самого dom0). Если приложения из dom0 уйдут в своп, будет беда для всех виртуалок
- Число открытых сетевых соединений. Само значение подбирается экспериментально, не должно быть чрезмерным
- Состояние рейд-массива и жёстких дисков. Отказ или деградация дисков на хосте, даже если они используются «всего лишь» для root (то есть данные виртуалок отдельно), то тормозной /var/log может попортить нервы. Особое внимание в случае аппаратного рейда — надо найти утилиту вендора и использовать её. Софтовый рейд отлично обрабатывает mdadm, если ему почту настроить. Сами диски контролируются smartmontools или чем-то от вендора.
- Состояние xen'а:
- Число доменов — превышение некоторого числа чревато проблемами при старте следующих виртуалок. Исчерпываются loop, минорные номера для tapdisk, lvm, iscsi и т.д.
- Наличие забытых доменов. Некоторые тулстеки могут забыть домен с статусом 's' (shutdown) — если такой домен висит в списке доменов больше 1-3 секунд, значит что-то не так.
- Наличие зомби-доменов. Если домен имеет флаги d и s одновременно более секунды, значит хосту очень плохо — есть shared-страницы памяти между dom0 и доменом, и их не отдают гипервизору, то есть домен убить не получается. На моей практике это чаще всего был «плохой» tapdisk.
- Свободная память гипервизора. Нужно резервировать хотя бы 100-200 Мб памяти для гипервизора, чтобы иметь возможность использовать shadow pages и живую миграцию с хоста. Заметим, эта задача отличается от «балансировки загруженности», так как является предаварийной для самого хоста, то есть должна мониториться независимо.
- Наличие на хосте (более секунды) доменов с uuid 00000000-0000-0000-0000-000000000000 (ошибка инициализации домена) или с uuid, начинающимся на deadbeaf-dead-beaf-… (признак сбоя в xapi. Свинский метод кодировать ошибку, но наблюдение за ним нужно)).
- Наличие посторонних (новых) сообщений в console ring зена. Наличие там чего-либо обычно свидетельствует о проблемах или хулиганстве с гостей (например, попытка записать MSR)
- Состояние сервисов dom0
- Расхождение времени ntpd с референсным. Расхождение более чем на 0.2с (цифру подобрать в зависимости от качества сети) свидетельствует о проблемах и может напрямую сказаться на гостях, у которых время тоже поползёт.
- Размер arp-таблицы. Если она слишком большая, это может значительно ухудшить работу SAN, приводя к постоянному перезапросу ARP, то есть дисковым лагам у гостей.
- Загруженности сетевых интерфейсов, использующихся для management/san. Если оно выше некоторого предела (для SAN — выше 30-40%), это свидетельствует о потенциальном источнике тормозов. Речь про 10-20G, так как на гигабите интерфейс так или иначе будет периодически утыкаться в оный гигабит
- Актуальность всех SSL-сертификатов. В отличие от «ой, API сервера не доступно» эта проверка позволяет сказать «WARNING, через месяц сертификат протухнет».
- Для тулстеков, поддерживающих глубину очереди (xapi) — размер оной очереди. 30-50 задач в очереди обычно признак проблем. Заодно, такая проверка проверяет и связность слейвов и мастера — т.е. проверку лучше делать на слейвах.
- Мониторинг dmesg. Чаще всего это делается grep'ом, причём не на хосте, а за его пределами. Отправка логов через syslog и netconsole для отправки dmesg — обязательная практика. Мониторинг грепом выглядит несолидно, но лучше фиговое сообщение, чем архитектурно совершенное замалчивание проблемы.
- Трейсы ядра. Причины бывают разные — чаще всего это OOM, затык с IO и т.д. Само появление трейса в dmesg гостя — однозначный признак проблемы
- Segmentation fault. Внутри dom0 не может быть пользовательских программ, а любая падающая программа, это либо сбой, либо будущий exploit.
- Наличие симптомов флапа (link down/link up) сетевых интерфейсов. Если интерфейс начал флапать — его надо срочно выводить из эксплуатации и выяснять, кто виноват. Бывает так, что флапы могут идти долгое время, не обнаруживаемые никем, а в это время проблема прогрессирует. Может быть плохо кабель воткнут, может быть SFP или сетевая карта умирают.
- Сообщение о таймаутах NFS/ISCSI, переключении путей multipath (или что там у вас используется в SAN). Часть таймаутов бывает «мягкая», то есть до гостей не доходит. Но знать о них надо. Точный тип сообщения выявляется экспериментально (погасите тестовую СХД и созерцайте)
- Мониторинг параметров СХД. Эта область сильно выходит за «Xen», так что назову только самый минимум, который имеет отношение к обслуживанию xen'а (то есть не будут обсуждаться мониторинг дисков, состояния массивов, интерконнектов, замкнутость петель SAS и т.д.):
- Мониторинг latency на экспортируемых лунах/томах/каталогах. Выставите себе некую разумную линию (5-10мс) и следите — как только 95% персентиль (то есть 5% запросов) выползет за эту линию — это однозначный признак будущих проблем
- Мониторинг IOPS'ов. Мониторить или нет максимум — это дело хозяйское, но что надо мониторить минимум — это однозначно. Если у вас на СХД с 25к IOPS нагрузка упала до 200 IOPS — обязательно нужно выяснить почему.
- Число активных подключений с хостов. Изменение этой величины в отсутствие технических работ или ввода/вывода хостов в эксплуатацию — признак проблем (о которых, быть может, хост и не подозревает ещё)
- Утилизация места. Игры с thin provision, oversubscription, deduplication, compression, и другими технологиями экономии места может больно ударить, если не следить за выполнимостью обещаний.
Автор: amarao
