Куда собирают метрики?

Метрики в Go-приложениях: куда и как собирать

В современных Go-приложениях метрики собирают в несколько типов систем, образующих полноценный мониторинговый стек. Выбор конкретных инструментов зависит от масштаба проекта, требований к производительности и уже существующей инфраструктуры.

Основные направления сбора метрики

1. Системы временных рядов (Time-Series Databases)

Это специализированные БД для хранения и обработки метрик с временными метками:

• Prometheus — де-факто стандарт для Go-приложений благодаря встроенной поддержке в библиотеке prometheus/client_golang. Метрики экспортируются через HTTP endpoint /metrics, откуда их забирает Prometheus скрейпер.

import (
    "net/http"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
    // Регистрируем кастомную метрику
    requestsTotal := prometheus.NewCounter(prometheus.CounterOpts{
        Name: "http_requests_total",
        Help: "Total HTTP requests",
    })
    prometheus.MustRegister(requestsTotal)
    
    // Экспортируем метрики
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":8080", nil)
}

• InfluxDB — популярна в IoT и сценариях с высокой частотой записи данных.
• TimescaleDB — расширение PostgreSQL для работы с временными рядами.
• VictoriaMetrics — высокопроизводительная альтернатива Prometheus с обратной совместимостью.

2. Агенты-посредники и коллекторы

Для сложных распределенных систем часто используют промежуточные компоненты:

• StatsD/Graphite стек — метрики отправляются по UDP протоколу через StatsD агент, который агрегирует и пересылает в Graphite. Библиотека github.com/alexcesaro/statsd позволяет легко интегрировать в Go-приложение:

import "github.com/alexcesaro/statsd"
func main() {
    c, _ := statsd.New(statsd.Address("localhost:8125"))
    defer c.Close()
    c.Increment("api.calls") // Отправка метрики в StatsD
}

• Telegraf — универсальный агент от InfluxData, поддерживающий множество форматов ввода/вывода.
• Vector или Fluent Bit — для сбора и трансформации метрик и логов.

3. Облачные и SaaS-решения

Для проектов без собственной инфраструктуры мониторинга:

• Datadog — комплексная платформа с богатым набором интеграций.
• Grafana Cloud — управляемый стек на основе Prometheus и Loki.
• New Relic, Signoz, Honeycomb — решения с акцентом на observability.
• Облачные провайдеры: AWS CloudWatch, Google Cloud Monitoring, Azure Monitor.

4. Распределенная трассировка

Для отслеживания запросов в микросервисных архитектурах:

• Jaeger — наиболее популярная система трассировки для Go (библиотека go.opentelemetry.io/otel).
• Zipkin — альтернативная система с похожей архитектурой.
• Данные трассировки часто хранят отдельно от метрик — в Elasticsearch или специализированных хранилищах.

Практические подходы к сбору метрик в Go

Экспорт через HTTP endpoint

Наиболее распространенный подход для Prometheus:

// Использование готовых экспортеров для базовых метрик
import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/collectors"
)

func main() {
    // Автоматический сбор метрик Go runtime
    reg := prometheus.NewRegistry()
    reg.MustRegister(collectors.NewGoCollector())
    reg.MustRegister(collectors.NewProcessCollector(collectors.ProcessCollectorOpts{}))
}

Push-модель через шлюз

Когда pull-модель недоступна (например, в serverless или за NAT):

// Push метрик в Pushgateway для кратковременных задач
import "github.com/prometheus/client_golang/prometheus/push"

func pushMetrics() {
    if err := push.New("http://pushgateway:9091", "my_job").
        Collector(myMetric).
        Grouping("instance", "my_instance").
        Push(); err != nil {
        log.Printf("Failed to push metrics: %v", err)
    }
}

Архитектурные рекомендации

• Многоуровневая отправка: Приложения могут отправлять метрики одновременно в несколько систем через адаптеры.
• Аггрегация на стороне приложения: Используйте гистограммы и суммарии для агрегации до отправки, чтобы уменьшить нагрузку.
• Конфигурируемость: Реализуйте возможность динамического переключения бэкендов через конфигурацию.
• OpenTelemetry: Для новых проектов рассмотрите стандарт OpenTelemetry, который унифицирует сбор метрик, трассировки и логов:

import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/prometheus"
)

func initMetrics() {
    exporter, _ := prometheus.New()
    meterProvider := metric.NewMeterProvider(metric.WithReader(exporter))
    otel.SetMeterProvider(meterProvider)
}

Типичный стек в production

1. Приложение → Prometheus (основные метрики)
2. Prometheus → Grafana (визуализация)
3. Приложение → Jaeger (трассировка)
4. Приложение → StatsD → Graphite (бизнес-метрики с агрегацией)
5. Все системы → AlertManager (оповещения)

Критически важно не только выбрать правильные системы для сбора метрик, но и настроить их ретеншн-политики, механизмы агрегации старых данных и эффективные схемы выборки для высоконагруженных систем. В Go-экосистеме сегодня доминирует связка Prometheus + Grafana, но для специфических случаев (высокая кардинальность метрик, особые требования к задержкам) стоит рассматривать альтернативы.