За работу с NON_FATAL или пользовательскими ошибками отвечает FeatureConfiguration.assertReporter.
Для cocoapods Podfile:
source 'https://github.com/odnoklassniki/tracer-ios.git' pod 'OKTracer'
Следите за актуальностью версии SDK, самая свежая: 1.4.0.
Для создания и запуска Tracer используются TracerFactory – статическая фабрика для удобства создания типовых настроек, и TracerService – он объединяет все сервисы и возможности и обрабатывает их делегаты. Существует несколько способов добавления .assertReporter в Configuration при создании TracerService.
TracerFactory:Данный метод неявно добавляет .assertReporter в Configuration.
let tracerService = TracerFactory.tracerServiceForCrashReporting(EndpointConfiguration(token: "Ваш appToken"))
features:Можно передать явно .assertReporter в параметр features при создании TracerService:
let tracerService = TracerFactory.tracerService(token: "Ваш appToken", features: [.assertReporter()])
Configuration:Создайте собственный Configuration с необходимыми настройками и передайте его в качестве параметра в TracerService:
let configuration = Configuration(EndpointConfiguration(token: "Ваш appToken"), features: [.assertReporter()]) let tracerService = TracerFactory.tracerService(configuration: configuration)
За инициализацию .assertReporter отвечает TracerAssertReporterConfiguration – в ней есть несколько параметров, отвечающих за отправку событий определенных типов.
| Параметр | Тип | Описание |
|---|---|---|
maxUploadsCount | Int | Максимальное количество отчетов в вытесняющейся очереди. По умолчанию 10. |
sendEvery | Int | Отвечает за фильтрацию событий на случай, если за сессию фиксируется несколько эквивалентных друг другу событий. По умолчанию 0, что эквивалентно включению фичи – будет отправлен каждый NON_FATAL. |
Для отправки NON_FATAL-ов используется метод send(), принимающий в качестве параметра объект TracerNonFatalModel.
Существует несколько способов использования метода send():
let nonFatal = TracerNonFatalModel(message: "User error") tracerService.send(nonFatal: nonFatal)
Вариант #2 полезен в том случае, если какое-либо из полей fileName, function или line модели может оказаться nil. При таком сценарии nil-параметр перезапишется соответствующим параметром метода.
ВАЖНО! На текущий момент в Tracer есть лимит в 1 млн событий в день. Поэтому рекомендуется не злоупотреблять этим методом.
| Параметр | Тип | Описание |
|---|---|---|
message | String | Сообщение, которое будет передано вместе с событием. |
tags | [String: String] = [:] | Дополнительная информация в формате «Ключ – Значение». Отображается во вкладке Ключи внутри события. |
properties | [String: String] = [:] | Дополнительная информация в формате «Ключ – Значение». Отображается во вкладке Данные внутри события. |
fileName | String? | Имя файла, при выполнении которого зафиксирована ошибка. |
function | String? | Имя функции, при выполнении которой зафиксирована ошибка. |
line | Int? | Номер строки, при выполнении которой зафиксирована ошибка. |
issueKey | String? | Специальный ключ, влияющий на группировку событий в общем списке (подробнее см. ниже). |
traceType | InternalTraceType | Источник информации о выполняемом потоке, в котором зафиксирована ошибка. По умолчанию current. |
severity | ReportSeverity | Уровень логирования (серьезности) ошибки, используется для классификации ошибок. Доступные значения: fatal,error,warning,info,notice,debug |
ВАЖНО! На данный момент количество пользова тельских ключей ограничено – не более 30.
| Тип | Описание |
|---|---|
current | Использует текущее имя потока и текущий стектрейс, обрезая несколько фреймов с начала. |
custom | Используется, когда у Вас уже есть стектрейс и его нужно обернуть в событие. К стектрейсу также можно добавить символы (есть нюансы, подробнее в статье Символизация). dropFirstSymbols работает аналогично current, только теперь применяется и к символам, и к стектрейсу. Помимо этого есть возможность задать своё имя потока. Если этого не сделать, будет использоваться текущее, как в current. |
По умолчанию все сбои группируются по общим частям стектрейса, но в случае NON_FATAL может возникнуть необходимость выделить ошибку среди других аналогичных. Дело в том, что не всегда стектрейс и место, в котором залогировали ошибку, связаны между собой. Существует способ повлиять на эту группировку и собрать все NON_FATAL одного вида ошибки в одну группу при помощи специального ключа issueKey. Этот параметр также будет отображаться в названии события.
Преимущество issueKey в том, что не только вы сможете легко найти NON_FATAL, относящиеся к конкретной проблеме, но и другие разработчики смогут легко найти по ключу точку логирования этой ошибки (и удалить при необходимости) и отследить его в вашем issue-трекере.
Для того чтобы все NON_FATAL-ы попали в одну группу вне зависимости от стектрейса, можно передать специальный ключ issueKey отдельным параметром или в числе properties. После этого появится возможность фильтровать события по данному ключу в общем списке событий.
issueKey как самостоятельный параметр:
let nonFatal = TracerNonFatalModel(message: "User error", issueKey: "IOS-100100") tracerService.send(nonFatal: nonFatal)
После создания модели на этапе отправки происходит дополнительный процессинг properties на стороне SDK. В связи с этим следует избегать использования некоторых названий ключей, так как вследствие обработки они могут быть перезаписаны:
message - сюда SDK всегда записывает message события.file - сюда SDK может записывать комбинацию из fileName, function и line. Необходимым условием является наличие хотя бы одного из перечисленных параметров.issueKey.