Сбор расширенной статистики работы апстрима с помощью nginx-sla

Введение

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

Измерить качество обслуживания напрямую мы, конечно, не можем, однако даже такую эфемерную величину в принципе можно свести к набору количественных характеристик, так или иначе косвенно отражающихся на качестве. Прибыль, число клиентов, процент конвертированных лидов (leads – зарегистрировавшиеся или заинтересованные пользователи) и т.д. – все это вполне объективные показатели. Кроме того, эти величины могут быть включены в систему контроля эффективности работы в качестве KPI – ключевых показателей эффективности.

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

Анализ отклика и HTTP-кодов удобно проводить на основе некоторой собранной статистической базы, и здесь мы плавно подходим к теме статьи.

Что и зачем измеряем

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

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

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

Таким образом, статистику следует собирать по двум базовым параметрам:

1. Время отклика апстрима на запрос.
   Анализируя статистику по этому параметру, мы не только сможем оценить общее быстродействие апстрима, но и выявить те или иные паттерны (закономерности) в изменении нагрузки, варьировании среднего времени ответа в различное время суток и т.д.
2. Код HTTP-ответа
   Понятно, что выявить и устранить все ошибки не удастся – кривые внешние ссылки еще никто не отменял. Однако стремиться к уменьшению числа ошибок, несомненно, стоит. Сохраняться и анализироваться должны как «средняя температура по больнице» (коды 2xx, 4xx), так и точный расклад по всем HTTP-кодам. Преобладание, например, кодов 5xx в статистике укажет на нашу ошибку (а значит, на снижение качества приложения), которую нужно исправить.

Особенности измерения

При анализе времени отклика неплохо было бы учитывать характер запроса, обрабатывая и анализируя статистику по различным видам запросов отдельно. Действительно, тяжелый SQL-запрос может значительно увеличить время формирования страницы, тогда как мелкие AJAX запросы, выполняемые пользователями, лишь незначительно «загружают» апстрим. В этой связи наиболее целесообразно было бы выделить категории запросов с различным предельным временем отклика, например:

• AJAX запрос – 200мс
• Генерация страницы – 1с
• Ошибка – 5с
• Timeout или отсутствие ответа – 7с

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

В этом случае можно сформулировать общие правила оценки времени отклика на основе процентно-временных диапазонов. Например:

• 90% < 200мс
• 95% < 500мс
• 99% < 1с
• 100% < 2с

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

Как оценить результат измерения

Собрать статистику (о чем ниже) и получить результаты измерений времени отклика – это лишь полдела. Без последующего анализа и оценки результата (хорошо, плохо), все это не имеет никакого смысла. К счастью, здесь нам на помощь приходят промышленные стандарты на время отклика системы:

• ESD/MITRE (ESD-TR-86-278, «Guidelines for Designing User Interface Software», 1986, www.dfki.de/~jameson/hcida/papers/smith-mosier.pdf)
• TAFIM («Technical Architecture Framework for Information Management», 1996, том 8, «DoD Human Computer Interface Style Guide», www.everyspec.com/DoD/DOD-General/DISA_TAFIM_VOL8_7545/)
• MIL-STD 1472 (ревизия G от 2012 г., www.everyspec.com/MIL-STD/MIL-STD-1400-1499/MIL-STD-1472F_208/)

В соответствии с этим стандартами, максимальное время ожидания пользователя не должно превышать 10-15 секунд, среднее время обработки запроса должно быть не более 2-5 секунд, а время отклика системы – 0.2-0.5 секунды (стандарты писались из расчета возможностей техники тех времен, которая на сегодняшний день хорошо увеличила свою производительность).

Другой источник – «Designing and Engineering Time: The Psychology of Time Perception in Software» (2008, www.amazon.com/Designing-Engineering-Time-Psychology-Perception/dp/0321509188) – рассматривает подход, основанный на времени ожидания пользователя:

• Мгновенную реакцию (0.1 — 0.2 с) система должна показывать при нажатии кнопок, вызове меню, взаимодействии с другими элементами интерфейса.
• Незамедлительная реакция (0.5 — 1 с) должна следовать в ответ на простой запрос пользователя.
• Непрерывающаяся реакция (2 — 5 с) – это время, в течение которого пользователь сохраняет внимание на задаче, иначе говоря, время обратной связи.
• Вынуждающая реакция (7 — 10 с) – когда после 7 секунд пользователь переключается на другую задачу или уходит со страницы.

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

Перейдем к непосредственному измерению.

Чем измерять

Рассмотрим решение задачи сбора статистики для популярного сервера nginx.

При использовании nginx в качестве front end, все необходимая нам информация доступна в логах. Классический способ сбора статистики через анализ логов подразумевает подробный разбор (парсинг) содержимого логов за выделенный промежуток времени. Данный путь имеет ряд недостатков:

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

Второй подход – использование дополнительных модулей. Рассмотрим ряд вариантов.

• nginx-statsd
  Модуль для nginx, собирающий статистику и перенаправляющий ее демону StatsD по протоколу UDP. Такой подход, во-первых, требует отдельного сервера, а во-вторых, приводит к росту служебного трафика. Кроме того, StatsD завязан на Graphite, а интеграция с ним других систем мониторинга затруднена.
• pinba
  Модуль для nginx, собирающий статистические данные в момент завершения выполнения запроса и передающий их по протоколу UDP на отдельный сервер сбора статистики. Фактически, недостатки такого решения обусловлены самим принципом его работы: необходимость отдельного сервера, «лишний» UDP-трафик. Кроме того, модуль фактически фиксирует время от момента получения запроса до его завершения (shutdown), т.е. измеряет время выполнения запроса, а не время ответа апстрима, которое нам нужно.
• nginx-sla
  Модуль nginx-sla реализует сбор статистики апстрима без привлечения дополнительного сервера. Данные статистики формируются по запросу к nginx в обычном текстовом формате, следовательно, ни отдельный сервер, ни UDP не нужны.

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

Преимущества nginx-sla

Как уже отмечалось, применение модуля nginx-sla не требует выделенного сервера для сбора и анализа статистики. Статистика собирается непосредственным анализом логов nginx и записывается в виде простого текста. Очевидно, что в контексте дальнейшего анализа, как стандартными инструментами, так и сторонними средствами (например, zabbix), такое представление статистики апстрима намного более выгодно.

Пример статистики, собранной nginx-sla, при конфигурации по умолчанию:

main.all.http = 1024 main.all.http_200 = 914 ... main.all.http_xxx = 2048 main.all.http_2xx = 914 ... main.all.time.avg = 125 main.all.time.avg.mov = 124 main.all.300 = 233 main.all.300.agg = 233 main.all.500 = 33 main.all.500.agg = 266 main.all.2000 = 40 main.all.2000.agg = 306 main.all.inf = 0 main.all.inf.agg = 306 main.all.25% = 124 main.all.75% = 126 main.all.90% = 126 main.all.99% = 130 

Как видно, данные отображают статистику всех обработанных HTTP ответов с различными статусами. Например, значение main.all.http_200 (main.all.http_404, main.all.http_500) обозначает число обработанных ответов с соответствующим статусом.
А поле main.all.http_2xx содержит количество всех ответов апстрима, имеющих статус «Success».

Статистика по времени отклика собрана в переменных main.all.300 (main.all.200, main.all.500, main.all.2000). Например, число запросов, обработанных апстримом за время от 300 миллисекунд до 500 миллисекунд, равно 33. А аггрегатированное число запросов, обработанных за 500 мс и менее, равно 266.

Помимо явной статистики времени ответа апстрима, nginx-sla приводит информацию по перцентилям. В частности время, за которое апстрим отвечает на 90% запросов, составляет в данном примере 126 миллисекунд.

Перцентильное представление статистики, а также значения среднего (main.all.time.avg) и скользящего среднего (main.all.time.avg.mov) времени ответа позволяют проанализировать поведение апстрима при различных сценариях нагрузки. Например:

Заключение и выводы

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

Здесь уместно вспомнить два простых закона:

1. Закон Вебера – Фехнера, утверждающий, что интенсивность ощущения пропорциональна логарифму интенсивности раздражителя. Или иначе: различие в ощущениях появляется, если раздражители отличаются на некую долю своей величины, а не на абсолютное значение.
2. Абсолютный порог восприятия времени человеком составляет примерно 15 мс.

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

Выводы

1. Качество работы приложения можно свести к набору количественных характеристик. В нашем случае, качество работы апстрима можно свести к времени отклика и HTTP-ответам с различными статусами.
2. Анализ указанных характеристик удобно проводить модулями для nginx.
3. В качестве рабочего инструмента используем nginx-sla как наиболее гибкий и нетребовательный модуль в сравнении с аналогами.
4. nginx-sla позволяет сгруппировать статистическую информацию и, тем самым, преобразовать количественные данные в величины, пригодные для качественного анализа (среднее значение, плавающее среднее, квантили).
5. Собранная статистика анализируется на предмет превышения предельных значений, заданных стандартом, и сопоставляется с порогом восприятия времени человеком. Делается вывод о необходимости дальнейших действий.