Мониторинг бэкенда мобильного приложения: 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.

Какие метрики критичны для бэкенда мобильного приложения?

Для бэкенда мобильного приложения критичны четыре группы метрик:

Дополнительно рекомендуем мониторить 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

Как настроить алертинг?

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 — не поднимать алерт при кратковременных всплесках, только при устойчивой деградации. Пошаговая инструкция:

1. Установить Alertmanager и настроить receivers (Telegram, Slack).
2. Создать файл rules.yml с описанными правилами.
3. Добавить файл в prometheus.yml секцию rule_files.
4. Проверить правила через promtool check rules rules.yml.
5. Настроить маршрутизацию: 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 день. Получите консультацию по выбору метрик и порогов алертов.