Как мониторить веб-приложения: от логов до observability — пошаговое руководство

Зачем вообще мониторить

Каждый час простоя SaaS-продукта с 1 000 платящих пользователей стоит примерно $1 500 выручки. Но деньги — не главная причина. Главная — пользователи. Когда кнопка «Оплатить» не работает, пользователь не пишет в support. Он уходит к конкуренту и больше не возвращается.

Мониторинг решает три задачи:

1. Узнать о проблеме до того, как пользователь заметит.
2. Понять, что именно сломалось, за минуты, а не часы.
3. Предотвратить повторение через анализ трендов.

Разберём полный стек мониторинга: от логов до observability.

Шаг 1: Определите, что мониторить

Не пытайтесь мониторить всё сразу. Начните с критичного пути пользователя:

Для SaaS-продукта это:
  - Регистрация (signup flow)
  - Онбординг (первые 3 шага)
  - Платёж (checkout → подтверждение)
  - Основная функция (то, ради чего платят)
  - Экспорт данных / отчёты

Составьте список из 3-7 ключевых user journeys. Именно их вы будете мониторить в первую очередь.

Шаг 2: Error Monitoring — узнайте, что падает

Первый инструмент в стеке — error tracker. Он ловит исключения и складывает их в дашборд с группировкой по типу.

Инструменты: Sentry (open-source, самый популярный), Rollbar, Bugsnag, Firebase Crashlytics (для мобильных).

Настройка Sentry за 5 минут:

npm install @sentry/nextjs

// sentry.client.config.js
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: 'https://ваш_ключ@sentry.io/проект',
  tracesSampleRate: 1.0, // в проде ставьте 0.1
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,
});

Что вы получите:

• Каждая ошибка сгруппирована по стектрейсу.
• Контекст: браузер, ОС, версия приложения.
• Хлебные крошки: что пользователь делал до ошибки.
• Алерты в Slack/Telegram/Discord при превышении порога.

Правило: настройте алерт на каждый новый тип ошибки. Если за 5 минут пришло 10 одинаковых исключений — что-то сломалось.

Шаг 3: Performance Monitoring — узнайте, что тормозит

Error monitoring отвечает на вопрос «работает ли?». Performance — на вопрос «работает ли быстро?».

Метрики, которые надо отслеживать:

Инструменты: Sentry Performance, New Relic, Datadog APM, Grafana + Prometheus.

Настройка Sentry Performance (Next.js):

// next.config.js
const { withSentryConfig } = require('@sentry/nextjs');

module.exports = withSentryConfig({
  sentry: {
    widenClientFileUpload: true,
    transpileClientSDK: true,
    hideSourceMaps: true,
  },
});

Что вы получите:

• Трейсинг каждого запроса: бэкенд → БД → внешние API.
• N+1 запросы (самая частая причина медленных страниц).
• Slowest endpoints — сортировка по времени ответа.

Шаг 4: Session Replay — увидьте проблему глазами пользователя

Error monitoring говорит «TypeError на строке 42». Session replay показывает: пользователь кликнул три раза подряд, DOM перестроился, и обработчик события отвязался.

Инструменты: LogRocket, FullStory, Hotjar (только heatmaps).

Настройка LogRocket:

import LogRocket from 'logrocket';
LogRocket.init('ваш_app_id');

// Для Redux
import { applyMiddleware, createStore } from 'redux';
const store = createStore(
  reducer,
  applyMiddleware(LogRocket.reduxMiddleware())
);

Что вы получите:

• Полную запись сессии (DOM, сеть, консоль, Redux store).
• Возможность найти сессию по ошибке: «покажи все сессии, где был console.error с текстом payment failed».
• Интеграцию с Sentry: в Sentry-ошибке ссылка на LogRocket-сессию.

Когда это окупается: один баг, найденный за 15 минут вместо 3 дней, окупает месячную подписку.

Шаг 5: Алертинг — настройте уведомления правильно

Главное правило алертинга: алерт должен требовать действия. Если алерт приходит и вы думаете «ну ок» — он бесполезен. Если приходит 50 алертов в день — вы перестанете на них смотреть.

Настройка Sentry Alert Rules:

Правило 1 — новые ошибки:
  Условие: новый тип ошибки (first seen)
  Канал: Slack #bugs
  Приоритет: HIGH

Правило 2 — рост ошибок:
  Условие: > 50 событий за 5 минут (один тип)
  Канал: PagerDuty / OpsGenie
  Приоритет: CRITICAL

Правило 3 — performance degradation:
  Условие: p95 latency > 2× baseline за 15 минут
  Канал: Slack #perf
  Приоритет: MEDIUM

Что не нужно алертить:

• Каждый 404 (пользователь опечатался в URL).
• Ошибки в старых браузерах (IE11, если вы его не поддерживаете).
• Known issues (уже есть тикет на fix).

Шаг 6: Собираем всё вместе — observability-стек

Базовый стек для SaaS-проекта (бюджет $50-300/мес):

┌─────────────────────────────────────────────┐
│                 SENTRY                        │
│  Error tracking + Performance + Alerts       │
│  $0-80/мес (Free для начала)                 │
└─────────────────────────────────────────────┘
                      +
┌─────────────────────────────────────────────┐
│               LOGROCKET                       │
│  Session replay + Frontend debugging         │
│  $0-99/seat/мес (Free для начала)            │
└─────────────────────────────────────────────┘
                      +
┌─────────────────────────────────────────────┐
│          GRAFANA + PROMETHEUS                 │
│  Infrastructure: CPU, RAM, disk, network     │
│  $0 (self-hosted)                            │
└─────────────────────────────────────────────┘

Для enterprise добавляется:

• Datadog или New Relic — единая панель для всего.
• ELK Stack (Elasticsearch, Logstash, Kibana) — централизованные логи.
• PagerDuty — эскалация алертов по графику дежурств.

Шаг 7: Настройка алертов по user journey

Самый продвинутый уровень — мониторинг не ошибок, а бизнес-метрик:

// Sentry + кастомные метрики
Sentry.metrics.increment('checkout.started');
Sentry.metrics.increment('checkout.completed');

// Алерт: если checkout.completed / checkout.started < 50% за 30 мин

Это называется Real User Monitoring (RUM). Вы видите не просто «сайт работает», а «пользователи успешно покупают».

План внедрения на неделю

Типичные ошибки при внедрении мониторинга

1. Мониторить всё подряд. Шум убивает пользу. Начните с 3-5 ключевых метрик.
2. Игнорировать алерты. Если алерт не требует действия — удалите его.
3. Не чинить known issues. Если ошибка в дашборде висит месяц — команда перестаёт доверять мониторингу.
4. Экономить на observability. $100/мес на Sentry + LogRocket экономит часы разработки. ROI очевиден.
5. Не связывать бэкенд и фронтенд. Ошибка на бэке может проявляться как «кнопка не работает» на фронте. Нужны оба слоя.

Чеклист: готов ли ваш мониторинг

• Все критические user journeys покрыты error tracking
• Алерты настроены и протестированы (проверьте: пришлите тестовую ошибку)
• Performance метрики собираются (p50, p95, p99)
• Session replay работает на checkout и onboarding
• Дашборд показывает состояние системы за последние 24 часа
• Команда знает, куда смотреть при инциденте
• Есть runbook: что делать при каждом типе алерта
• Инфраструктурные метрики (CPU, RAM, disk) отслеживаются
• Логи агрегированы в одном месте
• Раз в месяц — ревью алертов: убрать шум, добавить новое

Что дальше

После базового стека можно двигаться в сторону:

• Synthetic monitoring (Checkly, Pingdom) — эмулирует пользовательские действия по расписанию.
• Status page (Atlassian Statuspage, Cachet) — публичная страница статуса для пользователей.
• Distributed tracing (OpenTelemetry + Jaeger) — трейсинг запросов через микросервисы.
• AIOps — ML-модели, предсказывающие инциденты на основе исторических данных (Datadog Watchdog, New Relic Applied Intelligence).

Но это уже enterprise-уровень. Для 90% проектов достаточно связки Sentry + LogRocket + Grafana.