Средний

Метрики и алерты

Урок 3 из 3 в курсе Наблюдаемость backend-сервисов

Содержание курса (3/3)

Метрики и алерты

метрики — числовые сигналы о состоянии системы; алерты оповещают о проблемах.

Почему это важно: Метрики и алерты превращают 'реактивное' реагирование на жалобы пользователей в 'проактивное' обнаружение проблем.

Главная идея

Четыре golden signals: latency, traffic, errors, saturation. Алерты стройте на SLO, а не на инфраструктурных метриках.

Как это выглядит на практике

  1. Приложение экспортирует метрики в Prometheus-совместимом формате.
  2. Prometheus регулярно скрейпит эндпоинт /metrics.
  3. Grafana визуализирует данные в дашбордах.
  4. Alertmanager отправляет уведомления при нарушении SLO.

Что происходит под капотом

  • Counter: монотонно растущий счётчик (запросы, ошибки).
  • Gauge: мгновенное значение (температура, активные соединения).
  • Histogram: распределение значений (latency p50/p95/p99).
  • SLO: Service Level Objective, целевой показатель (например, 99.9% запросов быстрее 200ms).

Типичные ошибки и заблуждения

  • Ошибка: метрики на CPU/RAM достаточно. Они не говорят о поведении приложения.
  • Ошибка: алерт на всё подряд. Alert fatigue приводит к игнорированию алертов.
  • Ошибка: среднее время ответа показательно. p99 важнее, чем avg, для пользовательского опыта.
  • Ошибка: алерты = мониторинг. Алерты — это триггеры действий, дашборды — инструменты анализа.

Ключевые выводы

  • Четыре golden signals покрывают большинство случаев.
  • SLO-based alerting эффективнее чем threshold на метриках.
  • p99 важнее avg.
  • Alert fatigue убивает команду — алерты должны быть actionable.

Термины урока

Golden signals: latency, traffic, errors, saturation.
SLI: Service Level Indicator, метрика качества.
SLO: Service Level Objective, целевое значение SLI.
Alert fatigue: снижение реакции на алерты из-за их избытка.

Связь с работой backend-разработчика

Хорошие метрики и алерты — разница между 'узнали от пользователей' и 'починили до жалоб'. Это основа надёжности сервиса.

Мини-разбор реальной ситуации

Команда настроила алерт на 'CPU > 80%'. Он срабатывал каждую ночь при бэкапах, все его игнорировали, и никто не заметил, как сервис реально упал на час.

Что запомнить

  • Алерты должны требовать действий.
  • SLO > пороги на метриках.
  • p99 > avg.

Итог

Метрики и алерты — не роскошь, а обязательная часть production-grade сервиса.

Комментарии к уроку

Войдите, чтобы оставить комментарий.

Пока нет комментариев — будьте первым.