Моніторинг 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 тижнів. Вартість розраховується індивідуально — залежить від платформи, кількості ендпоінтів та складності інтеграції. Ми гарантуємо якість інтеграції та оперативне реагування на інциденти.