Мониторинг распределенной и облачной инфраструктуры

В прошлой статье я обзорно прошелся по различным типам мониторинга простых веб-проектов и веб-сайтов, когда от сайта не требуется уровня надежности 99,99%, когда время реакции может составлять часы или дни. В общем, когда все просто. В этой статье я раскрою механизмы мониторинга облачной инфраструктуры, когда простого сигнала доступен/не доступен совсем не достаточно, чтобы понять, в чем проблемы, и как их оперативно решить. Или же когда решение проблемы может требовать большого количества действий, автоматизировать которые можно только частично.

Обычно уровень надежности инфраструктуры проекта позволяет оставить время реакции на возникшие проблемы таким же — часы или даже дни. Но при этом есть ряд мест, решения по которым должны приниматься в (полу)автоматическом режиме, чтобы исключить человеческий фактор и свести время простоя системы к минимуму. О триггерах таких решений речь пойдет ниже. Хочу сразу отметить, что почти все описанные технологии мониторинга используются в новом облачном сервисе социального интранета - Битрикс24.

Мало не бывает

При построении отказоустойчивой распределенной инфраструктуры кроме обеспечения нескольких уровней надежности обычно закладывают и несколько уровней мониторинга системы. Среди них можно выделить:

• Встроенный мониторинг, выдающий данные о физических параметрах серверов (операции с диском, с памятью, загруженность процессора, сети, системы и т.д.). В качестве решения часто используется Munin (на Хабре о нем уже много писали) с большим набором плагинов, которые позволяют контролировать каждую проблемную точку. Плагины, по сути, — это консольные скрипты, которые проверяют определенный параметр системы с заданной периодичностью. Теоретически, уже на этом уровне можно использовать триггерный механизм, чтобы проводить «разгружающие» действия с сервером. Но на практике для принятия решений используется следующий уровень мониторинга, встроенный мониторинг используется только для сбора статистики и анализа параметров системы «изнутри».
• Внутренний мониторинг подразумевает профилактику состояния всей иинфраструктуры или ее части на уровне самой инфраструктуры. Это означает, что наряду с рабочими серверами (приложений, базы данных) в системе должны быть сервера, мониторяющие ее состояние и передающие эту информации (в критических случаях) по адресу (например, рассылающие уведомления по смс, или производящие запуск новых серверов приложений, или записывающие информации о рабочих серверах приложений на балансировщик). Наиболее часто используемое решение здесь — это Nagios (статьи на Хабре) с большим количеством проверок (несколько сотен или тысяч обычно). Дополнительно к нему подключают еще Pinba (Хабр) в случае PHP-приложений для более точного анализа проблем.
• Обычно двух предыдущих уровней мониторинга бывает достаточно для обнаружения и решения всех проблем с инфраструктурой, но часто (в случае использования облаков) присутствует еще мониторинг промежуточный, когда идет как мониторинг состояния всех серверов инфраструктуры, так анализ всех запросов, проходящих через выделенные в облаке мощности. Промежуточный мониторинг используют как дополнительный уровень контроля качества работы сервиса (например, легко отслеживать количество 500 ошибок, даже если сервера приложений работают в штатном режиме) и принимать решение о переключении мощностей между гео-кластерам (например, такое возможно у Amazon).
• Наконец, внешний мониторинг используется для анализа ситуации со стороны пользователей. Даже если система работает исправно, связность между серверами не нарушена, сервера отвечают быстро и стабильно, пользователи могут ощущать проблемы с использованием сервиса, и это будет зависеть от общего состояния Сети. На этом уровне возможны дополнительные триггеры для принятия решения о переключения пользователей на другие гео-кластеры (например, европейских пользователей Битрикс24 вести на европейский датацентр, а американских - на американский) для улучшения качества сервиса. Также этот уровень мониторинга может использоваться для дополнительной проверки результатов внутреннего и промежуточного мониторинга.

Встроенный мониторинг

Munin выдает большое количество информации о состоянии требуемого сервера. К наиболее часто проверяемым моментам относят:

• Проверка PHP (время выполнения, использование памяти, число хитов на 1 процесс и т.д.)
• Проверка nginx (коды ответов, использование памяти, число процессов)
• Проверка mysql (число запросов, использование памяти, время выполнение запросов)
• Проверка диска
• Проверка почтового демона
• Проверка сети
• Проверка системы

Немного картинок мониторинга реальной системы (загрузка и база данных)

Для примера, скрипт проверки свободного места в InnoDB таблице MySQL

## Tunable parameters with defaults
MYSQL="${mysql:-/usr/bin/mysql}"
MYSQLOPTS="${mysqlopts:---user=munin --password=munin --host=localhost}"

WARNING=${warning:-2147483648}   # 2GB
CRITICAL=${critical:-1073741824} # 1GB

## No user serviceable parts below
if [ "$1" = "config" ]; then
    echo 'graph_title MySQL InnoDB free tablespace'
    echo 'graph_args --base 1024'
    echo 'graph_vlabel Bytes'
    echo 'graph_category mysql'
    echo 'graph_info Amount of free bytes in the InnoDB tablespace'
    echo 'free.label Bytes free'
    echo 'free.type GAUGE'
    echo 'free.min 0'
    echo 'free.warning' $WARNING:
    echo 'free.critical' $CRITICAL:
    exit 0
fi

# Get freespace from mysql
freespace=$($MYSQL $MYSQLOPTS --batch --skip-column-names --execute        \
    "SELECT table_comment FROM tables WHERE TABLE_SCHEMA = 'munin_innodb'" \
    information_schema);
retval=$?

# Sanity checks
if (( retval > 0 )); then
    echo "Error: mysql command returned status $retval" 1>&2
    exit -1
fi
if [ -z "$freespace" ]; then
    echo "Error: mysql command returned no output" 1>&2
    exit -1
fi

# Return freespace
echo $freespace | awk '/InnoDB free:/ {print "free.value", $3 * 1024}'

Большой список популярных плагинов можно найти в GIT-репозитории

Внутренний мониторинг

Nagios как решение для мониторинга безусловно хорош. Но нужно быть готовым к тому, что кроме него придется использовать еще собственные скрипты и(ли) Pinba (или аналогичное решения дл вашего языка программирования). Pinba оперирует UDP-пакетами и собирает информацию о времени выполнения скриптов, объеме памяти и кодах ошибок. В принципе, этого достаточно для создания полной картины происходящего и обеспечения требуемого уровня надежности сервиса в автоматическом режиме.

На уровне внутреннего мониторинга уже можно принимать решения о выделении дополнительных мощностей (если это возможно автоматически — то достаточно просто отслеживать средний уровень загрузки процессора на серверах приложений или базы данных, если это производится в ручном режиме — то можно высылать письма или jabber-сообщения) или их отключении. Также в случае возникновения аномального количества ошибок (обычно это происходит при отказе оборудования либо ошибки в новой версии веб-сервиса, и что является причиной, всегда можно установить за счет дополнительных проверок) можно слать уже экстренные уведомления по смс или звонить по телефону.

Также очень удобно настроить автоматическое добавление (или удаление) тестов при увеличении точек проверки (например, серверов ли пользовательских сайтов) с заданными шаблонами: например, проверка главной страницы, распределение времени выполнения PHP, распределение использования памяти для PHP, число nginx и PHP ошибок.

Промежуточный мониторинг

Мониторинг на уровне облачной инфраструктуры предлагает не такое большое количество провайдеров, и он является, скорее, информационным: реальные решения принимаются либо на основе внутренних данных, либо внешнего состояния системы. На промежуточном уровне можно только собирать статистику или подтверждать внутреннее состояние инфраструктуры.

Для Amazon (CloudWatch) здесь доступны следующие возможности проверки:

• Полный трафик (по инстансам и совокупный).
• Число ответов с балансировщика.
• Состояние инстансов (в том числе и инфраструктурных, которые производят внутренний мониторинг).
• И ряд других, которые можно комбинировать со внутренними, но лучше максимум логики оставить все же на уровне внутреннего мониторинга.

Уже по результатам мониторинга промежуточного (на уровне балансировщиков) можно принимать обоснованное решение о выделении или закрытии машин (инстансов) в кластере. Именно так и делается в Битрикс24: как только состояние загруженности серверов приложений становится слишком большой (больше 60%), то начинают запускаться новые инстансы. И наоборот, при снижени нагрузк меньше 40% инстансы закрываются.

Внешний мониторинг

Здесь выбор решений очень большой. Если требуется отслеживать состояние серверов по всему миру, то лучшее решение — это Pingdom. Для российских реалий подойдет PingAdmin или WEBO Pulsar (у них есть сеть серверов по России). Особенно удобно настроить проверку из нескольких точек (например, Москва+Санкт-Петербург) и дергать удаленный скрипт уведомления, если сервис не доступен в течение 1-2 минут. Если при этом есть какие-либо проблемы внутри, то можно сразу переключаться на план «Б» (выключать неработающие сервера, сыпать уведомлениями и т.д.).

К дополнительным плюсам внешнего мониторинга можно отнести проверку реального времени ответа на стороне сервера (или реальных сетевых задержек). По этому параметру также можно настроить уведомления. Как дополнительная возможность в случае использования CDN: можно отслеживать полное время загрузки страниц сервиса и отключать или включать CDN для разных регионов.

P.S. статья обзорная, больше про архитектуру мониторинга крупных проектов. О конкретных прикладных вещах расскажу в следующих статьях.

Все комментарии (habrahabr.ru)