Как правильно логировать

4 совета, которые сделают логирование лучше, а жизнь проще

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

Название лог-файла

Начинается логирование с названия лог-файла. Например, если мы имеем в миграторе два одноимённых класса импорта и экспорта для, допустим, пользователей, то не стоит и там, и там вести запись в файл с названием «users_log.txt». Умение пользоваться поиском по тексту это, конечно, хорошо, но, согласитесь, намного удобнее, когда импорт пользователей лежит в «import_users_log.txt», а экспорт, соответственно, в «export_users_log.txt».

Иногда встречаются поделки, в которых все экспортируемые сущности: пользователи, задачи, проекты и т.д. просто логируются в файл с названием «export_log.txt». Разбираться в таких логах это отдельная головоломка, которую можно было бы не решать, если бы с самого начала все делалось грамотно.

Имена, пароли, явки — лучше четко и понятно

Сообщение, которое мы пишем в лог, должно быть максимально информативным с первой строки. В библиотеках bx24 и bx24m в конце каждого лога присутствует бэктрейс, по которому можно отследить, с какой строки и из какого файла был вызван процесс записи, но, согласитесь, намного удобнее, когда тебе не нужно пролистывать целую простынку текста, чтобы узнать, откуда она родом, и можно просто сразу прочитать, что

className methodName() $blahBlahBlahArray: array(blah-blah-blah на тысячу строк)

В принципе, имя класса можно пропустить, если оно достаточно очевидно из названия самого лог-файла. Но вот указывать метод и имя переменной нужно. Причём, обратите внимание, что вот так делать — плохо:

Bx24\Util::log('methodName() res: ' . print_r($answer, true), 'logname');

а вот так — хорошо:

Bx24\Util::log('methodName() $answer: ' . print_r($answer, true), 'logname');

Во втором случае разработчику, который пойдёт в код после прочтения вашего лога, не нужно будет производить лишнюю работу по сопоставлению некоего res и безымянного array(. ), возвращённого функцией print_r(), он будет сразу искать переменную с именем $answer и в этом мире, возможно, станет чуть больше добра и гармонии.

Не нужно лишней информации

Логируйте только то, что вам действительно нужно. Не стоит распечатывать весь массив, если вам нужно проверить наличие одного единственного ключа.

Оформление тоже важно

Если вам нужно залогировать несколько небольших переменных, которые связаны какой-то общей логикой, не стесняйтесь использовать простой советский:

Это не сильно отличается от того случая, когда мы используем несколько вызовов Bx24\Util::log() внутри одного блока if ($DEBUG), но если нужно залогировать несколько коротеньких строковых переменных, такая форма записи намного лучше читается — не нужно каждый раз проматывать бектрейсы в конце каждой лог-записи, да и в коде оно выглядит аккуратнее.

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

Доставка полезной информации от экспертов по Битрикс24!

Подпишитесь, и раз в неделю у вас на почте будет подборка полезных советов и обзоров про Битрикс24

Как правильно писать логи (?)

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

Есть такая linux утилита, а также по совместительству сетевой протокол под названием syslog. И есть целый набор RFC посвящённый syslog, один из них описывает уровни логирования https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Согласно rfc 5424 для syslog определено 8 уровней логирования, для которых также дается краткое описание. Данные уровни логирования были переняты многими популярными логерами для разных языков программирования. Например, http://www.php-fig.org/psr/psr-3/ определяет те же самые 8 уровней логирования, а стандартный Ruby logger использует немного сокращённый набор из 5 уровней. Несмотря на формальное указание в каких случаях должен быть использован тот или иной уровень логов, зачастую используется комбинация вроде debug/info/fatal — первый для логирования во время разработки и тестирования, второй и третий в расчёте на продакшен. Потом в какой то момент на продакшене начинает происходить что то не понятное и вдруг оказывается, что info логов не хватает — бежим включать debug. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:

• что-то происходит и надо знать что
• что-то сломалось и нужно дополнительно активировать триггер

В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:

• Fatal — вывод в лог и немедленный выход в ОС.
• Panic — вывод в лог и возбуждение «паники» (аналог исключения)
• Print — просто выводит сообщение в лог

Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.

Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) — то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug < entity.values >. В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.

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

Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:

[system info] + [message] + [context]

• system info : метка времени, ид процесса, ид потока и другая служебная информация
• message : текст сообщения
• context : любая дополнительная информация, контекст может быть общим для сообщений в рамках какой то операции.

Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:

reqLog := log.WithField("requestID", requestID)

После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.

• Логируйте с избытком. Никогда заранее не известно сколько и какой информации в логах понадобится в критический момент.
• Восемь уровней логирования — вам действительно столько надо? По опыту должно хватить максимум 3-4, и то при условии, что для них настроены обработчики событий.
• По возможности используйте ленивые вычисления для вывод сообщений в лог
• Всегда добавляйте текущий контекст в каждое сообщение лога, как минимум requestID.
• По возможности настраивайте сторонние библиотеки таким образом, чтобы они использовали логер с текущим контекстом запроса.

Логирование: что это и в чем его польза

Система логирования – один из важных моментов в процессе разработки программных продуктов, контроля над работой сервисов, веб-сайтов. Но часто ее недооценивают, не используют своевременно. А необходимость в ней понимают только тогда, когда проект уже находится на этапе сдачи и что-то в нем идет не так и остается только разводить руками. Чтобы этого не произошло, надо знать, что это, запись логов, зачем она нужна, когда и как ее применять на практике. К ней стоит обращаться IT-специалистам, чтобы разобраться, почему не работает или работает некорректно приложение или сайтов. Администраторы, основываясь на логах, смогут причины в сбое сервисов. Используя логирование, система безопасности сможет быстро установить вид взлома, оценить нанесенный ущерб, а в ряде случаев еще и выявить злоумышленника. Но, обо всем по порядку.

Проблемы, с которыми сталкиваются реальные приложения

Чтобы понять, для чего нужны лог файлы, следует знать, с какими проблемами могут столкнуться реальные программные продукты. Так, рассмотрим самый простой сайт. Он включает:

• систему передачи названия веб-сайта в ip-адрес сервера – DNS;
• интернет-сервер: программу, обрабатывающую входящие запросы, перенаправляющую их в код софта и получающую из него данные, необходимые пользователю;
• физический или виртуальный сервер и его инфраструктуру: аппаратное обеспечение, операционная система, обслуживающие программы;
• базу данных: внешнее хранилище, с которым будет работать код приложения, чтобы отправить или получить нужную информацию;
• программу: включает код самого приложения, а также миллионы строк библиотек, работает в рамках фреймворка со своими правилами обработки поступающих запросов;
• фронт-энд часть: код, выполняемый на пользовательском браузере, системы сборки и пр.

Это самая простая из возможных структур. Но большая часть современных сайтов имеет куда более сложное строение. Огромное количество дополнительных серверов, систем кеширования для ускорения доступа, внешние, в том числе облачные сервисы, очереди, асинхронные коды и многое другое. В результате написанный программистом код обрастает многослойной, разветвленной структурой. И что делать, если произошел сбой? Основная задача – найти, где это случилось и почему. Но в решении она очень сложная. И самое неприятное то, что проблемы могут быть выявлены не на этапе создания продукта, а уже тогда, когда он запушен в работу.

Аренда выделенного
сервера
Разместим оборудование
в собственном дата-центре
уровня TIER III.
Конфигуратор сервера
Подбор оборудования для решения Ваших задач и экономии бюджета IT

Зачем нужно логирование

И единственный способ эффективно решить ее – проанализировать лог. Осталось только понять, что значит логирование? Речь идет о записи специального текстового файла (лога) с полной информацией о работе программы, действиях пользователей. В результате получается некий журнал, каждая строчка в котором соответствует определенному действию. И если возникает любая непредвиденная ситуация, специалисту надо анализировать логи. Так он сможет узнать, что происходило и когда. Анализируя данные, программист выявит не только проблему, но и те факторы, которые спровоцировали ее появление, сможет понять, возникает ли она постоянно или только при определенных обстоятельствах.

Логи стоит записывать в процессе работы каждого компонента IT-инфраструктуры. Выгоду от его использования получит каждый специалист:

• администратор сможет понять почему произошел сбой устройства, ОС или «лег» сайт;
• Seo-специалисты получат наглядную картину о посещаемости, смогут оценить целевой трафик;
• разработчики, выполняя регулярно просмотр лога, выявят и устранят ошибки в продукте еще в процессе программирования, смогут при помощи простых интерфейсов отслеживать работу продукта в режиме реального времени;
• администраторы интернет-магазинов смогут держать под контролем процесс взаимодействия с заказами, платежными системами, видеть изменения, происходящие в них;
• представители системы безопасности компании смогут выявить факт посягательства на конфиденциальность информации и связанных с этим лиц.

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

Знакомимся с типами логов

Чтобы процесс работы с логами был более простым и удобным, их разделяют на несколько типов:

• системные – связаны с событиями, происходящими в операционной системе;
• серверные – формируют список обращений к серверу;
• баз данных – фиксируют обращения к базам данных;
• почтовые – работают с входящими или исходящими письмами, находят ошибки, ввиду которых они не были отправлены или получены;
• авторизации и аутентификации – отвечают за все моменты, связанные с входом и выходом из системы, восстановлением доступа;
• приложений – отвечают за установленные софты.

Для каждого из них надо создавать отдельный журнал записи в особом формате. Так будет более удобно анализировать состояние продукта, находить источники проблем и инструменты для работы с ними.

Дополнительно предусмотрена классификация логов по степени их важности. Так, к группе Fatal/critical error будут относиться те, которые требуют как можно более быстрого выполнения. Ошибки, которые не будут влиять на работу пользователей стоит записывать в группу Not critical error. В файле Warning будут храниться предупреждающие строки, то есть то, на что стоит обратить внимание. Для записи информации о запросах баз данных, вызовах API или других серверов предусмотрена категория Initial information.

Знакомимся с уровнями логирования

Заниматься логированием необходимо во время разработки и последующей эксплуатации всех IT-систем. Но если так делать, подучим огромное количество файлов и разобраться в них будет крайне сложно. Даже в том случае, если классифицировать их по типам и степени важности. Чтобы не разводить хаос, систематизировать важную информацию, упростить ее последующее использование, предусмотрены уровни логирования. Всего выделяют 4 основных:

• Debug. Здесь будут записывать масштабными переходы состояний. Речь идет об обращении к базам данных, запуск и остановка сервиса, подтверждение успешной обработки информации.
• Warning. В этой папке будет находиться все то, что относится к внештатной ситуации, проблемах, требующих внимания. Корявые запросы, некорректные вызовы – все эти логи можно будет найти здесь.
• Error. Этот уровень предполагает сбор типичных ошибок.
• Fatal. Искать проблему серьезных сбоев в работе необходимо в этой папке. Логи, хранящиеся в ней, помогут найти проблему отказа в доступе к базе данных, отсутствии свободного места на жестком диске и пр.
• Trace. Предполагает пошаговую запись происходящих процессов. Сюда стоит заглянуть в том случае, если возникнут сложности с локализацией проблемы.
• Info. Общеознакомительный файл, содержащий информацию о работе сервиса, службы.

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

Основы грамотного логирования

Чтобы получить файлы логирования, которые будут удобными в последующей работе, следует грамотно подойти к процессу их создания:

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

Задать вопросы специалистам компании «Xelent, получить профессиональную помощь в логировании, узнать условия сотрудничества можно по телефону или через форму обратной связи.

Популярные услуги
Аренда FTP сервера

Разработчики приложений часто сталкиваются с ситуаций, когда нужно создать backup файлов, но места для его хранения нет. Аренда FTP сервера в Xelent поможет решить эту проблему.

Аренда терминального сервера

Аренда терминального сервера – отличная альтернатива покупке дорогостоящего компьютерного оборудования. Клиент приобретает готовую систему на базе Windows, предназначенную для корпоративных пользователей. Работники компании получат облачный доступ к стандартным приложениям ОС и специализированным программам (1С: Бухгалтерия, PayDox и т.д.).

Отказоустойчивое облако Xelent

Каждый элемент в отказоустойчивом облаке подключен к двум независимым линиям питания. Система АВР позволяет корректно переключать нагрузку между основным и резервным питанием.

Логирование: понятие, механизмы и уровни

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

Что такое логи?

Лог (log) — это хронологическая запись наиболее значимой информации о работе системы. Подобная фиксация событий дает представление и том, что происходило в системе, в какой именно момент, какой пользователь спровоцировал то или иное событие, какие ошибки возникли и т.д.

Запись оформляется в особый файл, который еще называют лог-файлом или журналом логов. Для специалиста такой файл — это книга или справочник, рассказывающий о том, что происходило в системе в конкретный период времени. Грамотные администраторы, обращаясь к подобным записям, могут не только выявить проблему в работе системы на ранней стадии, но и вовремя предотвратить сбой в ее работе. Несанкционированные действия или установление вредоносных программ также фиксируются журналами логов. И по ним можно достаточно эффективно выявить внешнее вмешательство в работу сайта. Таким образом логи используются для контроля, мониторинга, анализа, защиты и оптимизации работы приложений и серверов.

Типы логов

В зависимости от того, информация какого типа фиксируется системой, формируются разные типы записей. Поэтому логи делятся на: системные, серверные, почтовые, логи аутентификации, авторизации, log file приложений, баз данных и т.д. Подобная группировка помогает быстрее находить нужный лог и оптимизировать работу с ним.

Еще существует разделение логов в порядке их значимости для ситуационной ошибки:

• Срочное исправление — Fatal error
• Ошибки, не влияющие на пользователя — Not critical error
• События, требующие внимания — Warning
• Информация о вызовах сервера — Initial information

Что такое логирование?

Логирование — это процесс формирования логов, а именно: фиксация и структурирование информации о работе системы в отдельные лог-файлы с возможностью быстрого доступа к ним в случае необходимости. Файлы содержат отчет обо всем, что происходило с системой: какие действия совершали конкретные пользователи, когда это происходило, как система реагировала на события и т.д.

Фиксацию всех важных для системы событий производит специальное программное обеспечение. В процессе логирования учитываются настройки уровня детализации записей, поскольку ни одна система не проводит записи абсолютно всех событий.

Кроме формирования журнала записей, важной компонентой настройки логирования является правильная организация хранения логов. Она должна обеспечивать своевременный и быстрый доступ к ним.

Лог-файлы могут храниться на компьютере, на удалённом жёстком диске, на отдельном сервере, в облачных хранилищах, т.е. на любом удобном носителе с ограниченным доступом для посторонних.

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

Механизмы записи информации

Как было сказано выше, в журналах логов не фиксируется абсолютно вся информация. Система производит запись наиболее важных для анализа данных. Например, при обращении пользователя к конкретной странице сайта, в лог записываются: URL, к которому обращается посетитель, его IP-адрес, используемый браузер, операционная система, дата и точное время обращения, код ответа сервера и прочее.

Для формирования журналов логирования программисты используют разные механизмы фиксации информации:

1. Самый понятный и распространенный механизм — запись логов в текстовый файл. Это запись каждого события отдельной строкой.Подобные журналы легко читать, открыв файл в любом текстовом редакторе.
2. Более углубленный лог — когда одно событие записывается несколькими строками, например, журнал ошибок. Такие записи имеют сложную многоступенчатую структуру, в которой человеку легко пропустить важную информацию. Поэтому для чтения этого вида log files используются специальные программы.
3. Бинарный — самый сложный механизм записи файлов. Обычно такие логи обрабатываются тем же программным обеспечением, что и ПО, их записывающее.
4. Приложения, использующие БД или сами СУБД. Основным недостатком такой фиксации является вероятность замедления работы базы данных из-за интенсивной записи логов. Поэтому при использовании такого механизма ведения записи крайне важно четко определить, что именно система должна фиксировать.

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

Уровни логирования

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

На уровне debug едет запись значимых переходных состояний, например, запуск или остановка сервера, запрос в БД, верификация, обработка информации. Уровень info расскажет программисту об общих событиях работы сервиса. Экстренные ситуации, проблемы, некорректные запросы будут записаны в warning. Основные ошибки на уровне error.

Чтобы соблюдались уровни логирования, программисту нужно прописать условия или внутри самой программы, или выставить условия в зависимости от ситуации при запуске программы, которая производит логирование.

Ротация файлов

Представим, что логирование данных системы налажено. Например, мы прописали в приложении уровни: debug, info, warning, error. Выбрали в качестве механизма записи обычные текстовые файлы и у нас благополучно все логи собираются в отдельном месте. Теперь нам стоит разобраться с ротацией логов.

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

Во время ротации происходит несколько технических процедур: сохранение и архивирование нового лога, переименование ранее сформированных файлов и удаление самых старых. Конечно, такое представление последовательности действий значительно упрощено. В реальности же ротация логов – это сложный многоступенчатый порядок действий системы, который запускается специальными утилитами.

На рынке существует системы логирования с высокими рейтингами, которые не только реализуют функцию формирования журналов с хронологической записью истории событий, но и с настройкой их последующей ротации.

Как читать логи?

Для чтения простых логов можно использовать обыкновенный текстовый редактор. А вот для расшифровки более сложных и объемных записей стоит воспользоваться специальным программным обеспечением. Ассортимент готовых решений для анализа файлов логирования достаточно широк. Выбирать ПО стоит, исходя из задач и объемов вашего ресурса. Расшифровка логов имеет свои особенности, поэтому во время анализа необходимо следовать рекомендациям разработчика ПО.

Заключение

Логирование данных — это фиксация событий в работе веб-ресурса, помогающая его администраторам вовремя выявлять баги системы, исправлять их, предотвращать появление ошибок или сбоев в будущем. Кроме указанных выше функций, информация из логов позволяет маркетологам получать данные про объем трафика, время посещения страниц, страницы входа/выхода, географию посетителей и другую важную для повышения конверсии информацию. Таким образом, логирование является важным этапом контроля и мониторинга работы системы, позволяющим увеличить коэффициент ее производительности.