Открыть список
Как стать автором
Обновить

Мониторинг производительности веб-сервиса. Часть I

Чулан
image Чем качественней налажен процесс разработки, тем реже будут проявляться проблемы с производительностью в релизе. С другой стороны, полностью их не удастся избежать по той банальной причине, что в процессе разработки были сделаны “предположения” относительно условий эксплуатации веб-сервиса, а жизнь постоянно вносит свои коррективы.

От того как часто появляются такие проблемы и как быстро они исправляются зависит многое – удовлетворенность пользователя сервисом, репутация разработчика и т.д. Как можно бороться с проблемами производительности?

Один из сценариев – пассивная реакция, т.е. решение проблем по мере их поступления. В этом случае служба поддержки накапливает жалобы до наступления какой-то “критической массы” и затем привлекает разработчиков. Разработчики тратят некоторое время на поиск и устранение проблем, затем веб-сервис снова начинает оперативно обрабатывать задачи.

Главный недостаток такого варианта – пользователи успевают сполна “насладиться” оперативностью работы веб-сервиса, прежде чем им займутся разработчики. А ведь проблему после этого еще только предстоит найти. Еще один недостаток – разработчики должны работать по срокам “на вчера”, что тоже не впечатляет.

Другой вариант, псевдо-активная реализация. Ставятся какие-то утилиты для мониторинга всего и вся, потом главный шаман с бубном время от времени просматривает графики и пытается идентифицировать факт наличия проблемы по ним.

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

Требуется иной сценарий, который позволил бы с минимальными издержками “держать руку на пульсе” и оперативно локализовывать источник проблем.

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


Проактивный мониторинг означает две вещи:
  1. Активную нотификацию о проблемах, будь то по телефону, смс, жабберу, icq или мылу;
  2. Четкий план действий по локализации и устранению проблем.

Нотификацию удобно выстраивать на готовой системе мониторинга, коих в мире не мало. Наколеночные рассматривать не будем, ибо они – удел энтузиастов. А вот из профессиональных хотелось бы отметить cacti, nagios и zabbix. Однако под требования нотификации подходит только горячо и взаимно любимый Zabbix ( или я что-то упустил в cacti? ), а nagios не сильно приспособлен к хранению исторических данных, что весьма полезно для анализа проблем.

Использование оповещений серьезно разгрузит местных шаманов, ибо вместо того чтобы пялиться в сотни графиков сутки на пролет, достаточно носить с собой телефон в кармане. Вопрос лишь в том – что и как мониторить.

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

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

image

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

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

# Симптом Причина Реакция
1. Среднее время ожидания свободного обработчика превысило допустимое значение Наплыв пользователей Горизонтальное масштабирование
2. Среднее время чтения\передачи запроса превысило адекватное значение Мы превысили ресурсы сети Смена тарифного плана
3. Среднее время обработки запроса превысило допустимое значение Проблемы с кодом\базой\и.т.д. Пора привлекать разработчиков

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

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

Продолжение следует...
Теги:мониторингпроизводительностьвеб-сервис
Хабы: Чулан
Всего голосов 13: ↑8 и ↓5 +3
Просмотры739

Похожие публикации

Лучшие публикации за сутки