Sentry, Crashlytics и Datadog в одном Flutter-приложении: как не терять ошибки

Sentry ловит необработанные исключения Dart и Flutter, Firebase Crashlytics фиксирует нативные краши iOS и Android ещё до жалобы пользователя, а Datadog связывает оба потока с логами сервера и метриками бэкенда. По отдельности каждый инструмент видит свой кусок картины, вместе — дают путь ошибки от нажатия кнопки до сбоя в базе 1С.

Почему в Flutter-приложении ошибки теряются между тремя системами

В пятницу в 18:40, когда склад закрывает смену, у 12 из 40 курьеров приложение зависает на экране сканирования штрихкода. В Crashlytics — тишина: ни одного нового краша за день. Но проблема не в том, что её нет, а в том, что exception пойман внутри try-catch Dart-кода и никогда не долетает до нативного слоя, который слушает Crashlytics по умолчанию.

Firebase Crashlytics видит только то, что дошло до нативного крash-репортера iOS или Android — фатальные сбои платформы. Dart-исключения, пойманные внутри FutureBuilder, StreamBuilder или обычного try-catch, для него не существуют: приложение продолжает работать, экран просто перестаёт реагировать. Поэтому у команды разработки в логах Crashlytics — ноль инцидентов, а у диспетчера склада — десяток курьеров с зависшим сканером и сорванная приёмка товара.

Ставка здесь не абстрактная. Курьер, у которого завис сканер, вручную вбивает накладную или везёт груз обратно на склад. Расхождение между фактической приёмкой и остатками в 1С обнаруживается только на утренней сверке, когда бухгалтерия закрывает смену и находит разницу в 40-60 позиций. Пересчёт склада занимает от двух часов, а если расхождение попадает в отчётность — это уже не технический баг, а вопрос доверия клиента к системе учёта. В небольшой команде без выделенного DevOps-инженера — а это типичная ситуация для малого и среднего бизнеса в Москве — такую ошибку находят не мониторингом, а звонком от клиента, и это происходит на день-два позже, чем должно.

Как исправить разрыв между Sentry, Crashlytics и Datadog

Три системы закрывают разные слои одного приложения, и чинить разрыв нужно на уровне архитектуры, а не разовым патчем. На проекте среднего размера — 15-20 экранов, один бэкенд — вся связка встаёт за 3-5 рабочих дней, если сразу закладывать её в архитектуру, а не пристраивать к готовому коду.

Ловим Dart-исключения там, где Crashlytics не слышит

runZonedGuarded оборачивает весь main() и перехватывает необработанные ошибки в асинхронном коде, а FlutterError.onError — ошибки рендеринга виджетов. Оба обработчика передают событие в Sentry SDK для Flutter, который автоматически прикладывает breadcrumbs: последние экраны, сетевые запросы, тапы пользователя. В примере с курьерами именно breadcrumbs показывают, что зависание начиналось после конкретного ответа сервера с задержкой больше 8 секунд.

Прокидываем нативные крэши в Crashlytics и Sentry одновременно

Firebase Crashlytics остаётся источником правды по нативным крашам, ANR на Android и завершениям процесса на iOS — эти события Sentry без дополнительной настройки native-слоя видит хуже. Обе системы можно держать параллельно: Crashlytics для быстрой оценки crash-free rate в консоли Firebase, Sentry — для трассировки конкретного стека с привязкой к релизу и коммиту.

Связываем мобильный клиент с бэкендом через Datadog

Datadog принимает логи и метрики сервера, к которому обращается приложение, включая интеграцию с 1С. Если мобильное приложение передаёт trace ID в заголовке запроса, а бэкенд пишет этот же ID в лог при обращении к 1С, инцидент можно проследить целиком: тап курьера, запрос, обработка на сервере, запись в базу. Для проектов с интеграцией приложения с 1С это обычно закрывает единственный слепой участок — момент, когда ошибка происходит не в приложении и не в самой 1С, а в передаче данных между ними. Подробнее о том, как строится такая связка, — на странице интеграция приложения с 1С.

Sentry, Crashlytics и Datadog: кто что видит в Flutter-приложении

Прежде чем выбирать, от чего избавиться ради экономии, полезно свести зоны ответственности в одну таблицу — на практике инструменты не конкурируют, а закрывают разные вопросы. Отказ от одного из трёх инструментов ради экономии на подписке обычно означает не сокращение расходов, а перенос стоимости на более поздний этап — на разбор инцидента вручную по логам сервера и скриншотам от пользователя.

Что делать, если ошибка повторяется после фикса

Фикс закатали, релиз вышел, а через три дня та же ошибка снова в топе Sentry — только с другим номером события. Обычно дело не в том, что фикс не сработал, а в том, что группировка развела старую и новую ошибку по разным карточкам, и команда закрыла не тот инцидент.

Первое, что стоит проверить — символизацию. Без загруженных dSYM для iOS и ProGuard или R8 mapping-файла для Android стектрейс в Crashlytics и Sentry превращается в набор адресов памяти вместо имён функций: две разные на вид ошибки на самом деле одна и та же строка кода. Если mapping не грузится автоматически в CI, повторные крэши будут выглядеть как новые баги на каждом релизе.

Второе — release health. Sentry и Crashlytics считают crash-free sessions по версии сборки: если после фикса показатель не вырос, а просел ещё сильнее, проблема шире одного бага — вероятно, задета общая зависимость или сетевой слой. Здесь помогает Datadog: если серверные логи показывают всплеск 5xx именно в момент повторного краша, ошибка вообще не в мобильном коде, а в бэкенде, к которому обращается B2B-приложение. Для сценариев с интеграцией 1С такой всплеск часто совпадает с блокировкой объекта в базе при параллельной записи — это уже зона ответственности серверной части, а не Flutter-кода.

Третье — данные в самом отчёте об ошибке. Если в breadcrumbs или логах случайно попадают телефон, email или ФИО клиента, это уже вопрос обработки персональных данных по 152-ФЗ: такие поля нужно маскировать на уровне SDK до отправки события, а не после. Практика показывает, что повторные ошибки часто находят именно потому, что при первом фиксе никто не смотрел полное тело события — исправляли по заголовку, не читая контекст.

Как предотвратить рост числа ошибок в следующих релизах

Поэтапный rollout — 5% пользователей, потом 25%, потом 100% — с порогом по crash-free rate останавливает распространение бага до того, как его увидят все 300 сотрудников компании, а не 15. Порог обычно ставят на уровне 99,5% crash-free sessions: если новая версия падает ниже, раскатку останавливают автоматически через API Firebase или Sentry Releases.

Алерты нужно настраивать по скорости роста, а не по абсолютному числу событий. Один краш в сутки на 300 активных пользователей — норма, десять крашей за час на той же базе — инцидент. Правило по числу событий за минуты в Sentry и Datadog ловит вспышку раньше, чем её заметят по жалобам в поддержку.

Для B2B-приложений, где от стабильности зависит закрытие смены на складе или отгрузка со стороны 1С, отдельная проверка перед релизом — тест на слабом устройстве и медленной сети: часть крашей на проде объясняется не багом в коде, а нехваткой памяти на бюджетном Android-смартфоне склада. Такие сценарии закладываются в план разработки на этапе тестирования, а не добавляются постфактум. Мы включаем настройку мониторинга ошибок — Sentry, Crashlytics и, при необходимости, Datadog — в проект разработки мобильных приложений с самого начала, а не как отдельную доработку после первого инцидента в проде.

Сколько стоит подключить мониторинг ошибок к Flutter-приложению

Настройка связки Sentry, Crashlytics и Datadog — не отдельная услуга, а часть разработки B2B-приложения на Flutter: интеграция SDK, правила алертов, символизация сборок в CI и маскирование персональных данных закладываются в архитектуру с первого спринта. Разработка мобильного приложения с интеграцией 1С у нас начинается от 500 000 рублей — в эту сумму входит и слой мониторинга, а не только экран и бизнес-логика.

Если приложение уже в проде без наблюдаемости, дешевле не переписывать его целиком, а подключить мониторинг к существующей кодовой базе и настроить дашборды под конкретные бизнес-процессы: склад, курьеров, кассу. Такие точечные доработки и дальнейшее сопровождение считаются по часовой ставке 3800 рублей в час. Полный список тарифов на разработку и сопровождение — на странице цены и тарифы.

Для компаний, где мобильное приложение — часть учётной системы на 1С, а не отдельный продукт, мониторинг ошибок обычно встраивают в проект B2B-приложения с 1С сразу: там же, где решается вопрос обмена данными со складом, кассой или CRM, закрывается и вопрос — кто узнает об ошибке первым, разработчик или клиент через жалобу в поддержку.

❓ Частые вопросы

Sentry, Crashlytics и Datadog — разве это не одно и то же?

Нет. Crashlytics видит только нативные краши iOS и Android, Sentry дополнительно ловит Dart-исключения внутри try-catch и рендеринга виджетов, а Datadog связывает оба потока с логами и метриками сервера. Каждый инструмент закрывает свой слой, поэтому в связке видна вся цепочка ошибки, а не только её финальный симптом.

Сколько времени занимает подключение мониторинга к уже готовому Flutter-приложению?

На проекте среднего размера, 15-20 экранов и один бэкенд, интеграция SDK, настройка breadcrumbs и правил алертов занимает 3-5 рабочих дней при условии, что архитектура приложения позволяет встроить обработчики ошибок без переписывания основного кода. Если приложение собиралось без учёта мониторинга изначально, срок может увеличиться до полутора недель за счёт доработки CI под символизацию сборок.

Нужно ли получать согласие пользователя на сбор данных об ошибках по 152-ФЗ?

Если в отчёт об ошибке попадают телефон, email или ФИО, это персональные данные, и их обработку нужно приводить в соответствие с 152-ФЗ. Практичное решение — маскировать такие поля на уровне SDK до отправки события, тогда согласие на сам факт сбора технических логов не требуется.

Что делать, если бюджет позволяет подключить только один инструмент из трёх?

Начинайте с Sentry — он покрывает и Dart-исключения, и, частично, нативные краши через встроенный native-слой SDK. Crashlytics добавляют бесплатно, если приложение уже в Firebase. Datadog подключают позже, когда нужно связать мобильный клиент с логами сервера и 1С и увидеть путь ошибки целиком, а не только его часть на устройстве.

Мониторинг ошибок входит в стоимость разработки приложения или это доплата?

У нас настройка Sentry, Crashlytics и, при необходимости, Datadog входит в проект разработки мобильного приложения с интеграцией 1С от 500 000 рублей. Для уже работающего приложения без мониторинга подключение считается отдельно, по часовой ставке 3800 рублей в час.