Мониторинг приложений: что и как отслеживать
Мониторинг приложений — это способ узнать о проблемах раньше пользователей. Приложение упало ночью — вы узнаёте об этом утром от клиентов. Или — от системы мониторинга в 3 часа ночи, и успеваете исправить до начала рабочего дня. Разница очевидна.
Хорошо настроенный мониторинг отвечает на вопросы: что работает, что не работает, где узкие места, что изменилось. Без него вы работаете вслепую: не знаете, какие проблемы есть сейчас, и не видите приближение проблем. В этой статье — разбор мониторинга приложений: метрики, логи, алерты, инструменты. Если нужно разместить приложение с мониторингом — поможем.
Зачем нужен мониторинг
Раннее оповещение
Узнаёте о проблемах раньше пользователей. Успеваете исправить до негативных последствий.
Понимание трендов
Видите рост нагрузки, замедление отклика. Планируете масштабирование заранее.
Диагностика
Когда что-то ломается — видите причину. Не гадаете, а знаете, где проблема.
Отчётность
Данные для отчётов: аптайм, средняя нагрузка, инциденты. Прозрачность для руководства.
Скорость реакции
Среднее время обнаружения проблемы — минуты, а не часы. Минимальный ущерб для бизнеса.
Спокойствие команды
Разработчики не просыпаются от звонков клиентов. Система оповещает заранее.
Уровни мониторинга
Мониторинг делится на уровни. Каждый уровень — свой фокус.
Инфраструктура
- CPU, RAM, диск
- Сеть, I/O
- Доступность серверов
- Температура, вентиляторы
Сервисы
- Веб-сервер, БД
- Redis, Memcached
- Очереди (RabbitMQ, Kafka)
- Docker, Kubernetes
Приложение
- Время отклика
- Количество запросов
- Ошибки 4xx, 5xx
- Медленные запросы
Бизнес-метрики
- Регистрации
- Заказы, платежи
- Конверсия
- Выручка
Ключевые метрики
Метрик много, но не все одинаково важны. Вот основные.
| Метрика | Норма | Что делать при отклонении |
|---|---|---|
| Response time | до 200 мс | Проверить запросы, кеш, БД |
| Request rate | зависит от проекта | Проверить аномалии, масштабировать |
| Error rate | до 1% | Смотреть логи, исправлять |
| Apdex | выше 0.94 | Оптимизировать, кешировать |
| Throughput | зависит от проекта | Проверить узкие места |
| Memory usage | до 80% | Искать утечки, оптимизировать |
| DB queries | до 100 мс | Индексы, оптимизация запросов |
| Queue size | близко к нулю | Добавить воркеров |
Apdex
Apdex (Application Performance Index) — это метрика удовлетворённости пользователей скоростью. Оценивает от 0 до 1. Значение выше 0.94 — отлично, ниже 0.7 — плохо. Учитывает три категории запросов: быстрые, приемлемые, медленные.
User-centric метрики
Для веб-приложений важны метрики, которые чувствует пользователь:
- TTFB: Time to First Byte. Время до первого байта;
- FCP: First Contentful Paint. Первый контент;
- LCP: Largest Contentful Paint. Основной контент;
- FID: First Input Delay. Задержка ввода;
- CLS: Cumulative Layout Shift. Сдвиги.
Логирование
Логи — это «чёрный ящик» приложения. Когда что-то ломается — они показывают, что происходило.
Что логировать
- Ошибки: с полным стеком и контекстом;
- Действия пользователей: вход, выход, критические операции;
- Запросы: URL, метод, время, статус;
- Изменения данных: кто, что, когда изменил;
- Внешние вызовы: к API, БД, другим сервисам.
Что НЕ логировать
- Пароли: никогда;
- Токены и ключи: никогда;
- Персональные данные: ФИО, номера карт, адреса;
- Полные тела запросов: только при необходимости и с маскированием.
Формат логов
- Структурированные: JSON. Легко парсить и анализировать;
- Уровни: DEBUG, INFO, WARN, ERROR, FATAL;
- Контекст: request_id, user_id, timestamp;
- Ротация: logrotate. Старые логи архивируются и удаляются.
Централизация
С ростом инфраструктуры логи надо централизовать. Иначе их невозможно анализировать.
- ELK Stack: Elasticsearch + Logstash + Kibana;
- Graylog: альтернатива ELK;
- Loki: от Grafana, легче ELK;
- Sentry: для ошибок приложений.
Алерты
Алерты — это оповещения, которые приходят, когда что-то не так. Без них мониторинг бесполезен: данные есть, а реакции нет.
Принципы хороших алертов
- Полезность: алерт должен требовать действия. Если ничего не делать — не нужен;
- Не спамить: 100 алертов в день — игнорирование. 5–10 важных — реакция;
- Приоритеты: критичные (звонок), важные (Telegram), информационные (email);
- Контекст: в алерте — что случилось, где, что делать;
- Эскалация: если не отреагировали — эскалация на второго;
- Тишина: ночью — только критичные алерты.
Что алертить
- Доступность: сервис недоступен более N секунд;
- Ошибки: error rate выше N%;
- Задержки: response time выше N мс;
- Ресурсы: CPU, RAM, диск выше N%;
- Бизнес: нет заказов N минут, упала конверсия;
- Безопасность: много неудачных входов, аномалии.
Куда отправлять
- Telegram: быстрый канал для большинства алертов;
- Email: для информационных;
- SMS: для критичных ночью;
- PagerDuty: для дежурных команд;
- Slack: для обсуждения инцидентов.
APM — Application Performance Monitoring
APM — это мониторинг производительности приложения. Показывает, где именно в коде тратится время.
Что даёт APM
- Трейсинг: путь запроса через все сервисы;
- Профилирование: какие функции медленные;
- Карта зависимостей: как сервисы связаны;
- Ошибки: где и почему возникают;
- Метрики: время отклика, throughput, error rate.
Инструменты APM
- Sentry: мониторинг ошибок. Популярен, прост, есть бесплатный тариф;
- New Relic: полноценный APM. Мощный, но дорогой;
- Datadog: APM + инфраструктура + логи. Для крупных команд;
- Elastic APM: часть ELK Stack. Бесплатный, интегрируется;
- SkyWalking: open-source APM для микросервисов;
- Jaeger: распределённый трейсинг;
- OpenTelemetry: стандарт сбора телеметрии. Работает с любым APM.
Что смотреть в APM
- Медленные запросы: какие эндпоинты тормозят;
- Медленные запросы к БД: какие SQL-запросы долгие;
- Внешние API: какие вызовы долгие;
- Ошибки: где падает, что вызывает;
- N+1 запросы: классическая проблема ORM.
Инструменты
Prometheus + Grafana
Стандарт для метрик. Prometheus собирает данные, Grafana визуализирует. Мощно, бесплатно.
ELK Stack
Для логов. Elasticsearch хранит, Logstash обрабатывает, Kibana визуализирует.
Sentry
Мониторинг ошибок. Показывает, где упало, какие пользователи затронуты, что делать.
Uptime-мониторинг
UptimeRobot, Pingdom, StatusCake. Проверяют доступность из разных точек мира.
Tracing
Jaeger, Zipkin, OpenTelemetry. Показывают путь запроса через микросервисы.
RUM
Real User Monitoring. Яндекс.Метрика, Google Analytics, SpeedCurve. Показывают опыт реальных пользователей.
Дашборды
Дашборд — это визуализация всех метрик на одном экране. Один взгляд — и понятно, что происходит.
Что включить в дашборд
- Верхний уровень: аптайм, RPS, error rate, response time;
- Ресурсы: CPU, RAM, диск, сеть;
- Сервисы: статусы веб-сервера, БД, кеша, очередей;
- Приложение: медленные эндпоинты, топ ошибок;
- Бизнес: заказы, регистрации, выручка.
Правила хорошего дашборда
- Минимум элементов: только важное. Не 50 графиков, а 10–15;
- Понятность: любой член команды должен понять за 10 секунд;
- Контекст: подписи, единицы измерения, нормы;
- Сравнение: текущее значение vs прошлая неделя, месяц;
- Действия: что делать при отклонении.
Дашборды для разных ролей
- Разработчики: ошибки, медленные запросы, логи;
- DevOps: инфраструктура, ресурсы, алерты;
- Бизнес: метрики продукта, конверсия, выручка;
- Поддержка: статус сервисов, инциденты, SLA.
Реакция на инциденты
Мониторинг — это только часть. Важно правильно реагировать на алерты.
Процесс
- Обнаружение: алерт приходит, дежурный реагирует;
- Классификация: критичный, важный, информационный;
- Диагностика: смотрим логи, метрики, APM;
- Устранение: фикс, откат, перезапуск;
- Коммуникация: сообщаем команде и пользователям;
- Пост-мортем: разбор, что было, что улучшить.
Runbook
Runbook — это инструкции для типовых инцидентов. Что делать, если: упал сервер, кончилось место, БД недоступна, выросли ошибки. С готовыми инструкциями реакция быстрее.
Дежурства
Для критичных проектов — дежурства. Один человек на связи круглосуточно, следующие — в резерве. Дежурства ротируются. Без дежурств алерты ночью никто не увидит.
Чек-лист мониторинга
Инфраструктура
- CPU, RAM, диск
- Сеть, I/O
- Доступность серверов
- Docker, Kubernetes
Приложение
- Response time
- Error rate
- Apdex
- Медленные запросы
Алерты
- 5–10 важных
- Приоритеты
- Telegram, email, SMS
- Эскалация
Логи и APM
- Структурированные логи
- Централизация (ELK, Loki)
- Sentry для ошибок
- Трейсинг микросервисов
Наши рекомендации
📌 Что вы получаете, заказывая мониторинг у нас
- Метрики — Prometheus + Grafana
- Логи — ELK или Loki
- Ошибки — Sentry
- Алерты — Telegram, email, SMS
- Дашборды — для команды
- Реакцию на инциденты — помощь дежурным
🔹 Оставьте заявку на мониторинг
Хотите видеть всё, что происходит с приложением? Оставьте заявку на бесплатную консультацию.
📌 Итоговый вывод
Мониторинг приложений — это способ узнать о проблемах раньше пользователей.
Что нужно знать:
- Зачем — раннее оповещение, тренды, диагностика, отчётность
- Уровни — инфраструктура, сервисы, приложение, бизнес-метрики
- Метрики — response time, error rate, Apdex, throughput
- Логи — структурированные, централизованные, без секретов
- Алерты — 5–10 важных, с приоритетами и эскалацией
- APM — Sentry, New Relic, Datadog, Elastic APM, OpenTelemetry
- Инструменты — Prometheus, Grafana, ELK, Sentry, Uptime
- Реакция — дежурства, runbook, пост-мортемы
Хотите мониторинг? Закажите консультацию в Lead Hub.
Также рекомендуем: Docker, Kubernetes, CI/CD, масштабирование, безопасность приложений, хостинг для приложений.