Вместе с Android
реверс и программирование, обсуждение и обзоры
IntSystem.org | Веб-разработка, все о ней

Начали новый проект? Делайте подсистему логирования! 14.05.2017

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

Под катом вольные рассуждения о том, как диагностировать такие проблемы одним их самых старых и проверенных способов.

А всем ли проектам она нужна?

Если ответить на этот вопрос коротко: то скорее да, чем нет. А теперь подробнее. Самый минимум в ведении логов, который может быть, выглядит как на листинге ниже.

Если код короче, чем приведенный выше, то скорее всего логирование не нужно. Однако, даже в этом случае есть вызов doSomething, под которым может скрываться все что угодно. И вот этот вызов, если не получается каким-то образом контролировать, все же лучше хотя бы информировать постфактум о произошедших ошибках.

И как это сделать, так чтобы и удобно было и информативно?

Это уже вопрос, больше имеющий отношение к архитектуре проекта. Чем больше сам проект, тем обособленнее должно быть логирование.

Например, если разрабатывается какая-то библиотека, и код написан в процедурном стиле, то логичнее было бы завернуть все логирование в отдельный модуль.
В случае ООП разработки со сложной архитектурой и/или зависимостями между разными проектами, логирование можно вынести в отдельной проект (библиотеку, как правило), который подключать в виде зависимости.
Не ленитесь обращать внимание на то, как это сделано у других и использовать наиболее подходящие под ваш процесс практики.
Также следует учитывать, что одна подсистема логирования может оборачиваться в другую. Например, для перенаправления логов системы в приложение. Логирование в Android работает по этому принципу: несколько подсистем логирования, работающие на разных уровнях, но имеющие общую прослойку для чтения: logcat.


В случае Android все компоненты логирования находятся на одной машине, но это не всегда может быть так. Например, на портале с достаточно высокой нагрузкой логи могут быть вынесены на отдельный сервер (типичная кстати ситуация для микросервисной архитектуры).

Есть более конкретные предложения?

Для начала тезисно оформлю итоги, что же все таки хотелось сказать этим постом:

    1. Логирование нужно;
    2. С него нужно начинать;
    3. Это должен мыть независимый компонент системы, органично вписывающийся в архитектуру проекта (прибитое гвоздями логирование доставляет иногда больше проблем, чем пользы);
    4. Не забываем про уровни логирования (dev, test, prod и т.д.) и типы сообщений (info, error, exception, warning и т.д.);
    5. В идеале подсистема логирования должна быть построена таким образом, чтобы ее можно было перенести на другой проект.

А теперь что касается матчасти…
К счастью, все уже написано до меня, поэтому ниже привожу список статей, рекомендуемых к прочтению. Читайте и начинайте, наконец, делать свою подсистему логирования.

http://jasonwilder.com/blog/2013/07/16/centralized-logging-architecture/ (вариант «все в одном»)
https://blog.treasuredata.com/blog/2016/08/03/distributed-logging-architecture-in-the-container-era/ (каждый компонент работает независимо, но логи отправляются в одно место)
https://toster.ru/q/263621 (пример разбора полетов)
http://www.skipy.ru/useful/logging.html (много текста по log4j)q


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Яндекс.Метрика