Краткий список того, что необходимо отслеживать на хосте виртуализации, на котором работает Xen. Полноценным «чтением» не является, но будет полезно тем, кто работает с Дзеном.
Дополнения и уточнения приветствуются.
Примечание касается мониторинга самого хоста, а не виртуальных машин или их служб, работающих на нем.
Итак, начнем с простого:
- Пинг до хоста, управление доступностью ssh. Никаких комментариев не требуется.
- ipmi/ilo сообщения из другой системы управления.
Отлавливает MCE (аппаратные сбои процессора, материнской платы), ошибки памяти, сбои блоков питания, вентиляторов, чужие шаловливые руки, открывающие корпуса и т.д. Мониторинг лучше осуществлять через внешние интерфейсы IPMI, хотя ipmitool sel list на хосте будет делай все хорошо.
- Статус dom0 (типичный):
- LA (превышение его указывает на проблемы, на нормальном dom0 la не должно выходить за пределы 0,1, больше 2-3 - проблема)
- использование процессора.
Мониторинг обычно неудобен (потому что требует интервала измерения), чаще всего реализуется через zabbix/cacti/munin
- Свободное место на разделах журналов.
Например, XenServers любят переходить в режим «бип», если в /var заканчивается место, но по умолчанию у них есть 4 ГБ для всего.
- Свободная память (сам dom0).
Если приложения из dom0 уйдут в своп, то беда будет у всех виртуальных машин
- Количество открытых сетевых подключений.
Само значение подбирается экспериментально и не должно быть чрезмерным.
- Состояние рейд-массива и жестких дисков.
Выход из строя или деградация дисков на хосте, даже если они используются «только» под root (то есть данные с виртуальных машин отдельно), то медленный /var/log может испортить вам нервы.
Особое внимание в случае аппаратного рейда – нужно найти утилиту вендора и воспользоваться ею.
Мягкий рейд прекрасно обрабатывает mdadm, если вы настроите для него почту.
Сами диски управляются smartmontools или чем-то от производителя.
- Статус Зена:
- Количество доменов — превышение определенного количества может вызвать проблемы при запуске последующих виртуальных машин.
Цикл, младшие номера для Tapdisk, lvm, iscsi и т. д. исчерпаны.
- Наличие забытых доменов.
Некоторые тулстеки могут забыть домен со статусом 's' (shutdown) - если такой домен висит в списке доменов более 1-3 секунд, значит что-то не так.
- Наличие зомби-доменов.
Если у домена одновременно более секунды присутствуют флаги d и s, то хост находится в очень плохой ситуации — между dom0 и доменом есть общие страницы памяти, и они не отдаются гипервизору, то есть Домен невозможно убить.
В моей практике чаще всего это был «плохой» тапдиск.
- Свободная память гипервизора.
Вам необходимо зарезервировать не менее 100-200 МБ памяти, чтобы гипервизор мог использовать теневые страницы и живую миграцию с хоста.
Обратите внимание, что эта задача отличается от «балансировки нагрузки», поскольку она является предотказной для самого хоста, то есть ее необходимо контролировать самостоятельно.
- Наличие на хосте (более секунды) доменов с uuid 00000000-0000-0000-0000-0000000000000 (ошибка инициализации домена) или с uuid, начинающимся с Deadbeaf-dead-beaf-.
(признак сбоя в работе xapi .
Плохой метод кодирования ошибки, но наблюдение за ним нужно)).
- Наличие посторонних (новых) сообщений в консоли звонка Дзен.
Наличие чего-либо там обычно указывает на проблемы или издевательства над гостями (например, попытка записать MSR)
- Количество доменов — превышение определенного количества может вызвать проблемы при запуске последующих виртуальных машин.
- Статус сервисов dom0
- Разница между временем ntpd и эталонным временем.
Расхождение более 0,2 с (выберите цифру в зависимости от качества сети) указывает на проблемы и может напрямую повлиять на гостей, время которых также будет увеличиваться.
- Размер стола Arp. Если он слишком велик, это может существенно ухудшить производительность SAN, что приведет к постоянным повторным запросам ARP, то есть к лагам диска у гостей.
- Перегруженность сетевых интерфейсов, используемых для управления/сан.
Если он выше определенного предела (для SAN — выше 30-40%), это указывает на потенциальный источник тормозов.
Речь идет о 10-20G, так как на гигабите интерфейс так или иначе периодически будет упираться в этот гигабит
- Релевантность всех сертификатов SSL. В отличие от «ой, API сервера недоступен», эта проверка позволяет сказать «ВНИМАНИЕ, через месяц сертификат испортится».
- Для стеков инструментов, поддерживающих глубину очереди (xapi) — размер этой очереди.
30-50 задач в очереди обычно признак проблем.
При этом при такой проверке проверяется и связность слейвов и мастера - т.е.
лучше проверять на слейвах.
- Разница между временем ntpd и эталонным временем.
- dmesg-мониторинг.
Чаще всего это делается с помощью grep, причем не на хосте, а вне его.
Отправка журналов через системный журнал и сетевую консоль для отправки dmesg является обязательной практикой.
Мониторинг с помощью grep выглядит недостойно, но дрянное сообщение лучше, чем архитектурно идеальное замалчивание проблемы.
- Следы ядра.
Причины могут быть разные - чаще всего это ООМ, проблема с IO и т.п.
Само появление следа в dmesg гостя - явный признак проблемы
- Ошибка сегментации.
Внутри dom0 не может быть пользовательских программ, и любая программа, которая выходит из строя, является либо сбоем, либо будущим эксплойтом.
- Наличие симптомов провала (соединение не работает/подключается) сетевых интерфейсов.
Если интерфейс начал глючить, его нужно срочно выводить из строя и выяснять, кто виноват. Бывает, что закрылки могут долго работать, никем не обнаруживаясь, и за это время проблема прогрессирует. Возможно, кабель плохо подключен, либо SFP или сетевая карта вышли из строя.
- Сообщение о таймаутах NFS/ISCSI, переключении многопутевых путей (или о том, что вы используете в SAN).
Некоторые таймауты являются «мягкими», то есть до гостей не доходят. Но о них нужно знать.
Точный тип сообщения выявляется экспериментальным путем (выключите тестовую систему хранения и созерцайте)
- Следы ядра.
- Мониторинг параметров системы хранения.
Эта область выходит далеко за рамки «Xen», поэтому я назову лишь самый минимум, который связан с обслуживанием Xen (то есть мониторинг дисков, состояния массивов, межсоединений, замкнутых шлейфов SAS и т.п.
обсуждаться не будет):
- Мониторинг задержки на экспортированных лунах/томах/каталогах.
Установите себе какую-то разумную черту (5-10мс) и наблюдайте — как только 95%-ный перцентиль (то есть 5% запросов) выйдет за эту черту — это явный признак будущих проблем.
- Мониторинг IOPS. Следить или нет за максимумом – дело владельца, а вот что нужно следить за минимумом – понятно.
Если нагрузка на вашу СХД с 25k IOPS упала до 200 IOPS, вам обязательно нужно выяснить, почему.
- Количество активных подключений от хостов.
Изменение этого значения при отсутствии технических работ или вводе хостов в эксплуатацию является признаком проблем (о которых, возможно, хост еще не подозревает)
- Распоряжение пространством.
Игры с тонким обеспечением, избыточной подпиской, дедупликацией, сжатием и другими технологиями экономии места могут пострадать, если вы не выполняете обещания.
- Мониторинг задержки на экспортированных лунах/томах/каталогах.
-
Создайте Свой Собственный Мобильный Веб-Сайт
19 Oct, 24 -
«Яндекс.такси» Запустили В Ульяновске
19 Oct, 24 -
От Ста До Пятисот Цифр Числа Пи На Колене
19 Oct, 24 -
Управленческая Истерия
19 Oct, 24 -
Отчеты Второй Волны Techdays.ru
19 Oct, 24 -
Коворкинг В Минске!
19 Oct, 24
