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