> Используете ли алертинг через Grafana (Go)

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

Да, использую алертинг через Grafana в связке с Prometheus. Основной подход - сбор метрик из Go-сервисов через prometheus/client_golang, настройка alerting rules в Prometheus и визуализация/управление алертами через Grafana. Для доставки уведомлений использую контакты в Grafana (Slack, email, webhook). Это стандартный и эффективный стек для observability в Go-проектах.

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

Алертинг через Grafana - это часть более широкой системы мониторинга. Обычно архитектура выглядит так:

• Go-сервис экспортирует метрики в формате Prometheus через /metrics endpoint.
• Prometheus периодически собирает эти метрики (scrape).
• В Prometheus задаются alerting rules - условия, при которых срабатывает алерт (например, error_rate > 5% в течение 5 минут).
• Grafana подключается к Prometheus как к datasource, позволяет просматривать метрики и управлять алертами.
• В Grafana настраиваются контакты (notification channels) - Slack, Telegram, email, PagerDuty, webhook.

Важный момент: есть два подхода к алертингу:

1. Alerting rules в Prometheus - алерты живут в конфиге Prometheus, Grafana их отображает и маршрутизирует. Это более гибко, так как Prometheus сам вычисляет условия и может работать даже без Grafana.

2. Alerting в Grafana - начиная с Grafana 8, есть встроенный алертинг, который позволяет создавать правила прямо в UI, без правки конфигов Prometheus. Это удобно для быстрых итераций, но менее декларативно.

На практике для Go-бэкенда чаще используют первый подход, потому что правила версионируются вместе с инфраструктурой, а Prometheus остаётся единственным источником истины по алертам.

На практике

В Go-проектах я обычно делаю так:

• Добавляю prometheus/client_golang в сервис, регистрирую кастомные метрики: http_requests_total, http_request_duration_seconds, errors_total и т.д.
• Настраиваю middleware для автоматического сбора HTTP-метрик.
• В Prometheus описываю alerting rules, например:

YAML
groups:
  - name: go_service_alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "High error rate in {{ $labels.service }}"

• В Grafana создаю dashboard, где видно текущее состояние метрик, и настраиваю контакты для уведомлений.

Также важно настроить алерты на отсутствие самих метрик (например, если сервис упал и перестал отвечать на scrape) - это часто упускают.

Пример кода

Пример middleware для Go-сервиса с Prometheus-метриками:

GO
package main

import (
    "net/http"
    "time"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    httpRequests = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "path", "status"},
    )

    httpDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "Duration of HTTP requests",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "path"},
    )
)

func init() {
    prometheus.MustRegister(httpRequests)
    prometheus.MustRegister(httpDuration)
}

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)

        httpRequests.WithLabelValues(r.Method, r.URL.Path, sw.status).Inc()
        httpDuration.WithLabelValues(r.Method, r.URL.Path).Observe(time.Since(start).Seconds())
    })
}

type statusWriter struct {
    http.ResponseWriter
    status string
}

func (w *statusWriter) WriteHeader(code int) {
    w.status = http.StatusText(code)
    w.ResponseWriter.WriteHeader(code)
}

func main() {
    mux := http.NewServeMux()
    mux.Handle("/metrics", promhttp.Handler())
    // остальные роуты

    http.ListenAndServe(":8080", metricsMiddleware(mux))
}

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

Начните с прямого ответа - да, использую. Затем кратко опишите стек: Prometheus + Grafana + client_golang. Упомяните, что алертинг настраиваете через alerting rules в Prometheus, а Grafana используете для визуализации и маршрутизации уведомлений. Если спросят про альтернативы - скажите, что рассматривали Alertmanager отдельно, но в текущем проекте хватает возможностей Grafana. Покажите понимание trade-off: Prometheus rules - декларативно и версионируется, Grafana alerting - быстрее в настройке, но хуже для инфраструктуры как код.

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

Интервьюер хочет понять:

• Умеете ли вы проектировать наблюдаемость сервиса, а не просто "ставить дашборды".
• Понимаете ли разницу между метриками, логами и трейсами, и где место алертинга.
• Знаете ли, как устроен сбор метрик в Go: middleware, histogram, counter, gauge.
• Умеете ли настраивать условия алертов, чтобы не было ложных срабатываний.
• Понимаете ли, как алерты связаны с процессом реагирования на инциденты.

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

• Отвечать, что алертинг - это только "красные уведомления в Slack", без понимания правил и условий.
• Не упоминать про алерты на отсутствие метрик (например, сервис умер).
• Говорить, что используете только Grafana alerting, игнорируя Prometheus rules - это может быть нормально, но нужно объяснить почему.
• Путать метрики приложения и метрики инфраструктуры (CPU, память) - для Go-бэкенда важны и те, и другие, но алерты должны быть разные.
• Не упоминать про дедупликацию и группировку алертов - это важная часть настройки, чтобы не спамить.