На многих проектах я видел душевные попытки внедрить какую-нибудь новомодную фичу, поставить всё на свежий фреймворк, подключить какие-нибудь крутые библиотеки, внедрить практики TDD, или наконец отрефакторить всё для будущих поколений. Но только один раз я встретил тимлида, который не проявлял столько интереса к фреймворкам и примочкам, сколько к грамотному логированию. За годы разработки я как-то привык, что логи пишутся в произвольном порядке — даже на порталах Нацбанка и Налоговой с ними была откровенная беда и сплошная отсебятина.
Логи в реальной жизни
Одна из основных причин, почему на большинстве проектов не уделяется должного внимания логам, — «можно и без них». Серьезно. Кому они нужны?
Логирование — это когда муж приходит домой и кричит жене: «Лена, я дома!». Логирование — это когда ребенок, уходя на улицу, кричит родителям в другой комнате: «папа, буду вечером!». И наконец, обычный школьный дневник или аттестат — чем не лог? Можно ли хорошо учиться без дневника и аттестата? Запросто. Обязательно ли, заходя в квартиру, вещать всем «я дома»? Нет. Вас, вероятно, и так заметят через минуту. Всё это логирование — периферийный, второстепенный процесс, который не выполняет никакого реального дела. Но только до тех пор, пока не появится проблема.
Мама, грепни мой дневник
Если в один прекрасный день вашего ребенка выгоняют из школы по причине плохой успеваемости, то можно, конечно, начать «дебажить». Задать ребенку пару наводящих вопросов, звякнуть учителям и спросить об успеваемости на протяжении года, пообщаться с одноклассниками и выяснить активность ребенка на уроках. В конце концов, после небольшого детективного расследования вам удастся выяснить причину и начать ломать голову над тем, как вернуть ребенка в школу. Но не проще ли было регулярно «грепать» дневник и аттестат?
И родители грепают. Для удобства дневники расчерчены в таблицы, где виден месяц, день недели, число. Напротив каждого предмета есть место для оценки и замечания, которое пишется красным цветом, который зарезервирован только для учителя. Эти логи неплохо оформлены и позволяют быстро найти причину, по которой ребенка выгнали из школы. Более того, еженедельный смотр логов позволяет увидеть тенденции в успеваемости ребенка и заранее предпринять какие-нибудь меры, чтобы приложение не «упало». Почему бы тогда не уделять логам на проектах больше внимания?
Чем лучше логи, тем меньше дебага
Конечно, если возникает проблема, то можно кинуть пару Exception’ов, включить Debug, отловить всё и пофиксить. Можно также добавить ситуативные logger.info() или старый добрый System.out.println(). Если приложение валится где-нибудь на продакшене, то вполне реально справиться с помощью Remote Debug (хоть и не всегда). Но всё это суета. Грамотно оформленные логи могут позволить почти не использовать Debug. И эти же логи помогут заглянуть в такие глубины приложения, где не ступала нога удаленного дебага. Поэтому мы просто обязаны сделать логи удобочитаемыми и удобогрепаемыми.
Принципы грамотного логирования:
1.Логи должны отражать все важные события. Например: запуск приложения, старт/стоп транзакций, успешный логин, возникновение ошибок и так далее.
2.Их должно быть легко грепать. Как вариант, есть смысл не только позаботиться об уникальности тех слов/символов, по которым вероятен поиск, но и исключить часто повторяющиеся слова. Не хотелось бы попасть в ситуацию, когда грепать нужно по <apple.juice.com>, который упоминается в каждой строчке лога.
3.Добавляйте [TAGS] для маркировки концепций приложения. Например: [TRANSACTION], [DEVICE], [LOGIN] и так далее. Грепая по этим тегам, можно получить срез логов по девайсам, транзакциям и другим процессам, которые обычно «размазаны» по нескольким классам.
4.Все логи конкретного проекта должны соответствовать определенному формату. Например, команда может условиться использовать такой порядок: ---> [TAG] текст_сообщения ### [IP]. В реальной жизни это было бы похоже на: INFO transaction.ScheduledReportTransactionService ---> [TRANSACTION] starting to execute on schedule ### [127.0.0.1]
Унифицированный подход к оформлению логов облегчит их чтение не только для самих разработчиков, но и для тех людей (например, клиентов), которым потом придется с ними работать.
5.Одна строка — одно сообщение. Стоит ограничиться выводом одного сообщения на строку, иначе греп будет не так эффективен.
6.Логов не должно быть слишком много и они не должны быть избыточными — лишняя информация будет засорять экран. Только самое важное и нужное.
И наконец, следует сознательно пользоваться разными уровнямилогирования: INFO, WARNING, ERROR, FATAL. На многих проектах девелоперы повально увлеклись уровнем INFO. Может, потому, что сообщения в logger.info() не выделяются жутким красным цветом? Мухи отдельно, котлеты отдельно — называя вещи своими именами, мы облегчаем себе диагностику ситуации. Если есть потенциальная проблема — быть WARN’у, если это ошибка — быть ERROR’у, ну, а если мы хотим дать безобидное сообщение и всё хорошо — включаем INFO.
Еще один плюс в пользу информативных логов: если приложение запущено на продакшене и нет доступа к дебагу, именно логи станут главным источником информации, которая позволит определить и пофиксить проблему. Поэтому лучше их держать в чистоте и порядке, да на коротком поводке.
Если у вас есть свои фишки, связанные с логированием, — делитесь в комментах.