> Назови примеры метрик для алертов (Go)

Короткий ответ

Основные метрики для алертов: RED-метод (Rate, Errors, Duration) для HTTP-сервисов, USE-метод (Utilization, Saturation, Errors) для инфраструктуры, и бизнес-метрики (количество заказов, конверсия). Для Go-сервисов дополнительно: количество горутин, GC pause, heap usage, rate of panics. Алерты строятся на SLO-базисе: error budget burn, latency percentiles (p50, p95, p99), availability. Важно различать алерты на симптом (пользовательское восприятие) и на причину (CPU, memory).

Подробное объяснение

Метрики для алертов делятся на три категории:

Симптомные метрики - отражают то, что видит пользователь:

• latency percentiles (p50, p95, p99) - например, алерт, если p99 > 500ms в течение 5 минут
• error rate - доля 5xx ответов, обычно порог 1-5%
• throughput/rate - резкое падение или рост RPS может сигнализировать о проблеме
• availability - процент успешных запросов за окно

Причинные метрики - помогают диагностировать:

• CPU utilization, load average
• memory usage, OOM kills
• disk I/O, disk space
• network: packet loss, connection errors
• для Go: goroutine count (утечки), GC pause duration, heap in use, mutex contention

Бизнес-метрики - показывают влияние на продукт:

• количество успешных операций (заказов, платежей)
• конверсия в целевое действие
• задержка бизнес-процесса (например, время обработки очереди)

Для алертов критично использовать SLO-подход: алерт срабатывает, когда скорость сжигания error budget превышает допустимую. Например, если SLO = 99.9% за 30 дней, алерт на 2% ошибок за 1 час.

На практике

Для Go-бэкенда типичный набор:

• HTTP-сервис: p99 latency, error rate по статус-кодам, RPS. Алерт на p99 > 300ms 5 минут подряд.
• Работники/очереди: длина очереди, возраст сообщения, количество ретраев. Алерт, если очередь растёт или сообщение старше N минут.
• База данных: connection pool utilization, query latency, deadlocks.
• Go-runtime: goroutine count > порога (например, 100k), heap growth, GC pause > 100ms.
• Инфраструктура: CPU > 85% на 10 минут, memory > 90%, disk > 80%.

Важно: алерты должны быть action-able. Если на алерт нельзя ответить действием - это шум. Используйте multi-window алерты (например, 1-минутное и 5-минутное окно) для снижения ложных срабатываний.

Пример кода

GO
// Пример метрик для HTTP-сервиса с Prometheus
var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total HTTP requests",
        },
        []string{"method", "path", "status"},
    )
    httpRequestDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "HTTP request duration",
            Buckets: []float64{0.05, 0.1, 0.25, 0.5, 1, 2.5},
        },
        []string{"method", "path"},
    )
)

// Middleware для сбора метрик
func MetricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        sw := &statusWriter{ResponseWriter: w}
        next.ServeHTTP(sw, r)
        
        duration := time.Since(start).Seconds()
        httpRequestsTotal.WithLabelValues(
            r.Method, r.URL.Path, strconv.Itoa(sw.status),
        ).Inc()
        httpRequestDuration.WithLabelValues(
            r.Method, r.URL.Path,
        ).Observe(duration)
    })
}

// Пример алерта в Prometheus
// alert: HighErrorRate
// expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
// for: 5m

Как отвечать на собеседовании

Начни с классификации: симптомные vs причинные метрики. Затем приведи конкретные примеры для Go-бэкенда: latency percentiles, error rate, goroutine count, GC pause. Обязательно упомяни SLO/error budget подход - это отличает senior от middle. Покажи понимание trade-off: слишком много алертов - шум, слишком мало - пропущенные инциденты. Добавь про multi-window алерты и важность action-ability. Если спросят про конкретные инструменты - упомяни Prometheus + Alertmanager, Grafana, но не углубляйся, если не просят.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание разницы между симптомами и причинами
• знание специфики Go-runtime метрик (горутины, GC)
• умение строить алерты на основе SLO, а не просто "по порогам"
• способность отличать важные метрики от шумных
• практический опыт: как избегать ложных срабатываний, как настраивать окна

Типичные ошибки

• Называть только CPU/memory - это причинные метрики, без симптомных они бесполезны для алертов
• Предлагать алерт на каждый 5xx - нужно учитывать процент от общего трафика
• Игнорировать SLO и error budget - алерты "на глазок"
• Не упоминать Go-специфику (горутины, GC) - для senior это ожидаемо
• Предлагать слишком много алертов без приоритизации - интервьюер увидит отсутствие системного подхода
• Забывать про multi-window алерты и проблему ложных срабатываний