![Как реализовать логгирование
в проекте правильно?
• Log output не должен быть загрязнен
• Log-ов не должно быть излишне много, лог-файл/лог-лист должен быть читабельным
• Log-и должны иметь удобное и наглядное форматирование, соблюдаемое для всех строчек
(напр. : Err[xx.xx.xxxx] %@)
• Log-и разных типов желательно выделять различными цветами/шрифтами в Output-e
• Особо важные записи тоже следует особым способом помечать
• Log-и следует категорировать и типизировать (напр., один лог лист для событий
авторизации, другой - для сетевого взаимодействия)
• Log-и следует различать по степени важности : LogLevel mechanism
• Хорошая система логгирования должна иметь механизмы для : а) Фильтрации б) Поиска в)
Репортинга ( иметь возможности различными способами получить логи из действующего
приложения )](https://image.slidesharecdn.com/deepstormpresentation2-160623051830/85/Deep-storm-presentation-7-320.jpg)
![Занесение записей в журнал с помощью макросов :
static NSString *firstJournal = @"firstJrn";
static NSString *secondJournal = @"secondJrn";
DSJRN_LOG(firstJournal, @"Make new day!!!");
DSJRN_LOG(secondJournal, @"Incredible Allien %@", @"HI");
DSJRN_WARNING_LOG(firstJournal, @"Warning! Hungry rabbit attacks");
DSJRN_EXT_LOG(secondJournal, @{@"key" : @"value"}, @"record text»);
Создание репортера, отправляющего логи на Email
DSEmailReporter *emailReporter = [DSEmailReporter new];
[emailReporter addDestinationEmail:@"hikto583004@list.ru"];
[emailReporter setReportingCompletion:^(BOOL isSuccessSending,
NSError *sendingError){
NSLog(@«Email with Report was sent");
}];
Отправка репорта
DSREPORT_FULL(emailReporter);](https://image.slidesharecdn.com/deepstormpresentation2-160623051830/85/Deep-storm-presentation-24-320.jpg)
Deep storm presentation
- 1. Привет, коллеги Готовы к восприятию?
- 2. Тема презентации: Логгирование, как панацея при DEBUG-е
- 3. Оглавление : 1. Зачем нужно логгирование? 2. Существующие решения для логгирвания : (NSLog, CocoaLumberjack, XCGLogger, NSLogger, XLFacility) 3. DeepStorm : Киллер-фичи и концепты 4. DeepStorm : Способы и нюансы использования
- 5. Логгирование - полезный и важный инструмент разработчика ПО. При правильном подходе : а) Позволяет своевременно диагностировать логгируемую систему б) Иметь свежую реалтайм-информацию о том, что происходит в системе в) Логгирование незаменимо при отладке
- 6. Логгирование желательно внедрять на ранних стадиях проекта, и оно в дальнейшем способно ускорить разработку. В современных системах логгированию часто не уделяют должной роли, либо реализовывают неправильно. Это один из механизмов, которые трудно понять, как реализовать правильно
- 7. Как реализовать логгирование в проекте правильно? • Log output не должен быть загрязнен • Log-ов не должно быть излишне много, лог-файл/лог-лист должен быть читабельным • Log-и должны иметь удобное и наглядное форматирование, соблюдаемое для всех строчек (напр. : Err[xx.xx.xxxx] %@) • Log-и разных типов желательно выделять различными цветами/шрифтами в Output-e • Особо важные записи тоже следует особым способом помечать • Log-и следует категорировать и типизировать (напр., один лог лист для событий авторизации, другой - для сетевого взаимодействия) • Log-и следует различать по степени важности : LogLevel mechanism • Хорошая система логгирования должна иметь механизмы для : а) Фильтрации б) Поиска в) Репортинга ( иметь возможности различными способами получить логи из действующего приложения )
- 9. NSLog Предусмотренный Apple стандартный инструмент для Логгирования Преимущества : - Прост в использовании - Для совсем маленьких проектов достаточен и минималистичен Недостатки : - Автоматически на RELEASE не undef-ится - Довольно скоро в аутпут улетает столько событий, что становится нечитабелен - Имеет низкую производительность (как утверждает в своей презентации создатель CocoaLumberjack, каждый раз при новой записи - реконнектится к ASL Daemon-у) - Не имеет никаких дополнительных возможностей, кроме логгирования - Не имеет возможности категоризации и logLevel-а - Логи никак не получить, кроме консоли XCode
- 10. CocoaLumberjack Распространенный фреймворк для логгирования by Robbie Hanson Преимущества : - Легко присоединяется с помощью Pod/Carthage, FreeBSD-лицензия - Обладает x6 лучшей производительностью, чем NSLog. Реализует собственное взаимодействие с ASL-сервером (однако нам на дебаге нужна производительность?) - Позволяет выбирать Output (в файл/на удаленный сервер), и синхронизировать систему по таймеру - Позволяет гибко назначать форматтеры - Поддерживает цветной OutPut в XCode-консоли (требуется плагин Xcode Colors) - Имеет удобные макросы для разных LogLevel-ов Недостатки : - Нету отправки логов по Email-у - Нету возможности разбиения логов на типы (что, на мой взгляд - серьезный недостаток) - Не умеет заворачивать из-коробки логи в JSON/XML структуры - Не умеет потоков стримить логи в другие Output-ы (удаленный терминал / подъем веб-сервера с логами) - Интерфейс недостаточно нативен, требует времени на изучение возможностей
- 11. XCGLogger Простое и удобное решение для логгирования Преимущества : - Легко присоединяется с помощью Pod/Carthage или Submodule-м - Прост в использовании и нативен, удобно конфигурируется форматирование вывода - Имеет в наличии logLevel-ы - Позволяет выводить как в обычный output, так и в файл - Позволяет с помощью XcodeColors организовывать цветный вывод логов в Xcode Недостатки : - Написан для swift-а, под Obj-c могут быть различные трудности - Не имеет возможности отправки логов в другие источники (на e-mail, удаленная БД или стримить) - Нету возможности разбиения логов на типы - Не умеет заворачивать из-коробки логи в JSON/XML структуры - Малое количество функциональности
- 12. NSLogger Мощная кроссплатформенная система логгирования, с собственный Desktop Viewer-ом Преимущества : - Легко присоединяется с помощью Pod/Carthage - Система имеет собственный DesktopViewer (десктоп-программка, в которую стремятся логи. В ней их можно фильтровать/сортировать и передавать картинки) (это одно дает этой системе большой жирный плюс) - Удаленно стримит логи, который подхватывает Desktop-клиент - Высокая производительность - Делает простой replace NSLog-вызовов Недостатки : - Трудно настраивается. По Stackoverflow видно, что много пользователей не сразу смогли его подключить без проблем - Имеет много методов для логгирования в открытом интерфейсе, но трудных для разбора. Интерфейс низкоуровневый функциональный (система уже довольно старая) - Настроек форматирования я не обнаружил в Wiki - Кроме того, что стримить логи моментально - ничего не умеет (в файл умеет разве что) - Нету возможности разбиения логов на типы - Не умеет заворачивать из-коробки логи в JSON/XML структуры
- 13. XLFacility Необычное решение для логгирование, с большим количеством Output-ов Преимущества : - Система позволяет стримить данные большим количеством способов (файл, Local DB) - Умеет поднимать Telnet-сервер и Web-сервер (к ним можно коннектится - и получать данные в реалтайм-режиме) - В наличии разные лог-левелы - Позволяет удобным образом настраивать форматирование - Позволяет выводить цветные логи, как в удаленный терминал, так и на поднятом локальном веб-сервере - Имеет удобный интерфейс и макросы Недостатки : - Соединяется только через Cocoapods - Не идеально отлажен, и работа с терминалом/веб-сервером часто напарывается на разные Exception-ы - Мягко говоря, не лучшее решение по производительности - Не позволяет отправлять логи на Email - Нету возможности разбиения логов на типы - Не умеет заворачивать из-коробки логи в JSON/XML структуры
- 14. DeepStorm : Киллер-фичи и концепты
- 16. Типизация логов и использование специальных объектов DSJournal В классических системах принято использование специальных объектов Logger-ов (они нарушают Single Responsibility). Здесь система принципиально разбивается на множество журналов, а ответственность за отправку в Output-ы ложится на другие объекты. Можно сказать, что каждый журнал - это всего-лишь хранилище, куда скапливаются данные. DSJournal создает и содержит в себе объекты DSJournalRecord (запись в журнале), которая содержит различные параметры - дату, лог левел, дополнительную информацию, и прочее В журнал можно добавить запись различным способом, указать максимальное количество хранимых записей, получить текущее количество, и прочее Примеров использования журналов можно придумать множество : например, класс работающий с сетевым взаимодействием может иметь собственный журнал, или различные объекты-сервисы логгировать свою деятельность отдельно. Или набор журналов для логгирования конкретных действий на разных экранах.
- 17. DSBaseLoggedService - объект со встроенным журналом В системе порой нужны объекты-сервисы, выполняющие различный спектр связанных задач. Такие объекты могут пригодиться для сервисного слоя. Например, объект работающий со счетами пользователя, или объект, работающий с шаблонами/предпочтениями пользователя, или с юзер- токенов Имеется набор специальных макросов для логгирования в теле сервиса (self подхватывается автоматически). (DSSVC_LOG(…) и прочие) У сервиса есть специальные свойства workingMode / fixateEmergencyError: . В репортах эти свойства указываются. Например, можно трекнуть, что в сервисе произошла ошибка - и оно определенным образом будет видно в репорте. С помощью этого, в репортах потом можно быстро отслеживать, какой из сервисов вышел из строя. (Подобие Assert-ов, только без краша)
- 18. DSServiceManager - еще одна реализация сервис-локатора Идея была вынесена, когда я еще не был особо знаком с идеей инъекции зависимостей, но вовсю имел желание централизовать какие-либо действия. Суть в том, что DSBaseLoggedService адаптированы под этот сервис- менеджер. У него есть методы, с помощью которого можно опрашивать все сервисы системы, и собирать «репортаж». Кроме прочего, с помощью сервис-локатора можно устанавливать сервис по ключу, и получать сервис по ключу, в обход sharedXXX методов. В общем, это переходная стадия к инъекции зависимостей. Создание объекта, у которого другие объекты-клиенты могут запросить любой сервис. Кроме всего, предоставляет удобные методы для энумерации сервисов, и централизованные места для создания/конфигурирования
- 19. Reporter-ы и Streamer-ы Главная киллер-фича этой системы логгирования - большой набор объектов репортеров и стримеров. Собственно, задача Reporter-ов - создавать репорты, которые используются 1 раз, и передаются куда-либо Задачи Streamer-ов - стримить в реальном времени логи в любой возможный Output. Благодаря простым интерфейсам - можно создать кастомные Reporter/Streamer-ы почти на все случаи жизни. К сожалению, Streamer-ы существуют пока только в рамках проработанной концепции.
- 22. Многоуровневость системы За счет разбиения системы на простейшие объекты - удается достичь большой гибкости. Те же самые объекты DSJournal можно расширять каким-угодно образом, объектам DSJournalRecord задавать новые свойства, создавать кастомные репортеры/стримеры. Имеется специальный объект DSLogger, который является фасадом системы, и представляет простой интерфейс для использования системы. Те, кому мало и этого - для них существует набор удобных и нативных макросов
- 23. DeepStorm : Способы и нюансы использования
- 24. Занесение записей в журнал с помощью макросов : static NSString *firstJournal = @"firstJrn"; static NSString *secondJournal = @"secondJrn"; DSJRN_LOG(firstJournal, @"Make new day!!!"); DSJRN_LOG(secondJournal, @"Incredible Allien %@", @"HI"); DSJRN_WARNING_LOG(firstJournal, @"Warning! Hungry rabbit attacks"); DSJRN_EXT_LOG(secondJournal, @{@"key" : @"value"}, @"record text»); Создание репортера, отправляющего логи на Email DSEmailReporter *emailReporter = [DSEmailReporter new]; [emailReporter addDestinationEmail:@"hikto583004@list.ru"]; [emailReporter setReportingCompletion:^(BOOL isSuccessSending, NSError *sendingError){ NSLog(@«Email with Report was sent"); }]; Отправка репорта DSREPORT_FULL(emailReporter);
- 25. DeepStorm on GitHub : https://github.com/huktoDev/DeepStorm Cocoa pods : pod 'DeepStorm'