// codeart.ru / Работаем с кодом / Каким должен быть правильный лог-файл Форум

Каким должен быть правильный лог-файл rss подписка

Автор: Evgeniy Sergeev

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

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

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

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

Лог должен быть один

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

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

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

Лог должен содержать полную информацию о действиях пользователя

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

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

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

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

Лог должен представлять из себя обычный текстовый файл.

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

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

Лог должен содержать информацию в терминах, понятных пользователям и администраторам

Я очень долго пытался сформулировать понятное название этого раздела, но это оказалось достаточно сложным. Основной смысл в том, что программист видит программу и имеет свободный доступ к любым ее данным (об этом я уже писал раньше, но повторить не лишне). Администратор же вообще не представляет внутреннее содержание программы и не имеет свободного доступа к внутренним данным. Зато он общается с пользователем и имеет представления о том, какие данные вводил пользователь.

Поэтому программисту при записи в лог следует подумать, а сможет ли администратор правильно интерпретировать данные полученные из лога.

Простой пример в многопользовательской программе с разделением прав пользователей — имя пользователя (логин) проверяется лишь единожды: в процессе авторизации. Затем для идентификации пользователя может использоваться такой параметр как uid (user id), когда возникает необходимость записать в лог информацию о том, какое действие выполняется пользователем в настоящее время, у программиста уже нет логина пользователя и для его получения требуется приложить некоторые усилия, зато у программиста есть uid, и ему намного проще записать в лог именно его. А что делать администратору, чтобы ассоциировать пользователя и его uid? Проблема даже не в том, что это требует времени, которого никогда не бывает много, бывают ситуации, когда этого просто невозможно сделать.

Я считаю, что программист должен стремиться к тому, чтобы передавать в лог информацию, которую администратор может получить от пользователя (в примере выше — это имя пользователя), а не ту, которая используется внутри приложения.

Программа должна изначально разрабатываться с прицелом на максимально подробное логирование

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

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

  1. Размышления о логировании | Лобач.info
  1. А какие бывают типы логов пользовательских программ?

Leave a Reply

« »