Розробка кастомних 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, goroutines, черга запитів. Без цього можна бачити нормальні 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 день і запропонуємо відповідне рішення.