Налаштування моніторингу сетевих помилок у мобільних застосунках
Продакшн-застосунок без моніторингу сетевих помилок—ви дізнаєтесь про проблеми з відгуків App Store. Типова ситуація: бекенд повернув 502 об 3:00 ночі, 8% користувачів отримали пустий екран, деякі видалили застосунок. У Sentry це стає подією з повним контекстом: пристрій, версія ОС, endpoint, статус відповіді, тіло помилки.
Що моніторити
Сетеві помилки поділяються на категорії з різною критичністю:
| Тип помилки | Приклад | Приоритет |
|---|---|---|
| Connectivity | Network request failed, timeout |
Високий—користувач не може працювати |
| 4xx клієнтські | 401, 403, 404, 422 | Середній—часто очікувані |
| 5xx серверні | 500, 502, 503, 504 | Високий—проблема бекенду |
| Parse error | JSON decode failure | Високий—breaking change API |
| SSL/TLS | Certificate pinning failure | Критичний—можливий напад |
Sentry для React Native: перехват мережевих запитів
@sentry/react-native автоматично перехоплює fetch та XMLHttpRequest через патч глобальних об'єктів. За замовчуванням включає Performance трейси для HTTP-запитів, але не логує помилки автоматично:
import * as Sentry from '@sentry/react-native';
Sentry.init({
dsn: 'https://[email protected]/yyy',
tracesSampleRate: 0.1, // 10% запитів трейсяться для Performance
integrations: [
new Sentry.ReactNativeTracing({
traceFetch: true,
traceXHR: true,
// Не включайте конфіденційні endpoints у трейси
tracingOrigins: ['api.yourapp.com', 'cdn.yourapp.com'],
}),
],
});
Для явного логування сетевих помилок—обгортка над fetch:
export async function monitoredFetch(
url: string,
options?: RequestInit
): Promise<Response> {
const startTime = Date.now();
try {
const response = await fetch(url, options);
const duration = Date.now() - startTime;
if (!response.ok) {
Sentry.captureMessage(`HTTP ${response.status}: ${url}`, {
level: response.status >= 500 ? 'error' : 'warning',
extra: {
status: response.status,
duration,
method: options?.method ?? 'GET',
endpoint: new URL(url).pathname,
},
fingerprint: [`http-${response.status}`, new URL(url).pathname],
});
}
return response;
} catch (error) {
Sentry.captureException(error, {
extra: { url, duration: Date.now() - startTime },
tags: { error_type: 'network_connectivity' },
});
throw error;
}
}
fingerprint критичний. Без нього Sentry створює окреме питання для кожної URL помилки. З fingerprint ['http-500', '/api/orders'] всі 500 помилки на /api/orders групуються в одне питання.
Breadcrumbs: контекст перед помилкою
Breadcrumbs показують, що відбувалося перед помилкою мережі: які екрани відкривав користувач, які дії виконував:
// Додайте breadcrumb при навігації
navigation.addListener('state', (e) => {
Sentry.addBreadcrumb({
category: 'navigation',
message: `Navigate to ${e.data.state.routes[e.data.state.index].name}`,
level: 'info',
});
});
За замовчуванням зберігає останні 100 breadcrumbs. Для довгих сесій—достатньо.
Виявлення втрати з'єднання
Offline-помилки повинні відрізнятися від серверних. Користувач у метро—не проблема бекенду:
import NetInfo from '@react-native-community/netinfo';
let isConnected = true;
NetInfo.addEventListener(state => { isConnected = state.isConnected ?? true; });
// У monitoredFetch, при catch:
if (!isConnected) {
// Не відправляйте у Sentry — очікуваний offline
throw new OfflineError('No network connection');
}
// Іншомк — реальна помилка, логуйте
Sentry.captureException(error, { tags: { connectivity: 'online' } });
Алертинг
Sentry Alerts по умові: count(event) > 50 per 5min для http-500 → Slack/PagerDuty. Error rate вище baseline → alert. Для продакшну повинен працювати 24/7.
Оцінка часу
Налаштування Sentry з моніторингом мережі, fingerprinting, offline-детектом та алертами: 1–2 тижні.