Моніторинг бекенду мобільного застосунку: Prometheus + Grafana під ключ
Уявіть: ваш мобільний застосунок раптово починає гальмувати, а Crashlytics мовчить. Користувачі йдуть, а ви не бачите причини. Це типова ситуація, коли проблема на бекенді — і без моніторингу її не знайти. Ми налаштовуємо повний стек моніторингу бекенду мобільних застосунків на базі Prometheus та Grafana, щоб ви бачили кожен збій та деградацію до того, як вони вплинуть на користувачів.
За 5+ років роботи ми провели понад 50 впроваджень для iOS та Android проєктів — від стартапів до enterprise. Гарантуємо, що через 2 дні після старту ви отримаєте робочий дашборд з ключовими метриками. Інвестиція в моніторинг окупається за 1-2 місяці: середній SLA-штраф при простої може досягати 5000 у.о. на годину, а моніторинг дозволяє скоротити час виявлення інцидентів на 80%.
Чому саме Prometheus?
Згідно з документацією Prometheus, pull-модель збору метрик спрощує виявлення нових цілей через service discovery та знижує навантаження на мережу. Prometheus масштабується до 10^6 метрик на одному інстансі, тоді як Zabbix починає гальмувати при 10^5. Багатовимірна модель даних з лейблами дозволяє гнучко фільтрувати та агрегувати — наприклад, подивитися latency лише для endpoints з методом POST.
Які метрики критичні для бекенду мобільного застосунку?
Для бекенду мобільного застосунку критичні чотири групи метрик:
| Тип метрики | Приклади | Чому важливі |
|---|---|---|
| API-метрики | latency, error rate, throughput | p95 та p99 latency безпосередньо впливають на UX. Середнє значення приховує хвостові затримки. |
| Метрики БД | active connections, query duration, lock waits | Повільні запити — часта причина деградації. pg_stat_statements допомагає знайти їх. |
| Метрики інфраструктури | CPU, RAM, disk I/O | Вузькі місця на серверах призводять до падінь. |
| Метрики черг | глибина черги, lag consumer | Фонова обробка повинна встигати. |
Додатково рекомендуємо моніторити SSL-сертифікати: термін дії закінчується — користувачі не можуть підключитися. Для цього використовуємо blackbox_exporter.
Як інструментувати API-сервер?
Prometheus очікує метрики у своєму форматі. Для різних мов — готові клієнтські бібліотеки:
# Python (FastAPI / Flask)
from prometheus_fastapi_instrumentator import Instrumentator
app = FastAPI()
Instrumentator().instrument(app).expose(app)
# Endpoint /metrics з'являється автоматично
// Go (Echo / Gin)
import "github.com/prometheus/client_golang/prometheus/promhttp"
func setupMetrics(e *echo.Echo) {
httpRequestsTotal := prometheus.NewCounterVec(
prometheus.CounterOpts{Name: "http_requests_total"},
[]string{"method", "path", "status"},
)
prometheus.MustRegister(httpRequestsTotal)
e.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
err := next(c)
httpRequestsTotal.WithLabelValues(
c.Request().Method, c.Path(),
strconv.Itoa(c.Response().Status),
).Inc()
return err
}
})
e.GET("/metrics", echo.WrapHandler(promhttp.Handler()))
}
Важно: не створюйте метрику з path як high-cardinality label — якщо в path є user_id або інші динамічні значення, Prometheus захлинеться. Нормалізуйте шлях: /users/12345/profile → /users/:id/profile. Також налаштовуємо кастомні метрики для бізнес-логіки: кількість замовлень, помилки аутентифікації, час відповіді зовнішніх API.
Яка конфігурація Prometheus підходить для production?
Базовий prometheus.yml для мобільного бекенду:
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'api-server'
static_configs:
- targets: ['api:8080']
metrics_path: /metrics
- job_name: 'postgres'
static_configs:
- targets: ['postgres-exporter:9187']
- job_name: 'redis'
static_configs:
- targets: ['redis-exporter:9121']
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
Для production — Service Discovery через Consul або Kubernetes service discovery замість static_configs. Також додаємо scrape_timeout по 10s, щоб не чекати завислі ендпоінти.
Як ми це робимо: кейс з практики
Один наш клієнт з мобільним застосунком для доставки зіткнувся з ростом p99 latency до 12 секунд. Після впровадження моніторингу виявили вузьке місце в запиті до PostgreSQL — був відсутній індекс. Оптимізація зайняла 2 години, а latency впала до 200ms (покращення в 60 разів). Без моніторингу ця проблема могла залишатися непоміченою тижнями, а втрати від пішлих користувачів склали б десятки тисяч у.о.
Які дашборди будуємо в Grafana?
Не потрібно будувати дашборди з нуля — Grafana.com/dashboards містить готові: ID 1860 для Node Exporter, ID 9628 для PostgreSQL через postgres_exporter. Імпортуються одним кліком.
Для API-моніторингу будуємо кастомний дашборд з ключовими панелями:
-
rate(http_requests_total[5m])— RPS по endpoint -
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))— p95 latency -
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])— error rate
| Панель | Метрика | Джерело | Важливість |
|---|---|---|---|
| RPS | rate(http_requests_total[5m]) |
API | Висока — показує навантаження |
| p95 latency | histogram_quantile(0.95, ...) |
API | Критична — впливає на UX |
| Error rate | ... / rate(...) |
API | Висока |
| Active connections | pg_stat_activity_count |
postgres_exporter | Середня |
| Queue lag | redis_queue_length |
redis_exporter | Середня |
Як налаштувати алертинг?
Grafana Alerting або Alertmanager — налаштовуємо пороги для PagerDuty/Telegram/Slack. Мінімальний набір алертів для мобільного бекенду:
# alerting/rules.yml
groups:
- name: api
rules:
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Error rate > 5% on {{ $labels.job }}"
- alert: HighLatency
expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
for: 5m
annotations:
summary: "p95 latency > 1s"
for: 2m — не піднімати алерт при короткочасних сплесках, тільки при стійкій деградації. Покрокова інструкція:
- Встановити Alertmanager та налаштувати receivers (Telegram, Slack).
- Створити файл rules.yml з описаними правилами.
- Додати файл в
prometheus.ymlсекціюrule_files. - Перевірити правила через
promtool check rules rules.yml. - Налаштувати маршрутизацію: critical алерти — в Telegram/PagerDuty, warning — в Slack.
Типові помилки при налаштуванні моніторингу
- Висока кардинальність лейблів — не включайте в path user_id або session_id.
- Відсутність порогів для алертів — без них ви дізнаєтеся про проблему тільки від користувачів.
- Ігнорування p99 latency — середнє значення приховує поодинокі уповільнення.
- Неправильний scrape_interval — надто рідкісний збір пропустить короткочасні сплески.
Що входить в нашу роботу
- Docker Compose або Kubernetes манифести для Prometheus, Grafana, Alertmanager
- Інструментування API-сервера (Python / Go / Node.js / Java)
- Підключення експортерів: postgres_exporter, redis_exporter, node_exporter
- Кастомні дашборди в Grafana під специфіку застосунку
- Налаштування алертів з маршрутизацією в Telegram / Slack / PagerDuty
- Документація по метриках і порогах алертів
Терміни та вартість
Базова установка з готовими дашбордами та алертами: 2–3 дні. Повний стек з кастомними метриками, інструментуванням коду та production-ready конфігурацією: 4–6 днів. Вартість розраховується індивідуально. Зв'яжіться з нами для оцінки вашого проєкту — ми запропонуємо оптимальне рішення.
Замовте налаштування моніторингу — оцінимо ваш проєкт за 1 день. Отримайте консультацію щодо вибору метрик та порогів алертів.