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 структуры
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-ы существуют пока только в рамках
проработанной концепции.
20.
21.
22. Многоуровневость системы
За счет разбиения системы на простейшие объекты -
удается достичь большой гибкости. Те же самые объекты
DSJournal можно расширять каким-угодно образом,
объектам DSJournalRecord задавать новые свойства,
создавать кастомные репортеры/стримеры.
Имеется специальный объект DSLogger, который
является фасадом системы, и представляет простой
интерфейс для использования системы.
Те, кому мало и этого - для них существует набор
удобных и нативных макросов