Разработка кастомных Grafana-дашбордов для приложений

Разработка кастомных Grafana-дашбордов для приложений

Мы часто сталкиваемся с ситуацией: инфраструктурные метрики в порядке, а пользователи жалуются на медленную работу API. Без дашборда приложения приходится греп-логить и надеяться на лучшее. С правильно настроенным дашбордом — 2 минуты на диагностику. Наш опыт показывает, что для сервиса с 50 000 RPS правильно спроектированный дашборд сокращает MTTR с 30 минут до 3-5.

Инфраструктурный дашборд показывает состояние железа: CPU, память, диск. Дашборд приложения — это метрики, важные для разработчика: количество запросов, процент ошибок, латентность по эндпоинтам, состояние пулов соединений. Разберем, как мы создаем такие дашборды под ключ для микросервисов.

Почему инфраструктурного дашборда недостаточно?

Типичный пример: CPU загружен на 30%, память свободна, но p95 latency скачет до 2 секунд. Инфраструктурный дашборд не покажет, что проблема в медленном SQL запросе или блокировке в пуле соединений. Только дашборд приложения с метриками бизнес-логики позволяет локализовать проблему за минуты.

Какие метрики нужно экспортировать?

Приложение должно самостоятельно экспортировать метрики. Для Go используем prometheus/client_golang, для Python — prometheus_client, для Node.js — prom-client, для Java — Micrometer с Prometheus registry. Без инструментирования нет данных, без данных нет дашборда.

Минимальный набор метрик, который должно экспортировать каждое HTTP-приложение:

var (
	httpRequestsTotal = prometheus.NewCounterVec(
		prometheus.CounterOpts{
			Name: "http_requests_total",
			Help: "Total number of HTTP requests",
		},
		[]string{"method", "path", "status_code"},
	)
	httpRequestDuration = prometheus.NewHistogramVec(
		prometheus.HistogramOpts{
			Name: "http_request_duration_seconds",
			Help: "HTTP request duration in seconds",
			Buckets: []float64{0.01, 0.05, 0.1, 0.5, 1, 2, 5},
		},
		[]string{"method", "path", "status_code"},
	)
)

Именно с этими метриками строится основная часть application dashboard.

Ключевые панели дашборда приложения

Request rate — количество запросов в секунду, разбитое по статус-кодам. Быстро виден рост ошибок:

sum by (status_code) ( rate(http_requests_total{service="$service"}[5m]) ) 

Error rate — процент 5xx от общего трафика. Этот показатель часто вешают как stat panel с пороговой подсветкой: зелёный до 1%, жёлтый до 5%, красный выше:

sum(rate(http_requests_total{service="$service", status_code=~"5.."}[5m])) / sum(rate(http_requests_total{service="$service"}[5m])) * 100 

Latency percentiles — p50, p95, p99. Среднее значение latency почти всегда обманывает. p99 — то, что видит 1% самых невезучих пользователей:

histogram_quantile(0.99, sum by (le, method) ( rate(http_request_duration_seconds_bucket{service="$service"}[5m]) ) ) 

Saturation — состояние ресурсов приложения: размер connection pool, горутины, очередь запросов. Без этого можно видеть нормальные latency прямо до момента, когда сервис ляжет под нагрузкой.

Типичные SLO thresholds:

Drill-down структура

Хороший набор дашбордов для сервиса строится в три уровня.

Overview — состояние всех инстансов сервиса на одном экране. Если что-то красное — понятно, где смотреть дальше.

Instance detail — один инстанс с полным набором метрик: request rate, latency breakdown по endpoint, error rate, JVM heap (если Java), goroutines (если Go), DB connection pool usage.

Endpoint detail — конкретный HTTP endpoint. Latency distribution (histogram heatmap), размер payload запросов/ответов, downstream зависимости. Этот уровень нужен при дебаге конкретной медленной операции.

Переход между уровнями через data link — клик по инстансу на overview открывает instance detail с правильными переменными. Это не настраивается автоматически, нужно прописывать вручную через Data links в panel settings.

Аннотации деплоев

Деплой приложения должен быть виден на дашборде. Аннотация через Grafana Annotations API или Prometheus event:

curl -X POST http://grafana:3000/api/annotations \
  -H "Content-Type: application/json" \
  -d '{ "time": '"$(date +%s000)"', "tags": ["deployment", '"$SERVICE_NAME"'], "text": "Deploy '"$VERSION"' to production" }'

В Grafana это отображается как вертикальная линия на всех time series панелях. Если после деплоя p99 latency выросла — это видно немедленно, без ручного сопоставления времени деплоя с графиком.

Процесс разработки дашборда

Начинаем с инвентаризации метрик: что экспортирует приложение, какие labels доступны, есть ли SLO которые нужно отражать. Без понимания доступных метрик дашборд не получится.

Дальше — структура дашборда согласуется с командой разработки: они лучше знают, какие endpoint критичны, какие downstream зависимости важны, какие метрики они сами смотрят при отладке.

Реализация: панели, переменные, data links между уровнями, threshold colors, единицы измерения (не «значение 0.045», а «45 ms»). Финально — provisioning JSON в git и документация по добавлению новых метрик.

Что входит в работу (deliverables)

• Аудит существующих метрик и экспортеров
• Проектирование структуры дашбордов (макет)
• Реализация панелей, переменных, data links
• Настройка аннотаций деплоев
• Документация по эксплуатации (README, provisioning JSON)
• Обучение команды (1 час)
• Гарантия на результат: мы не сдаем дашборд, пока не получим подтверждение, что все метрики корректны

Сроки: дашборд для одного сервиса с тремя уровнями детализации — 2-3 дня. Стандартизированный шаблон для типового микросервиса — 1-2 дня, дальше адаптация под конкретные сервисы быстрее.

Как ускорить разработку дашбордов с помощью шаблонов?

Мы подготовили шаблоны для типовых микросервисов (Go, Python, Java). Они покрывают 80% типовых метрик. Адаптация под специфические требования занимает всего день. Более 5 лет опыта в DevOps позволяют нам гарантировать, что дашборд будет соответствовать лучшим практикам Prometheus и Grafana.

Хотите такой же дашборд для своего сервиса? Свяжитесь с нами — оценим проект за 1 день и предложим подходящее решение.