Советы по организации системы мониторинга

В предыдущей статье мы писали о тонкостях организации резервного копирования веб-проекта. Проработка стратегии мониторинга и дальнейшая грамотная поддержка проекта — не менее сложные процессы. В данной статье мы раскроем что и как нужно мониторить для стабильной работы веб-проекта.

Полноценная система мониторинга должна играть несколько ролей:

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

Для каждой из этих ролей есть определенные требования. Они обязательно должны выполняться для обеспечения стабильной поддержки.

 

Мониторинг как система оповещения о проблемах на сайте

Базовая роль мониторинга — это информирование о приближении проекта к критическим значениям, а также об уже случившихся проблемах, авариях, нарушении бизнес-функций проекта.

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

Система мониторинга должна максимально быстро оповещать о достижении критических показателей и авариях. Если информация о проблеме не приходит к дежурным или приходит слишком поздно, то не будет возможности принять эффективные меры по предотвращению или решению проблемы. Казалось бы, что это очевидное требование, однако речь идет не просто о быстрой доставке оповещений, но и об уверенности в том, что дежурные администраторы получат сообщение об ошибке. Прежде всего, оповещения должны приходить не только по e-mail. Если дежурных несколько, хорошо бы добавить в смс-сообщение ссылку для подтверждения получения. Если дежурный администратор не перешел по ссылке в течение нескольких минут — смс уходит следующему администратору в цепочке эскалации.

Ко всему прочему система мониторинга должна не только быстро, но и надежно оповещать о происшествиях в системе. Не сработавшее оповещение может повлечь за собой часы простоя или достижение такой ситуации, в которой для исправления проблемы придется затратить огромное количество времени. Поэтому если метрики проекта достигли критических показателей — оповещение об этом должно быть непременно сделано. Для проверки системы оповещения мы рекомендуем регулярно принудительно создавать «критические» показатели.

Что же следует «закрыть» системой мониторинга?

Очень часто в своей практике мы встречаемся с проектами, на которых мониторинг закрывает только технические показатели серверной системы. Однако на деле этим никак нельзя ограничиваться. В случае, например, ошибок в коде в новой версии сайта на сервере не будет происходить никакой нагрузки, но это совсем не означает что с проектом всё хорошо. Мы считаем, что правильная система оповещения должна проверять работоспособность трех слоев проекта:

• фиксировать проблемы на уровне сервера;
• проверять работоспособность системы на уровне приложения;
• понимать и замечать проблемы на уровне бизнес-логики приложения.

Эти три слоя позволяют максимально обеспечить уверенность в том, что с система работает именно так, как должна.

Базовым уровнем является мониторинг серверных показателей. Обязательно стоит следить за нагрузкой на CPU (создавая оповещения на Load Average, растущий больше чем число ядер в системе, и снижение CPU idle до минимальных значений), анализировать статистику по нагрузке на дисковую подсистему (увеличение времени avio, рост дисковых операций iops, рост «busy» диска), следить за использованием оперативной памяти, контролируя значение used memory, а на больших объемах памяти — значение free. Работа с памятью в Linux — тема отдельной статьи, которую мы обязательно напишем. Естественно, надо следить за использованием swap, причем не столько за изменением swap used (приложение может находиться в swap-е долгое время, но при этом не использоваться), сколько за числом swap fre, чтобы при исчерпании процессы системы не уничтожались по out of memory, и, главное, swap in/swap out — непосредственным использованием swap. Необходимо следить за показателями ПО, работающего на сервере (статистикой БД, кэшей, статистикой веб-сервера). Все эти показатели представляют собой базис от которого следует отталкиваться, но которым нельзя ограничиваться.

Следующим уровнем мониторинга является наблюдение за техническими данными самого приложения. Сюда нужно включить контроль за числом ошибок приложения (5xx и 40x ошибки в access-логах, анализ лога ошибок самого приложения) — их резкий рост может свидетельствовать о серьезных проблемах. Практически всегда в access-логах будут 404-е ошибки, но если их число стало слишком большим — возможно что-то случилось со статическими данными. Это не всегда можно быстро обнаружить при визуальном просмотре сайта, а оповещение на такую ошибку позволит среагировать своевременно. Важно собирать статистику по числу запросов к подсистемам и узлам системы — резко увеличившееся число SQL запросов к базе может означать плохую выкладку кода, падение запросов к API внешнего сервиса (который постоянно должен использоваться) возможную аварию.

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

Естественно, систему стоит проверять и снаружи. По нашему опыту, необходимо следить не только за временем ответа и кодом ответа страниц сайта, но также и за их размером — довольно часто в случае ошибки страницы сайта продолжают выдавать код ответа HTTP 200, и это очень тяжелая ситуация. Поисковый движок воспримет такую страницу как актуальную и проиндексирует ее без любых данных. Это не единственный случай, когда такая метрика может пригодиться. Очень важно собирать метрики и по статистике резервного копирования — об этом мы говорили в нашей статье про бэкапы здесь https://www.itsumma.ru/blog/5/. Таких метрик можно придумать еще довольно много, но для полного контроля необходим третий слой защиты.

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

 

Мониторинг как средство анализа

Система мониторинга не должна ограничиваться только информированием о проблемах. При достижении критических значений важно понять — в первый ли раз такая проблема случилась или она системна? Может ли система продолжить работать в таком состоянии, как скоро произойдет сама авария? Для этого система мониторинга должна содержать достаточное количество данных, которые можно проанализировать, адекватно и быстро отобразить с максимальной детализацией и иметь возможность выбрать нужный промежуток времени.

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

В идеальном случае система мониторинга как средство анализа должна предоставлять возможность сложной статистической агрегации метрик — как минимум вычисление скользящей средней, процентили, группировки серии данных по их минимуму/максимуму и другие значения.

 

Мониторинг как средство принятия решений

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

Среди внешних систем, которые мы видели и можем рекомендовать в качестве простого решения на старте, выделим SaaS-системы NewRelic, Server Density и NewRelic (при этом NewRelic, конечно же, стоит использовать также на больших и сложных проектах). Для сложного сбора данных на месте мы рекомендуем Graphite и старый-добрый Zabbix. Особо отметим российский SaaS-сервис мониторинга okmeter.io, который сейчас рекомендует огромное количество наших друзей. Мониторинг можно автоматически развернуть на веб-сервере за 5 минут, его просто настроить даже под нестандартные вещи - в этом поможет подробная документация и техподдержка сервиса. Дополнительные преимущества: Okmeter "из коробки" поддерживает сбор кучи метрик Nginx, Mysql, Postgres, Redis, Memcached и другого, и строит наглядные графики, что также важно при анализе проблем.

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