Пороги оповещений

Настройте, когда срабатывают оповещения, на основе производительности мониторов.

Пороги мониторов

Порог сбоев

Количество последовательных сбоев перед оповещением:

Default: 3 consecutive failures
Recommended: 
  - Critical services: 2
  - Normal services: 3
  - Low-priority: 5

Пример: монитор проверяется каждые 60 с, порог = 3

  • Сбой в 10:00 (1/3)
  • Сбой в 10:01 (2/3)
  • Сбой в 10:02 (3/3) → ОПОВЕЩЕНИЕ СРАБОТАЛО

Порог восстановления

Последовательные успешные проверки до статуса «восстановлено»:

Default: 2 consecutive successes
Recommended:
  - Quick recovery: 1
  - Stable recovery: 2
  - Confirmed recovery: 3

Пример: оповещение активно, порог = 2

  • Успех в 10:05 (1/2)
  • Успех в 10:06 (2/2) → ОПОВЕЩЕНИЕ ЗАКРЫТО

Пороги времени отклика

Статические пороги

Фиксированные значения в миллисекундах:

// Dashboard → Monitors → [Monitor] → Alert Settings
{
  response_time_warning: 1000,   // 1 second
  response_time_critical: 3000   // 3 seconds
}

Динамические пороги (на основе ML)

Автоматическая подстройка на основе исторических паттернов:

Enable: Dashboard → Monitors → [Monitor] → Dynamic Thresholds

Learning period: 7 days
Threshold: Baseline + 2 standard deviations

Преимущества:

  • Адаптация к паттернам трафика
  • Меньше ложных срабатываний
  • Обнаружение постепенной деградации

Пороги HTTP-статусов

Ожидаемые коды статуса

Monitor Settings → Expected Status → 200

Alert if: 
  - 4xx errors (client errors)
  - 5xx errors (server errors)
  - Unexpected redirects

Порог частоты ошибок

Alert if error rate > X% over Y minutes

Example:
  - Error rate > 5% over 5 minutes → Warning
  - Error rate > 10% over 5 minutes → Critical

Пороги SSL-сертификатов

За сколько дней до истечения оповещать:

Default: 30 days

Recommended:
  - 1st alert: 30 days
  - 2nd alert: 14 days  
  - 3rd alert: 7 days
  - Critical: 3 days

Пороги пользовательских метрик

Для пользовательских метрик (CPU, память, диск):

Dashboard → Servers → [Server] → Thresholds

CPU Usage:
  Warning: 70%
  Critical: 85%

Memory Usage:
  Warning: 80%
  Critical: 90%

Disk Usage:
  Warning: 75%
  Critical: 85%

Стратегии порогов

Консервативная (мало оповещений)

Failure threshold: 5
Recovery threshold: 3
Response time: 3000ms
Error rate: 10%

Применять для: некритичных сервисов, сред разработки

Сбалансированная (рекомендуется)

Failure threshold: 3
Recovery threshold: 2
Response time: 1000ms (or dynamic)
Error rate: 5%

Применять для: продакшен-сервисов, клиентских приложений

Агрессивная (максимальный uptime)

Failure threshold: 1
Recovery threshold: 1
Response time: 500ms (or dynamic)
Error rate: 1%

Применять для: критически важных сервисов, API с SLA

Группировка оповещений

Предотвратите спам оповещениями:

Dashboard → Alert Settings → Grouping

Group by:
  - Monitor group
  - Time window (5 minutes)

Result:
  10 monitors down → 1 grouped alert instead of 10

Политики эскалации

Автоматическая эскалация неподтверждённых оповещений:

Dashboard → Alert Settings → Escalation

1. Alert → Slack #monitoring (instant)
2. After 10min → Email team lead
3. After 30min → SMS on-call engineer
4. After 1hour → Voice call manager

Тестирование порогов

Симулируйте сбой для тестирования:

Dashboard → Monitors → [Monitor] → Test Alert

Triggers: 
  - Immediate failure
  - Threshold countdown
  - Alert channels activated
  - No actual monitoring affected

Рекомендации

СТОИТ:

  • Использовать динамические пороги для переменного трафика
  • Настраивать политики эскалации
  • Тестировать конфигурацию порогов
  • Пересматривать и корректировать на основе ложных срабатываний

НЕ СТОИТ:

  • Задавать слишком низкие пороги (усталость от оповещений)
  • Игнорировать настройку порогов
  • Использовать одинаковые пороги для всех мониторов
  • Пропускать тестирование

Настройка через API

# Update monitor thresholds
curl -X PUT \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"failure_threshold":3,"recovery_threshold":2}' \
  https://statusradar.dev/api/monitors/{id}/thresholds

Дальнейшие шаги