Налаштування алертів по метрикам стабільності мобільного додатку
Метрики стабільності без алертів — красиві графіки, які ніхто не дивиться. Алерти без правильних порогів — шум, який перестають читати через тиждень. Завдання — налаштувати систему, де кожен алерт означає реальну деградацію, яка вимагає дії.
Ключові метрики стабільності
Crash-Free Users Rate — відсоток користувачів, у яких за період не було ні одного крахе. Сторонні орієнтири: Google Play вважає > 1.09% крахів за сесію «поганим». Apple рекомендує > 99% Crash-Free Users. Важлива примітка: рахуйте за унікальними користувачами, а не за сесіями — інакше один користувач з 10 крахами завищує значення.
ANR Rate (Android) — кількість ANR-подій на 1000 користувачів на день. Поріг поганої поведінки в Google Play Vitals: > 0.47% ANR Rate.
Watchdog Termination Rate (iOS) — співвідношення сесій з Watchdog Termination до загальної кількості сесій. Немає офіційного орієнтира від Apple, але хороший ориєнтир — < 0.1%.
App Hang Rate (iOS) — відсоток сесій з заморожуванням UI > 250ms. Xcode Organizer показує цю метрику як Hang Rate.
Налаштування алертів у Firebase Crashlytics
// Firebase Alert Webhook (налаштовується у Firebase Console)
// При velocity alert — POST на ваш endpoint
// Приклад payload від Firebase:
{
"type": "crashlytics.velocityAlert",
"data": {
"issue": {
"id": "issue_id",
"title": "Fatal Exception: java.lang.NullPointerException",
"crashPercentage": 2.3,
"firstVersion": "2.1.0",
"latestVersion": "2.3.1"
}
}
}
Velocity Alert у Crashlytics спрацьовує, коли відсоток потрібних сесій різко зростає. Налаштування порога — у Firebase Console → Crashlytics → Alerts.
Алерти у Sentry з CRON-перевіркою
# Sentry API — створення Monitor через REST
import requests
response = requests.post(
"https://sentry.io/api/0/organizations/YOUR_ORG/monitors/",
headers={"Authorization": "Bearer YOUR_TOKEN"},
json={
"name": "Crash-Free Rate Drop",
"type": "cron_job",
"config": {
"schedule_type": "interval",
"schedule": [1, "hour"]
}
}
)
Але зручніше використовувати Sentry Alerts через інтерфейс: Issues → Alerts → New Alert Rule:
- Умова:
Number of users affected > 50за 1 годину - Дія: Notify Slack channel
#mobile-incidents
Алерти у Datadog на основі RUM-метрик
# Datadog Monitor query (Metric Alert)
rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600)
# Умова: > 100 крахів на годину → CRITICAL
# > 50 крахів на годину → WARNING
Для Crash-Free Rate:
# Обчислювана метрика у Datadog
(1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100
# Алерт: якщо < 99% → WARNING, < 98% → CRITICAL
Маршрутизація алертів
# PagerDuty + Alertmanager (для Prometheus-based мониторингу)
route:
group_by: ['service', 'platform']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: critical
service: mobile
receiver: pagerduty-mobile-oncall
- match:
severity: warning
service: mobile
receiver: slack-mobile-channel
receivers:
- name: pagerduty-mobile-oncall
pagerduty_configs:
- service_key: YOUR_PD_SERVICE_KEY
- name: slack-mobile-channel
slack_configs:
- api_url: YOUR_SLACK_WEBHOOK
channel: '#mobile-stability'
Що не працює: типові помилки конфігурації
Алерт на абсолютне число крахів без нормування. При зростанні аудиторії число крахів зростає, навіть якщо Crash-Free Rate стабільний. Алерт постійно спрацьовує, команда перестає реагувати.
Єдиний поріг для всіх версій. Нова версія щойно вышла — у неї мала аудиторія, але високий крэш-рейт може бути статистично незначимим. Додайте умову sessions > 1000 перед перевіркою порогів.
Немає алерта на поліпшення. Якщо Crash-Free Rate різко виріс з 97% до 99.9% — це також цікаво: може быть, запрацював hotfix. Bi-directional алерти допомагають зрозуміти ефект релізів.
Що ми робимо
- Визначаємо базовий рівень метрик стабільності для поточної версії
- Налаштовуємо velocity alerts у Crashlytics/Sentry під реальний трафік
- Налаштовуємо Datadog/New Relic Monitors з нормуванням за сесіями
- Маршрутизуємо CRITICAL → PagerDuty, WARNING → Slack
- Документуємо runbook для кожного типу алерта
Часові оцінки
Базове налаштування алертів: 4 години – 1 день. Повна система з маршрутизацією та runbook: 2 дні. Ціна розраховується індивідуально.