Какими метриками будешь покрывать сервис

Стратегия метрического покрытия сервиса на Go

При построении системы метрик для сервиса я руководствуюсь принципами "Four Golden Signals" от Google (Latency, Traffic, Errors, Saturation) и дополняю их специфичными для бизнес-логики и инфраструктуры показателями. В Go-экосистеме стандартным решением является использование библиотеки Prometheus через prometheus/client_golang.

1. Основные категории метрик

A. Метрики инфраструктуры и рантайма

// Пример экспорта метрик рантайма Go
import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/collectors"
)

func registerRuntimeMetrics() {
    // Стандартные коллекторы Go
    prometheus.MustRegister(collectors.NewGoCollector())
    prometheus.MustRegister(collectors.NewProcessCollector(
        collectors.ProcessCollectorOpts{},
    ))
}

Ключевые метрики:

• Использование памяти: go_memstats_alloc_bytes, go_memstats_heap_inuse_bytes
• Горутины: go_goroutines — мониторинг утечек
• GC паузы: go_gc_duration_seconds — перцентили времени сборки мусора
• Количество потоков: go_threads

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

var (
    requestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )
    
    requestDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "Request duration distribution",
            Buckets: prometheus.DefBuckets, // или кастомные бакеты
        },
        []string{"method", "endpoint"},
    )
)

2. Обязательные метрики для любого сервиса

2.1. HTTP/GRPC метрики

• Скорость запросов: rate(http_requests_total[5m]) — трафик
• Латентность: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) — перцентили
• Статусы ответов: разделение по кодам 2xx/3xx/4xx/5xx
• Размеры запросов/ответов: для выявления аномалий

2.2. Метрики ошибок

errorsTotal := prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "service_errors_total",
        Help: "Total business logic errors",
    },
    []string{"error_type", "component"},
)

• Коэффициент ошибок: rate(service_errors_total[5m]) / rate(http_requests_total[5m])
• Критические ошибки: паники, таймауты, ошибки подключений к БД

2.3. Метрики зависимостей

dbQueryDuration := prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "db_query_duration_seconds",
        Help:    "Database query duration",
        Buckets: []float64{.001, .005, .01, .025, .05, .1, .25, .5, 1},
    },
    []string{"operation", "table"},
)

• Латентность внешних вызовов: БД, кэши, другие сервисы
• Коэффициент ошибок зависимостей: rate(db_errors_total[5m])
• Таймауты и ретраи: для выявления проблем в цепочке вызовов

3. Продвинутые метрики для сложных сервисов

3.1. Метрики очередей и буферов

queueLength := prometheus.NewGaugeVec(
    prometheus.GaugeOpts{
        Name: "message_queue_length",
        Help: "Current queue length",
    },
    []string{"queue_name"},
)

• Длина очереди: для асинхронной обработки
• Время пребывания в очереди: rate(queue_processing_duration_seconds_sum[5m])

3.2. Метрики кэширования

cacheHitRatio := prometheus.NewGaugeVec(
    prometheus.GaugeOpts{
        Name: "cache_hit_ratio",
        Help: "Cache hit ratio percentage",
    },
    []string{"cache_name"},
)

• Hit/Miss ratio: эффективность кэширования
• Размер кэша: память/количество элементов
• Время инвалидации: для TTL-based кэшей

3.3. Метрики бизнес-логики

ordersProcessed := prometheus.NewCounter(
    prometheus.CounterOpts{
        Name: "orders_processed_total",
        Help: "Total processed orders",
    },
)

• Ключевые бизнес-события: регистрации, платежи, конверсии
• Средний чек/стоимость: для финансовых сервисов
• Пользовательская активность: DAU/MAU, сессии

4. Инструментарий и best practices

4.1. Подход к инструментации:

// Middleware для HTTP-метрик
func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        rw := &responseWriter{w, http.StatusOK}
        
        next.ServeHTTP(rw, r)
        
        duration := time.Since(start).Seconds()
        requestDuration.WithLabelValues(r.Method, r.URL.Path).Observe(duration)
        requestsTotal.WithLabelValues(r.Method, r.URL.Path, strconv.Itoa(rw.status)).Inc()
    })
}

4.2. Рекомендации по реализации:

• Лейблы: Использовать ограниченное количество лейблов (не более 10)
• Кардинальность: Избегать высококардинальных лейблов (user_id, session_id)
• Сборщики: Использовать NewConstMetric для кастомных экспортеров
• Интервалы: Настраивать соответствующие scrape интервалы в Prometheus

4.3. Мониторинг метрик:

• SLO/SLA: Настраивать алерты на основе целевых показателей
• Скорость роста: rate() для выявления аномалий
• Capacity planning: Мониторинг лимитов ресурсов

5. Дополнительные системы мониторинга

Помимо Prometheus, интегрирую:

• Tracing (Jaeger/Tempo): для распределенной трассировки
• Logging (Loki): структурированные логи с correlation ID
• Профилирование (pprof): CPU, memory, goroutine профили

Итог: Моя стратегия строится на многоуровневом подходе — от низкоуровневых метрик рантайма Go до высокоуровневых бизнес-показателей, с обязательным покрытием всех четырех золотых сигналов и построением meaningful dashboards в Grafana для каждого микросервиса.