Мониторинг HTTP-запросов: Response Time и Error Rate

Отметим: когда среднее время ответа эндпоинта GET /api/feed вырастает с 200 мс до 1800 мс, пользователь чувствует тормоза, но отзывы в App Store появятся через сутки. С мониторингом вы узнаёте о проблеме через 5 минут. Команда с 10+ летним опытом мобильной разработки сталкивалась с ситуациями, когда отсутствие мониторинга HTTP-запросов приводило к потере до 30% пользователей. Мы реализовали более 50 проектов с мониторингом — от стартапов до enterprise-приложений с аудиторией 10 млн пользователей. Поэтому мы внедряем системы сбора метрик Response Time и Error Rate под ключ. По данным аналитиков, каждый час простоя с высокой задержкой стоит компании в среднем $10,000. Разберём, как это работает на практике, и какие подходы приносят реальный результат.

Проблемы без мониторинга HTTP-запросов

Без мониторинга вы узнаёте о проблемах с API только из отзывов или жалоб пользователей. Но жалобы приходят с задержкой, а каждый час простоя с высокой задержкой означает потерю части аудитории. Мониторинг решает три задачи: обнаружение деградации за 5 минут, диагностика причины (сеть vs сервер) и предотвращение регрессов после релизов.

Клиентский vs серверный мониторинг: что выбрать?

Два уровня сбора метрик дают полную картину.

Клиентский (in-app): время ответа от устройства пользователя — включает задержку сети. Отражает реальный опыт, но зашумлен: плохая сеть у одного пользователя не означает проблему сервера.

Серверный (APM): инструментируем сервер, измеряем только время обработки. Не видит сетевую задержку, но точно показывает состояние бэкенда.

Правильно — оба уровня. Клиентский для понимания UX, серверный для диагностики.

Выбор подхода зависит от цели. Если нужно видеть реальный UX — обязателен клиентский. Для диагностики бэкенда достаточно серверного. Оптимальная комбинация: клиентские метрики для алертов «пользователь страдает», серверные — для поиска причины.

Как инструментировать HTTP-клиент: код и примеры

Покажу на примере React Native. Код аналогичен для iOS (URLProtocol) и Android (OkHttpInterceptor).

Перехватчик для Axios в React Native

import axios, { AxiosInstance, AxiosRequestConfig, AxiosResponse } from 'axios'; type RequestMetric = { endpoint: string; method: string; statusCode: number; durationMs: number; timestamp: number; error?: string; }; const metricsBuffer: RequestMetric[] = []; const FLUSH_INTERVAL_MS = 30_000; const FLUSH_BATCH_SIZE = 50; function createMonitoredAxios(): AxiosInstance { const instance = axios.create({ baseURL: API_BASE_URL }); instance.interceptors.request.use((config: AxiosRequestConfig) => { (config as any).metadata = { startTime: Date.now() }; return config; }); instance.interceptors.response.use( (response: AxiosResponse) => { recordMetric(response.config, response.status, null); return response; }, (error) => { const status = error.response?.status ?? 0; recordMetric(error.config, status, error.message); return Promise.reject(error); } ); return instance; } function recordMetric(config: any, status: number, error: string | null) { const durationMs = Date.now() - (config?.metadata?.startTime ?? Date.now()); const url = config?.url ?? 'unknown'; const endpoint = new URL(url, API_BASE_URL).pathname; metricsBuffer.push({ endpoint, method: (config?.method ?? 'GET').toUpperCase(), statusCode: status, durationMs, timestamp: Date.now(), error: error ?? undefined, }); if (metricsBuffer.length >= FLUSH_BATCH_SIZE) flushMetrics(); } 

URL нормализуем в pathname — не хотим тысячи уникальных метрик /api/users/123, /api/users/456. Нужен паттерн /api/users/:id.

Агрегация на клиенте: P50/P95/P99

Среднее (mean) время ответа обманчиво: 90% запросов за 100 мс и 10% за 5000 мс дают среднее 590 мс — не отражает реальной картины. Перцентили точнее:

function calculatePercentiles(durations: number[]): { p50: number; p95: number; p99: number } { const sorted = [...durations].sort((a, b) => a - b); const p = (percentile: number) => sorted[Math.floor(sorted.length * percentile / 100)]; return { p50: p(50), p95: p(95), p99: p(99) }; } 

P99 — время ответа для 99% запросов. Если P99 растёт при стабильном P50 — проблема с медленными запросами у небольшой части пользователей (конкретный endpoint, конкретная ОС, конкретный регион).

Отправка метрик: батчинг и приоритизация

async function flushMetrics() { if (metricsBuffer.length === 0) return; const batch = metricsBuffer.splice(0, FLUSH_BATCH_SIZE); try { await fetch(`${METRICS_ENDPOINT}/ingest`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ metrics: batch, appVersion: APP_VERSION, platform: Platform.OS }), }); } catch { // При ошибке отправки — кладём обратно в буфер, но не более MAX_BUFFER_SIZE metricsBuffer.unshift(...batch.slice(0, MAX_BUFFER_SIZE - metricsBuffer.length)); } } 

Метрики отправляем через специальный non-critical fetch — ошибки при отправке не должны влиять на UX. Буфер ограничен — при длительном offline не накапливаем гигабайты.

Готовые решения: Firebase Performance Monitoring

@react-native-firebase/perf делает большую часть автоматически: перехватывает fetch/XHR, измеряет время, отправляет в Firebase. В консоли — дашборд с перцентилями по endpoint. Согласно документации Firebase Performance Monitoring, автоматический сбор метрик сети доступен на Android и iOS.

import perf from '@react-native-firebase/perf'; // Кастомный trace для критичной операции const trace = await perf().startTrace('checkout_flow'); trace.putAttribute('userId', userId); // ... операция ... await trace.stop(); 

Для большинства приложений Firebase Performance Monitoring — правильный выбор. Для enterprise с требованиями к self-hosted — Datadog RUM Mobile или кастомная отправка в InfluxDB/Prometheus.

Перцентили: почему это главная метрика?

Среднее время ответа может быть приемлемым, но 10% самых медленных запросов делают приложение некомфортным. P95 и P99 показывают, сколько на самом деле ждут пользователи с плохим соединением или на старых устройствах. Установка алертов по P95 позволяет реагировать на ухудшение для большинства, а P99 — на выбросы.

Как настроить алерты и не пропустить деградацию?

Определите baseline — среднее значение P95 за неделю. Установите порог: P95 > 2× baseline в течение 5 минут — предупреждение в Slack. Error Rate > 5% за 10 минут — критический алерт в PagerDuty. Важно разделять клиентские и серверные метрики: рост клиентского P95 при стабильном серверном указывает на проблемы сети.

Firebase Performance внедряется в 3 раза быстрее, чем кастомное решение на Datadog — за 3 дня вместо 2 недель. Но кастомное решение даёт полный контроль над хранением и кастомизацией дашбордов. Инвестиция в мониторинг окупается за счёт снижения потери пользователей и затрат на поддержку, экономя до 30% бюджета.

Что входит в работу

• Инструментирование HTTP-клиента (Axios/OkHttp/URLSession) под вашу платформу
• Настройка дашборда метрик (Grafana, Firebase Console или Datadog)
• Скрипты для батчинга и отправки метрик с обработкой ошибок
• Документация по алертам и порогам
• Обучение команды эксплуатации системы

Процесс работы и сроки

1. Аналитика: аудит текущего стека, определение критических эндпоинтов
2. Проектирование: выбор подхода (клиент/сервер), инструментов, схемы метрик
3. Реализация: интеграция перехватчиков, написание логики батчинга и агрегации
4. Тестирование: проверка в боевых сценариях, стресс-тест буфера
5. Деплой: выкатка в релиз, мониторинг первых дней, калибровка порогов

Сроки ориентировочно: Firebase Performance с кастомными трейсами и базовыми алертами — от 1 недели. Кастомная система метрик с батчингом, перцентилями и дашбордом Datadog/Grafana — от 2 до 4 недель. Стоимость рассчитывается индивидуально — зависит от платформы, количества эндпоинтов и сложности интеграции. Мы гарантируем качество интеграции и оперативное реагирование на инциденты.