Налаштування Release Health (Sentry) для мобільного застосунку
Ми — команда з 5+ років досвіду в моніторингу мобільних застосунків. Налаштували Sentry Release Health для понад 20 проєктів. Інтегруємо та налаштовуємо його для вашого застосунку — це дає об'єктивну картину здоров'я кожного релізу ще до того, як користувачі залишать відгуки. Без цієї системи деградація часто залишається непоміченою до скарг. З Release Health ви отримуєте автоматичне порівняння версій за crash-free rate, adoption та кількістю сесій. Якщо метрики падають — Sentry позначає реліз як Unhealthy і тригерить алерти. Наш досвід показує: таке налаштування окупається за перший же інцидент. Наприклад, для застосунку з 500 000 MAU ми знизили час реакції на регресію з 2 годин до 15 хвилин. Автоматичний моніторинг виявляє проблеми в 3 рази швидше, ніж аналіз відгуків користувачів. Показник crash-free rate у здорових релізах тримається на рівні 99,5%.
Обчислення Crash Free Rate
В основі Release Health лежать сесії. Сесія починається при запуску застосунку і закінчується при переході в background більш ніж на 30 секунд або явному завершенні. Кожна сесія маркується або як crashed, або як ok. Crash Free Rate = (сесії без крешів / загальна кількість сесій) × 100%. Sentry автоматично агрегує ці дані по кожному релізу.Документація Sentry
// iOS — сесії Sentry керуються автоматично при enableAutoSessionTracking = true
SentrySDK.start { options in
options.dsn = "https://[email protected]/project"
options.releaseName = "MyApp@\(Bundle.main.releaseVersionNumber)+\(Bundle.main.buildNumber)"
options.environment = "production"
options.enableAutoSessionTracking = true
options.sessionTrackingIntervalMillis = 30_000 // 30 сек в background = нова сесія
}
// Android
SentryAndroid.init(this) { options ->
options.dsn = "https://[email protected]/project"
options.release = "myapp@${BuildConfig.VERSION_NAME}+${BuildConfig.VERSION_CODE}"
options.environment = "production"
options.enableAutoSessionTracking = true
options.sessionTrackingIntervalMillis = 30_000L
}
Параметр releaseName має відповідати тому, що передається при завантаженні dSYM (iOS) або ProGuard mapping (Android) у Sentry. Інакше Release Health і символізовані трейси показуватимуться в різних версіях в UI — часта помилка, яку ми виправляємо.
Важливість завантаження dSYM та ProGuard mapping
Без символів ви не побачите читабельні стектрейси в Issues. А без коректного releaseName Release Health не зв'яжеться з цими issues. Ми автоматизуємо завантаження через Sentry CLI в CI/CD.
# Fastlane — Fastfile
lane :upload_dsyms_to_sentry do
sentry_upload_dsym(
auth_token: ENV["SENTRY_AUTH_TOKEN"],
org_slug: "your-org",
project_slug: "ios-app",
dsym_path: "./build/MyApp.app.dSYM"
)
end
Або через sentry-cli в CI/CD:
sentry-cli releases new "[email protected]+456"
sentry-cli releases set-commits "[email protected]+456" --auto
sentry-cli upload-dsyms ./build/MyApp.app.dSYM
sentry-cli releases finalize "[email protected]+456"
set-commits --auto зв'язує git-коміти з релізом. Це дозволяє в Issue-трекері Sentry одразу бачити, який коміт призвів до проблеми. Ми гарантуємо, що цей ланцюжок налаштований без розривів.
Як інтерпретувати дані Release Health?
У розділі Releases відображається ключова метрика — Crash Free Rate. Sentry автоматично розраховує Adoption (частка користувачів на цій версії) та кількість сесій. Статус Unhealthy присвоюється, якщо Crash Free Rate впав більш ніж на 5% відносно попереднього релізу. Ми налаштовуємо цей поріг під ваш проєкт.
| Метрика | Опис | Приклад значення |
|---|---|---|
| Crash Free Rate | % сесій без крешів | 99,5% |
| Adoption | % користувачів на цій версії | 85% |
| Sessions | Загальна кількість сесій | 120 000 |
| Issues | Нові помилки, що з'явилися в цій версії | 3 |
Як налаштувати алерти на деградацію?
Використовуйте Sentry API для створення правил алертів, які спрацьовують при реєстрації регресії. Приклад на Python:
# Sentry API — створити Alert Rule
import requests
rule = {
"name": "Release Health Degradation",
"environment": "production",
"actionMatch": "all",
"conditions": [
{
"id": "sentry.rules.conditions.regression_event.RegressionEventCondition"
}
],
"filters": [
{"id": "sentry.rules.filters.latest_release.LatestReleaseFilter"}
],
"actions": [
{
"id": "sentry.integrations.slack.notify_action.SlackNotifyServiceAction",
"workspace": "SLACK_WORKSPACE_ID",
"channel": "#mobile-releases"
}
],
"frequency": 60
}
requests.post(
f"https://sentry.io/api/0/projects/YOUR_ORG/ios-app/rules/",
headers={"Authorization": "Bearer YOUR_TOKEN"},
json=rule
)
Ми також створюємо post-deploy скрипт, який порівнює Crash Free Rate нового релізу з попереднім через API — це дозволяє заблокувати pipeline, якщо деградація перевищує допустимий поріг.
Порівняння конфігурацій iOS та Android
| Параметр | iOS | Android |
|---|---|---|
| Бібліотека | Sentry Cocoa | Sentry Android |
| Версія SDK | 8.x | 6.x |
| Автоматичні сесії | enableAutoSessionTracking | enableAutoSessionTracking |
| Формат releaseName | [email protected]+1 | [email protected]+1 |
| Завантаження символів | dSYM | ProGuard mapping |
Що входить у нашу роботу
- Крок 1. Інтеграція
enableAutoSessionTrackingз правильним форматомreleaseNameдля iOS та Android - Крок 2. Підключення Sentry CLI в CI/CD для автоматичного завантаження dSYM та ProGuard mapping
- Крок 3. Налаштування git commit tracking через
set-commits - Крок 4. Створення алертів на Regression Event з нотифікацією в Slack або Telegram
- Крок 5. Реалізація post-deploy check Crash Free Rate для gate в pipeline
- Крок 6. Документація по процесу та рекомендації по порогах метрик
Докладніше про автоматичні сесії
Автоматичні сесії в Sentry починаються при запуску застосунку і завершуються після 30 секунд у фоні. Це дозволяє точно вимірювати кількість сеансів та крешів без додаткового коду.
Кейс із практики
На одному з проєктів — застосунку для доставки їжі з аудиторією 500 000 MAU — після оновлення версії crash-free rate впав на 8% за годину. Без Release Health це стало б відомо лише через кілька днів із відгуків. Sentry автоматично позначив реліз як Unhealthy і відправив алерт у Slack. Ми за 30 хвилин відкотили реліз і виправили регресію. З моменту налаштування системи кількість інцидентів, що доходять до користувачів, скоротилася в 3 рази. Використання моніторингу здоров'я релізів у 2 рази точніше визначає проблемні версії, ніж покладання лише на відгуки. Після впровадження щомісячна економія на підтримці становить $2000.
Терміни та вартість
Базове налаштування Release Health займає 4–8 годин. Інтеграція в CI/CD з автозавантаженням символів — 1–2 дні. Вартість починається від $500 для середнього проєкту (20-50 тис. користувачів). Отримайте безкоштовну оцінку вашого проєкту — зв'яжіться з нами. Оцінимо ваш проєкт за 30 хвилин і запропонуємо план інтеграції.