Мониторинг и алерты: узнавать о проблеме раньше клиента

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

Мониторинг — это не панель с красивыми графиками. Это ответ на два вопроса: работает ли сейчас и что именно сломалось. Всё остальное — детали реализации.

Четыре сигнала, которые нужны всегда

Среднее время ответа сюда не входит осознанно: оно скрывает проблемы. При среднем в 300 мс десятая часть пользователей может ждать по восемь секунд, и по среднему это не видно. Процентили показывают реальную картину.

Структурные логи

Строка «Ошибка при сохранении» бесполезна: непонятно, у какого пользователя, в каком запросе и что именно не сохранилось. Логи должны быть машиночитаемыми, с одинаковым набором полей и идентификатором запроса, по которому можно собрать всю цепочку.

type LogFields = {
  requestId: string
  userId?: string
  route: string
  durationMs?: number
  [key: string]: unknown
}

export function logEvent(level: "info" | "warn" | "error", message: string, fields: LogFields) {
  // Одна строка — один объект JSON: так его разберёт любой сборщик логов
  console.log(JSON.stringify({
    level,
    message,
    ts: new Date().toISOString(),
    ...fields,
  }))
}

// Использование: по requestId собирается вся история одного запроса
logEvent("error", "Не удалось создать заказ", {
  requestId,
  userId: session.user.id,
  route: "/api/orders",
  reason: "insufficient_stock",
  productId,
})

Алерты, которые не игнорируют

Главный враг оповещений — их количество. Если приходит двадцать сообщений в день и девятнадцать из них ни о чём, двадцатое тоже не прочитают. Поэтому у нас правило: алерт означает необходимость действия. Всё остальное — панель, куда смотрят по расписанию.

• Оповещение срабатывает на симптом для пользователя, а не на технический факт: важна доля ошибок, а не перезапуск процесса
• У каждого алерта есть порог по времени: скачок на 30 секунд не повод будить человека
• В тексте — ссылка на график и на логи по нужному фильтру
• Есть дежурный, а не рассылка на всех: рассылка на всех означает, что не реагирует никто
• Раз в месяц алерты пересматриваются: сработавшие ни о чём отключаются

groups:
  - name: web
    rules:
      - alert: HighErrorRate
        # Условие должно держаться 5 минут — иначе это шум
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Более 1% запросов с ошибкой"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

Что мы настраиваем на старте

1. 01Сбор необработанных исключений с трассировкой и контекстом запроса
2. 02Структурные логи с идентификатором запроса и сроком хранения 30 дней
3. 03Проверка доступности снаружи с оповещением при двух неудачах подряд
4. 04Метрики по времени ответа и доле ошибок с разбивкой по маршрутам
5. 05Наблюдение за фоновыми задачами: возраст старейшей и число проваленных

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