Мониторинг и алёрты

Спроектируй мониторинг для {{service}}.

Три уровня сигналов (USE / RED)

RED (для сервисов с трафиком)

• Rate — RPS, EPS
• Errors — % ошибочных ответов
• Duration — latency P50/P95/P99

USE (для ресурсов)

• Utilization — CPU, RAM, диск, сеть %
• Saturation — очереди, queue depth
• Errors — host-level errors

Что точно надо собирать

1. Доступность

   • Uptime: external check каждую минуту
   • SSL expiry: алёрт за 14 дней до
   • DNS check

2. Latency

   • P50 / P95 / P99 для каждого endpoint
   • Cold start time (если serverless)
   • DB query time top-10

3. Ошибки

   • 5xx rate
   • Uncaught exceptions
   • Failed background jobs
   • DLQ size

4. Бизнес-метрики

   • Signups per hour
   • Payment success rate
   • Active users (низкие значения = алёрт даже если технически всё ок)

5. Resource health

   • CPU > 80% длится 5+ минут
   • RAM > 85%
   • Disk > 80%
   • DB connections > 80% от лимита

Алёрты: иерархия

P1 — Page кто-то прямо сейчас
     - Сайт упал
     - Платежи не проходят
     - DB недоступна
     - Massive data loss

P2 — Notify в чат (не будит)
     - Высокая latency 30+ минут
     - Error rate выше нормы
     - Очередь растёт быстрее обычного

P3 — Just log / ticket
     - Метрики дрифтуют
     - Disk заполнится через 30 дней

Anti-spam правила

• Symptom-based, не cause-based — алёрт "Сайт упал", а не "Health-check provider не получил ответ от прокси-1"
• Threshold должен срабатывать редко — если 5 раз в день, никто не реагирует
• Окно > 1 точка — не на одиночный спайк, а на устойчивое отклонение
• Auto-resolve — алёрт сам закрывается когда проблема ушла
• Snooze / mute — на время известных багов

Runbooks

Каждый алёрт ссылается на runbook:

# Alert: 5xx rate > 1%

**Severity:** P1
**SLO impact:** да

## Что проверить
1. /admin/dashboard — какой endpoint?
2. Sentry — какой stacktrace?
3. Если DB — `SELECT * FROM pg_stat_activity` для long queries

## Известные кейсы
- Если 5xx только от /api/checkout — почини X
- Если повсюду — DB issue

## Escalation
- 30 минут без понимания → разбуди backend lead

Дашборды

Три типа:

• Overview (для всех): SLI/SLO главное
• Service-specific: метрики одного сервиса
• Incident response: что смотреть в инциденте

Не делай "дашборд со всем" — он бесполезен.

Принципы

• Алёрт на симптом, ссылка на причину
• Каждый алёрт ≥ 1 раз ловил реальную проблему — иначе удаляй
• Дашборд — для answer'а на вопрос, не для красоты
• On-call график честный (включая компенсацию)