Monitoring и alerting веб-приложений: как не проспать падение

Почему мониторинг — это не «хорошо бы», а «обязательно»

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

Средняя стоимость минуты простоя для e-commerce — от $5 000 до $100 000 в зависимости от масштаба бизнеса. Для банков и финтеха — ещё выше. Даже для малого бизнеса час простоя сайта во время рекламной кампании может стоить весь рекламный бюджет.

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

В этой статье разберём полный стек мониторинга: от базовых проверок до продвинутой observability.

Четыре золотых сигнала (Four Golden Signals)

Google SRE (Site Reliability Engineering) выделяет четыре ключевые метрики, которые нужно отслеживать для любого сервиса:

1. Latency (Задержка)

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

Что отслеживать:

• P50 (медиана) — типичное время ответа
• P95 — время ответа для 95% запросов
• P99 — время ответа для 99% запросов (хвостовые задержки)

Нормальные значения для веб-приложения:

• P50: < 200 мс
• P95: < 500 мс
• P99: < 1000 мс

Важно: отслеживайте задержку отдельно для успешных и неуспешных запросов. Медленная ошибка 500 — это двойная проблема.

2. Traffic (Трафик)

Количество запросов к вашему сервису. Метрика показывает текущую нагрузку и помогает прогнозировать потребность в ресурсах.

Что отслеживать:

• RPS (Requests Per Second) — запросы в секунду
• RPM (Requests Per Minute) — для менее нагруженных сервисов
• Разбивка по типам запросов (API, статика, WebSocket)

Зачем нужно: резкое падение трафика часто означает проблему (DNS, сеть, баг), а резкий рост — потенциальную перегрузку или DDoS-атаку.

3. Errors (Ошибки)

Процент запросов, завершившихся ошибкой. Это самый прямой индикатор проблемы.

Что отслеживать:

• Error rate — процент ошибок от общего числа запросов
• HTTP 5xx — серверные ошибки
• HTTP 4xx — клиентские ошибки (рост может указывать на баг)
• Ошибки бизнес-логики — неуспешные платежи, таймауты внешних API

Нормальные значения:

• Error rate: < 0.1% (менее 1 ошибки на 1000 запросов)
• HTTP 5xx: < 0.01%

4. Saturation (Насыщение)

Насколько загружены ресурсы системы. Метрика предсказывает, когда система перестанет справляться.

Что отслеживать:

• CPU utilization — загрузка процессора
• Memory utilization — использование памяти
• Disk I/O — нагрузка на диск
• Network bandwidth — использование сетевого канала
• Database connections — количество подключений к БД
• Queue depth — длина очередей

Пороговые значения:

• CPU: алерт при > 80% более 5 минут
• Memory: алерт при > 85%
• Disk: алерт при > 90%

Инфраструктурный мониторинг: Prometheus + Grafana

Prometheus: сбор и хранение метрик

Prometheus — открытый инструмент для сбора метрик. Он опрашивает ваши сервисы по HTTP и сохраняет числовые временные ряды.

Архитектура мониторинга:

[Ваше приложение] --> [Prometheus] --> [Grafana]
       |                    |
  /metrics endpoint    хранилище метрик     дашборды и алерты

Экспортёры метрик

Prometheus собирает метрики через «экспортёры»:

• Node Exporter — метрики сервера (CPU, RAM, диск, сеть)
• cAdvisor — метрики Docker-контейнеров
• PostgreSQL Exporter — метрики базы данных
• Nginx Exporter — метрики веб-сервера
• Blackbox Exporter — проверка доступности URL

Для Node.js-приложений метрики экспортируются через библиотеку prom-client:

// metrics.ts
import {
    Registry,
    Counter,
    Histogram,
    collectDefaultMetrics,
} from "prom-client";

const registry = new Registry();
collectDefaultMetrics({register: registry});

// Кастомные метрики
export const httpRequestDuration = new Histogram({
    name: "http_request_duration_seconds",
    help: "Duration of HTTP requests in seconds",
    labelNames: ["method", "route", "status"],
    buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5],
    registers: [registry],
});

export const httpRequestTotal = new Counter({
    name: "http_requests_total",
    help: "Total number of HTTP requests",
    labelNames: ["method", "route", "status"],
    registers: [registry],
});

// Middleware для Express/Fastify
export function metricsMiddleware(req, res, next) {
    const start = Date.now();
    res.on("finish", () => {
        const duration = (Date.now() - start) / 1000;
        httpRequestDuration.observe(
            {
                method: req.method,
                route: req.route?.path || req.path,
                status: res.statusCode,
            },
            duration
        );
        httpRequestTotal.inc({
            method: req.method,
            route: req.route?.path || req.path,
            status: res.statusCode,
        });
    });
    next();
}

Grafana: визуализация

Grafana — инструмент для создания дашбордов на основе данных Prometheus. Позволяет строить графики, таблицы, heatmaps и настраивать алерты.

Типичный дашборд для веб-приложения включает:

• Overview — RPS, error rate, средняя задержка
• Infrastructure — CPU, RAM, диск по каждому серверу
• Application — эндпоинты по задержке, очереди, кэши
• Database — коннекты, slow queries, размер таблиц
• Business metrics — регистрации, заказы, платежи

Мониторинг ошибок приложения: Sentry

Зачем нужен отдельный инструмент для ошибок

Prometheus отслеживает количество ошибок, но не их содержание. Sentry (или аналоги) ловит конкретные исключения с полным стек-трейсом, контекстом пользователя и данными запроса.

Интеграция Sentry в Next.js

// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
    dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
    tracesSampleRate: 0.1, // 10% запросов для performance monitoring
    replaysSessionSampleRate: 0.01, // 1% сессий для Session Replay
    integrations: [
        Sentry.replayIntegration(),
        Sentry.browserTracingIntegration(),
    ],
});

Что даёт Sentry

• Группировка ошибок — одинаковые ошибки объединяются в issues
• Стек-трейс — полный путь до ошибки с номерами строк
• Контекст — браузер, ОС, URL, данные пользователя
• Session Replay — видеозапись сессии пользователя, в которой произошла ошибка
• Performance — трейсы запросов, медленные транзакции
• Алерты — уведомления о новых ошибках в Slack/Telegram

Sentry незаменим при разработке сайтов на Next.js и Telegram Mini Apps — он помогает находить и исправлять ошибки до того, как они повлияют на большое количество пользователей.

Uptime мониторинг: проверка доступности

Зачем нужен внешний мониторинг

Prometheus мониторит сервис изнутри. Но если упадёт DNS, CDN или провайдер — Prometheus об этом не узнает, потому что сам станет недоступен. Внешний uptime мониторинг проверяет сайт «снаружи» — как реальный пользователь.

Инструменты

Инструмент	Бесплатный план	Интервал проверки	Локации
UptimeRobot	50 мониторов, 5 мин	1 мин (платный)	10+
Pingdom	Нет	1 мин	100+
Better Uptime	10 мониторов, 3 мин	30 сек (платный)	30+
Checkly	5 мониторов	1 мин	20+
Uptime Kuma	Self-hosted, бесплатно	1 мин	Ваш сервер

Что мониторить

• HTTP-статус — главная страница и ключевые эндпоинты возвращают 200
• Время ответа — порог, выше которого считается проблемой (обычно 3–5 секунд)
• SSL-сертификат — предупреждение за 7–14 дней до истечения
• DNS — резолвится ли домен
• Контент — содержит ли страница ожидаемый текст (чтобы не получить 200 OK от ошибки Cloudflare)

Statuspage

Для публичных сервисов рекомендуется создать страницу статуса (status page), где клиенты могут проверить состояние сервиса. Инструменты: Statuspage (Atlassian), Instatus, Cachet (self-hosted).

Log management: ELK Stack и Loki

Зачем собирать логи централизованно

Логи — основной источник информации при расследовании инцидентов. Если у вас 5 серверов и вы ищете причину ошибки, заходить на каждый сервер через SSH — медленно и неэффективно. Централизованный сбор логов позволяет:

• Искать по всем серверам одновременно
• Фильтровать по времени, уровню, сервису
• Корrelировать события между сервисами
• Строить дашборды по логам

ELK Stack (Elasticsearch + Logstash + Kibana)

Классический стек для логов:

• Elasticsearch — хранение и поиск логов
• Logstash (или Filebeat) — сбор и отправка логов
• Kibana — визуализация и анализ

Плюсы: мощный полнотекстовый поиск, гибкие дашборды. Минусы: ресурсоёмкий (Elasticsearch требует много RAM), сложная настройка.

Grafana Loki

Лёгкая альтернатива ELK. Loki не индексирует содержимое логов (как Elasticsearch), а только метаданные (метки). Это делает его в 10–100 раз дешевле по ресурсам.

# docker-compose.yml (фрагмент)
loki:
  image: grafana/loki:latest
  ports:
    - "3100:3100"
  volumes:
    - loki-data:/loki

promtail:
  image: grafana/promtail:latest
  volumes:
    - /var/log:/var/log
    - ./promtail-config.yml:/etc/promtail/config.yml

Loki интегрируется с Grafana — логи можно просматривать рядом с метриками Prometheus на одном дашборде. Это значительно ускоряет расследование инцидентов.

Структурированное логирование

Для эффективного анализа логи должны быть структурированными (JSON):

// Плохо
console.log("User 12345 made payment of 1000 RUB");

// Хорошо
logger.info({
    event: "payment_completed",
    userId: 12345,
    amount: 1000,
    currency: "RUB",
    paymentMethod: "card",
    duration: 350,
});

Структурированные логи легко фильтровать, агрегировать и визуализировать. Если вы используете Python для автоматизации, те же принципы логирования применяются и там.

Alerting: как не проспать и не устать

Проблема alert fatigue

Alert fatigue — главная проблема систем оповещения. Когда алертов слишком много, команда начинает их игнорировать. А значит, пропустит и реальный инцидент.

Статистика: 30% алертов в типичных компаниях — ложные срабатывания. Ещё 40% — некритичные события, которые не требуют немедленной реакции.

Правила хорошего alerting

1. Алерт должен требовать действия. Если получив алерт, инженер ничего не делает — алерт не нужен
2. Алерт на симптомы, а не на причины. «Error rate > 1%» лучше, чем «CPU > 80%». Высокий CPU не всегда означает проблему
3. Устанавливайте правильные пороги. Слишком чувствительные — шум. Слишком нечувствительные — пропуск инцидентов
4. Используйте гистерезис. Алерт срабатывает при превышении порога в течение 5 минут, а не при единичном спайке
5. Приоритизируйте. P1 будит ночью, P3 отправляет email утром

Каналы оповещения

Канал	Для чего	Время реакции
Телефонный звонок	P1 — критические инциденты	< 5 мин
SMS	P1 — дублирование звонка	< 5 мин
Telegram	P2 — важные, но не критичные	15–30 мин
Slack	P3 — требуют внимания в рабочее время	1–4 часа
Email	P4 — информационные	Следующий рабочий день

Escalation (эскалация)

Если дежурный инженер не отреагировал за установленное время — алерт автоматически эскалируется:

1. 0 мин — алерт в Telegram дежурному
2. 5 мин — звонок дежурному
3. 15 мин — звонок бэкап-инженеру
4. 30 мин — звонок тимлиду
5. 60 мин — звонок CTO

Инструменты для управления эскалациями: PagerDuty, Opsgenie, Grafana OnCall (бесплатный).

On-Call: дежурство и ротация

Организация дежурств

On-call — это практика, при которой один из инженеров назначается дежурным и отвечает за реакцию на инциденты.

Ключевые принципы:

• Ротация — дежурство меняется каждую неделю или каждые 2 недели
• Компенсация — дежурный получает дополнительную оплату (обычно +30–50% к дневной ставке за ночные часы)
• Передача смены — при смене дежурного происходит handoff с обзором текущего состояния
• Runbooks — инструкции по реагированию на типичные инциденты

Runbooks (инструкции)

Runbook — это пошаговая инструкция по реагированию на конкретный тип инцидента. Пример:

## Алерт: Error rate > 1%

### Шаг 1: Определить масштаб
- Проверить Grafana: dashboard -> Overview -> Error Rate
- Определить, какие эндпоинты затронуты

### Шаг 2: Проверить последние деплои
- git log --oneline -5 на production
- Если деплой был в последние 30 минут — откатить

### Шаг 3: Проверить внешние зависимости
- БД: проверить pg_stat_activity на slow queries
- Redis: проверить INFO, memory usage
- Внешние API: проверить в Grafana -> External APIs

### Шаг 4: Если причина не найдена
- Эскалировать на тимлида
- Собрать информацию: логи, метрики, время начала

Наличие runbooks сокращает время реагирования в 3–5 раз. Даже junior-инженер может справиться с инцидентом, следуя инструкции.

Incident Management: от обнаружения до постмортема

Жизненный цикл инцидента

1. Обнаружение — алерт или сообщение от пользователя
2. Acknowledgement — дежурный подтверждает, что видит проблему
3. Тriage — определение приоритета и масштаба
4. Investigation — поиск причины
5. Mitigation — временное решение (откат, перезагрузка, переключение на бэкап)
6. Resolution — полное исправление причины
7. Postmortem — анализ инцидента и предотвращение повторения

Постмортем (разбор инцидента)

Постмортем — это структурированный разбор инцидента после его устранения. Цель — не найти виноватого, а предотвратить повторение.

Структура постмортема:

## Инцидент: [Название]
Дата: [дд.мм.гггг]
Длительность: [X часов Y минут]
Влияние: [Кто пострадал, сколько пользователей]
Дежурный: [Имя]

## Timeline
- HH:MM — Алерт: описание
- HH:MM — Дежурный начал расследование
- HH:MM — Обнаружена причина
- HH:MM — Применён фикс
- HH:MM — Мониторинг подтвердил восстановление

## Причина
[Описание root cause]

## Что сработало хорошо
- [Алерт сработал вовремя]
- [Runbook помог быстро диагностировать]

## Что можно улучшить
- [Алерт должен быть более специфичным]
- [Не было runbook для этого случая]

## Действия (Action Items)
1. [ ] Добавить мониторинг на [X] — Ответственный: [Имя] — Срок: [дата]
2. [ ] Написать runbook для [Y] — Ответственный: [Имя] — Срок: [дата]
3. [ ] Добавить автоматический откат при [Z] — Ответственный: [Имя] — Срок: [дата]

Blameless культура

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

Архитектура мониторинга: итоговая схема

Полный стек мониторинга для веб-приложения:

Уровень 1: Uptime (внешний)
├── UptimeRobot / Better Uptime
└── Синтетические проверки (Checkly)

Уровень 2: Инфраструктура
├── Prometheus + Node Exporter (серверы)
├── cAdvisor (Docker)
└── Grafana (дашборды)

Уровень 3: Приложение
├── Sentry (ошибки)
├── Application metrics (prom-client)
└── Distributed tracing (Jaeger / Tempo)

Уровень 4: Логи
├── Grafana Loki / ELK
└── Promtail / Filebeat

Уровень 5: Alerting
├── Grafana Alerting / Alertmanager
├── PagerDuty / Opsgenie
└── Telegram / Slack интеграции

Для небольших проектов можно начать с уровней 1 и 3 (UptimeRobot + Sentry) — это покроет 80% потребностей. Остальное добавляется по мере роста.

Заключение

Мониторинг — это не роскошь, а необходимость для любого веб-приложения, которое зарабатывает деньги. Правильно настроенная система мониторинга:

• Обнаруживает проблемы до пользователей
• Сокращает время простоя в 5–10 раз
• Помогает находить узкие места производительности
• Даёт данные для планирования масштабирования

Ключевые принципы:

1. Мониторьте четыре золотых сигнала — задержка, трафик, ошибки, насыщение
2. Комбинируйте внешний и внутренний мониторинг — они дополняют друг друга
3. Алерт должен требовать действия — иначе это шум
4. Пишите runbooks — они сокращают время реагирования в разы
5. Проводите постмортемы — без обвинений, с конкретными действиями

Если вам нужна помощь с настройкой мониторинга для вашего проекта — обращайтесь. Мы развернём полный стек мониторинга за 3–5 дней и настроим алерты, чтобы ваше приложение работало бесперебойно. Также можем помочь с разработкой сайтов и Mini Apps с мониторингом из коробки.