Правильный мониторинг

Игорь Грегорченко

05.09.2020 23:38

Любое Web приложение постоянно изменяется. Как с точки зрения внутренностей (новые функции и технологии), так и с точки зрения внешних условий (размер и активность аудитории). Качественная работа приложения критически зависит от правильной и своевременной диагностики. Динамика Web приложений переводит диагностику на новый — постоянный уровень. Важно не просто знать максимум о системе. Важно еще и узнавать об изменениях максимально быстро. Это задача мониторинга.

Существует три основные компоненты системы мониторинга:

Статусный мониторинг. Проверка нормальной работы компонент.
Мониторинг тенденций. Сбор изменений в показателях и их последующая аналитика.
Бизнес мониторинг. Наблюдение за отклонениями в бизнес показателях.

Статусный мониторинг

Задача мониторинга статусов — постоянно проверять все компоненты системы на корректность их работы.

Например:

Работает ли база данных MySQL.
Есть ли свободное место на жестком диске.
Корректно ли отвечает Nginx на запросы.

Наиболее популярные решения:

Monit — самый простой выбор. Умеет не только делать проверки, но и выполнять определенные действия в аварийных ситуациях (например, может попытаться запустить упавший процесс). Хорошо подойдет для небольших проектов.
Nagios — монстрелло. Умеет все. Если в Вашей системе больше нескольких десятков компонент, переключайтесь на него.

Основное правило настройки мониторинга — проверять как можно больше показателей системы. Тут работает правило — чем больше знаем, тем лучше.

Уведомления

Главная задача статусного мониторинга — сообщать о проблемах. На практике это обычно письмо либо СМС сообщение в случае поломки. От правильной настройки уведомлений на 90% зависит эффективность работы мониторинга.

Прежде всего, очень полезно иметь дашборд с выведенными туда максимально приоритетными метриками. Чаще всего это доступность Web сервера, баз данных и бекендов. Т.е. тех узлов, которые непосредственно отвечают за генерацию ответа на запрос пользователя.

Настройка уведомлений обычно происходит по такому принципу:

1. Выбор параметра. Не на все параметры нужно настраивать уведомления. Некоторые из них основные (например, доступность Web сервера). Некоторые вспомогательные (например, количество открытых файловых дескрипторов).

2. Определение приоритета. Следует выделять две группы параметров:

Высокий приоритет — критичные проблемы. Сюда должно попасть около 5% показателей — тех, при отклонении которых наступит катастрофа. Обычно это — доступность всех узлов (ping), показатель загрузки процессора, свободное место в оперативной памяти и на диске.
Низкий приоритет — проблемы, на которые следует обратить внимание. Это остальные метрики, которые могут вызвать серьезные проблемы, если на них не отреагировать в течение ближайшего времени.

3. Определение порога срабатывания. Для многих метрик следует выбирать два порога срабатывания — один предупреждающий (низкий приоритет, например свободного места на диске осталось 10%), второй — требующий мгновенной реакции (высокий приоритет, свободного места 1%).

Настройка уведомлений — это не одноразовая работа. Этим следует заниматься постоянно, т.к. меняются приоритеты и появляются новые метрики. Соблюдайте правила:

Избегайте слепоты. Если Вы несколько раз подряд получили уведомление и никак на него не отреагировали, уведомление нужно отключить.
Избегайте потока. Система мониторинга должна отвлекать Вас по важным делам, а не слать дайджесты о десятках проблем, которые не мешало бы поправить.
Используйте разные механизмы уведомлений. Например, СМС только для самых важных случаев. Почтовые сообщения — для средней важности. Журнал в Web интерфейсе либо отдельный почтовый ящик — для уведомлений малой важности.
Включайте уведомление, если сомневаетесь. Лучше убедиться, что уведомление бесполезно и отключить его позже.
Учитывайте разброс значений. Мониторинг таких показателей, как Load Average может стать проблемой. Этот показатель может выскакивать за установленные пределы несколько раз в день просто по причине характера нагрузок. Повышайте постепенно порог, чтобы добиться полезности уведомления.

Делайте постоянную проверку самой системы уведомлений. Иногда может поломаться отправка почты, либо на СМС-шлюзе закончится депозит. Обязательно настройте проверку доставки уведомлений с помощью запасной системы мониторинга.

Мониторинг тенденций

Знания текущего статуса работы системы недостаточно для того, чтобы делать прогнозы. Ясно, что проблему лучше предупреждать, чем реагировать на нее. Для этого нужны системы сбора и хранения исторических данных об изменении показателей. Такие системы работают так же, как и статусные, но обычно собирают намного больше показателей и хранят всю историю их изменений.

Наиболее популярными решениями являются:

Munin — простой инструмент с самым большим репозиторием готовых плагинов.

Cacti — продвинутая система работы с графиками включая zoom.
Collectd — производительнее своих конкурентов, рассчитан на огромное количество данных.

Аналитика и прогнозы

Аналитика исторических данных позволит прогнозировать необходимость масштабирования. Кроме обычных метрик, таких как загрузка процессора и объем доступной памяти, сюда следует включать показатели более высокого уровня, например:

Количество запросов в секунду на Nginx, php, MySQL и т.п.
Количество потоков и процессов.

Размеры очередей (например, на почтовом сервере или системе задач).
Время генерации страниц сайта.

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

Бизнес метрики и Real time трекинг

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

Именно поэтому есть необходимость в мониторинге бизнес метрик. Многие системы аналитики, такие как Google Analytics позволяют проводить детальнейший анализ исторических данных. Однако такие инструменты неудобно использовать для обнаружения отклонений в реальном времени.

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

...
# вставка данных нового пользователя
mysql_query('INSERT INTO users SET email = ...');
$user_id = mysql_insert_id();

# трекинг регистраций
track('signups');
...

Пример интерфейса ioTrack для [Хд]

Распространенными примерами метрик бизнес уровня являются:

Активность аудитории (количество посещений/просмотров).
Скорость работы приложения (время загрузки страниц).
Регистрации/покупки/комментарии/другие действия.
Конверсии различных величин (например, конверсия рекламных кампаний в регистрации).
Метрики высокого уровня, связанные с бизнес логикой (например, количество обработанных фотографий).

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

Очень удобно выводить несколько основных величин в дашборды на отдельных мониторах в офисе. Позволяет не только быть в курсе проблем, но и получать “живую” информацию о качестве работы приложения.

Самое важное

Помните, задача мониторинга — предоставлять информацию о сбоях в работе. Она не выполняется разово, изменения должны внедряться вместе с изменениями самого приложения.

Прежде всего, организуйте наблюдение за бизнес метриками. Мониторинг тенденций позволит прогнозировать изменения в оборудовании и избегать катастроф. Мониторинг статуса — это Ваша служба 911, мерой ее эффективности является полезность уведомлений.