Ответ
На последнем проекте мы использовали стек Prometheus + Grafana + Alertmanager. Основные группы метрик были следующими:
-
HTTP-метрики (RED)
- Собирались с помощью middleware для
net/http
и библиотекиprometheus/client_golang
. - Latency: Гистограмма времени ответа (
prometheus.HistogramVec
) с разделением по эндпоинтам и HTTP-методам. - Request Rate: Счетчик запросов (
prometheus.CounterVec
) с лейблами:path
,method
,status_code
. - Error Rate: Рассчитывался в Grafana на основе данных из счетчика запросов.
// Пример метрики для подсчета HTTP-запросов var httpRequestsTotal = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", }, []string{"path", "method", "code"}, )
- Собирались с помощью middleware для
-
Бизнес-метрики
- Счетчики ключевых бизнес-операций. Например, количество созданных заказов или обработанных платежей.
- Использование лейблов позволяло разделять успешные и неуспешные операции.
var ordersProcessed = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "orders_processed_total", Help: "Total processed orders", }, []string{"status"}, // "success", "failed" )
-
Метрики зависимостей
- База данных: Время выполнения запросов (histogram), количество активных и простаивающих соединений в пуле.
- Внешние API: Время ответа и количество ошибок при обращении к сторонним сервисам.
-
Системные метрики Go
- Стандартные метрики, предоставляемые
prometheus/client_golang
, включая статистику GC, количество горутин, использование памяти (go_memstats_*
).
- Стандартные метрики, предоставляемые
Такой подход позволял нам не только отслеживать общее состояние сервиса (SLA/SLO), но и быстро диагностировать проблемы, определяя, где именно произошел сбой: в нашем коде, в базе данных или во внешнем сервисе.