Мониторинг качества работы вашего проекта
План
• Работает ли сайт
• Работает ли бизнес функционал
Работает ли сайт
• Внешние регулярные проверки (http check)
• Анализ логов
• Real User Monitoring (RUM – метрики из браузеров пользователей)
Внешние проверки сайта
• Покрывают не все страницы• Не позволяют хорошо замерить время
ответа• Пропускают проблемы
Логи nginx
• Есть все запросы реальных пользователей
• Можно посчитать за период, сколько было ошибок
• Добавляем в лог время ответа – видим как быстро отвечали пользователям
Время ответа: квантиль
• Сильно лучше чем среднее :)
• Непонятно, как корректно объединять (например при сборе с нескольких серверов)
• Примерно понятен физический смысл, но не отвечает на все вопросы
• Если Q95 выросла с 500ms до 5s, сколько пользователей это затронуло?
Время ответа: гистограмма
• Очень понятный физический смысл
• Удобно объединять: просто сумма одинаковых бакетов
• Нужно сразу выбрать пороги
• Есть способ делать гистограмму не выбирая заранее пороги, но он дорогой
Нас интересует
• Сколько было запросов: как обычно/больше/меньше
• Сколько было ошибок
• Времена ответов: на сколько масштабны были тормоза
Упихиваем ответы на 1 график
Гистограмма времени ответа + ошибки
• быстро (<500ms)• терпимо (500ms-1s)• медленно (>1s)• HTTP-5xx
“Светофор”
логи VS пробы
• Пробы: 5 основных страниц раз в минуту с таймаутом 4s
• Триггеры по метрикам из лога nginx: > 20 ошибок в секунду (при ~600rps) Q95 > 4sUptime: пробы: 99.80% (9 минут за 30 дней) логи: 98.86% (7ч 29 минут за 30 дней)
Rеal User Monitoring
• На страницу ставится JS, который отстреливает статистику загрузки страницы на сервер
• Очень полезен в мониторинге производительности client-side логики
RUM
Отстреливаем свои события
• Загрузка видео + рекламы в плеер
• Считаем, сколько пользователь смотрел видео
• Загрузка и работа ваших JS компонентов
Мониторинг доставки видео
• Скорость загрузки (качество работы CDN)
• Ошибки загрузки
Скорость загрузки видео
Ошибки загрузки видео
Так работает ли сайт?
• Правильно замониторить сайт – достаточно большая задача
• Но вполне решаемая
• Если захотеть, можно видеть большинство проблем на всех уровнях
Бизнес-логика сайта
• Синхронные действия (пользователь ждет)
• Асинхронные действия (отложенные)
• Действия иницируемые системой (рассылки, биллинг, …)
Как получать метрики
• SQL запросы• Запрос в http сервис• Запрос в NoSQL• Размер очереди в *mq• Парсинг логов• Из приложения через statsd
Синхронные действия
• Заказ в интернет-магазине• Регистрация нового пользователя• Просмотр статьи• Комментарий• Лайк• …
Синхронные действия
• Важно считать количество действий
• Если поехала верстка, забыли нужную кнопку – упадет количество целевых действий
• Видим, как ведет себя показатель во времени – можем подобрать порог для триггера
Пользователи должны всегда заливать новые видосы
И лайкать чужие
Асинхронные действия
В ходе пользовательского запроса решили что-то отложить – положили в очередь
• Отправка уведомлений• Процессинг загруженных данных• Пересчет статистики• …
Асинхронные действия
• Считаем размер очереди
• Считаем ошибки при процессинге
• Скорость процессинга (tasks/second)
• Считаем время нахождения задач в очереди – алерт, если старшей необработанной задаче больше N минут
Обработка залитых видео
Failed push notifications
Мониторинг доставки почты
Поток доставляемых сообщений
Скорость доставки важной почты
Структура почтового трафика
Хочу тоже все видеть!
• Начните с сайта – теперь вы знаете, на что смотреть
• Вспомните последние 10-20 инцидентов/багов, влияющих на пользователей
• Повторную проблему должно быть видно хотя бы на одном графике
Хочу тоже все видеть!
• У метрик должен быть хорошо понятный вам физический смысл
• Не страшно, если сначала будет много графиков – лишнее выкинуть не сложно
• По самым показательным метрикам сделайте триггеры
