Pull to refresh

Мониторинг Хen'а в продакшене

Reading time 4 min
Views 11K
Краткий список того, что нужно контролировать на хосте виртуализации под управлением Xen'а. На полноценное «почитать» не тянет, но тем, кто с Зеном работает, будет полезно. Дополнения и уточнения приветствуются.

В заметке идёт о мониторинге именно хоста, а не запущенных на нём виртуальных машин или их сервисов.

Итак, начнём с простого:

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

  • Мониторинг параметров СХД. Эта область сильно выходит за «Xen», так что назову только самый минимум, который имеет отношение к обслуживанию xen'а (то есть не будут обсуждаться мониторинг дисков, состояния массивов, интерконнектов, замкнутость петель SAS и т.д.):
    1. Мониторинг latency на экспортируемых лунах/томах/каталогах. Выставите себе некую разумную линию (5-10мс) и следите — как только 95% персентиль (то есть 5% запросов) выползет за эту линию — это однозначный признак будущих проблем
    2. Мониторинг IOPS'ов. Мониторить или нет максимум — это дело хозяйское, но что надо мониторить минимум — это однозначно. Если у вас на СХД с 25к IOPS нагрузка упала до 200 IOPS — обязательно нужно выяснить почему.
    3. Число активных подключений с хостов. Изменение этой величины в отсутствие технических работ или ввода/вывода хостов в эксплуатацию — признак проблем (о которых, быть может, хост и не подозревает ещё)
    4. Утилизация места. Игры с thin provision, oversubscription, deduplication, compression, и другими технологиями экономии места может больно ударить, если не следить за выполнимостью обещаний.
Tags:
Hubs:
+15
Comments 8
Comments Comments 8

Articles