Поразмышляю немножко непосредственно о программировании. По работе - последние несколько дней я занимаюсь анализом логов. На первый взгляд, кажется что логирование – очень простой и полезный процесс. Однако это только кажется. В руках разработчиков, которые слабо понимают, что и зачем делают – логирование это процесс, который только мешает. И процессу разработки и процессу анализа ошибок. Ошибки, которые мне создают наибольшее количество боли я и хочу обсудить.
Начнем с общего количества логов. Уважаемые коллеги и интересующиеся читатели. Помните. Если вы не собираетесь логи читать и анализировать – не логируйте ничего. В противном случае вы просто забьете мусором дисковое хранилище. Это касается любого логирования. Представьте, что вы ответственный web-разработчик и реализовали безусловную трассировку всех входящих запросов и ответов в API. Вы на белом коне, вы имеете бесконечный источник поиска узких мест в проекте. Но если вы не смотрите на результаты – вы просто забиваете дисковое пространство и тратите вычислительную мощность процессора на бесполезные действия. Есть достаточно просто решение. Если вы реализовали систему логирования самостоятельно – то закладывайте функциональность включения/выключения логирования в зависимости от настроек проекта. А если вы используете что-то готовое – следите за режимом работы используемого продукта. Режим неврастеника не даст ничего кроме переполненного жесткого диска.
Если дошли до этих строк – значит все же логирование вам нужно. Самое минимальное, что необходимо логировать, на мой взгляд – необработанные исключения. На разных платформах данный функционал реализуется по-разному, но быть он должен. Из этой рекомендации есть несколько следствий:
1) Подумайте над необходимостью логирования обработанных исключений. Тут мы возвращаемся к банальному количеству логов. Я считаю, что обработанная ошибка – это часть бизнес-логики, поэтому логирование данного события вопрос не однозначный. И если уж соберетесь логировать – логируйте как предупреждение, а не ошибку.
2) Такого же продумывания требует сценарий самостоятельного выбрасывания исключения.
Никогда не используйте синхронное логирование. Используете вы сохранение логов в БД или файле или еще где – не важно. Вы включаете в свою бизнес-логику действия, которые 100% не являются частью бизнес-логики. Вы тратите на это ресурсы, следовательно, время ожидания ответа увеличится. Соответственно если вы пишете много логов – большую часть времени ваш сервис будет писать логи, а не делать что-то полезное.
Если вы не пишете, а анализируете логи – всегда требуйте от разработчиков логировать важные вам процессы и параметры. Они сами никогда в жизни не догадаются. В лучшем случае – будут разбирать баги, поймут, что логов мало и напишут. Но добровольно и сами могут не сделать.
Если вы реализовали некий класс, запоминающий совершенные действия (например, логируете поведение приложения, но сохраняете данный лог только при определенных обстоятельствах), то позаботьтесь чтобы ваша работа не была в пустую. Звучит как бред сумасшедшего, но буквально на днях увидел в проекте модуль, который делает около 20 записей, а затем просто выкидывает эти записи вне зависимости от того возникла ошибка или нет.
Вне зависимости от того сколько у вас клиентов одновременно – крайне полезной фичей является объединение логов в цепочку. Снова звучит как заявление капитана очевидность, однако почему-то не все мои коллеги понимают, зачем это. Так что либо я работаю с редкостно тупыми людьми, либо людей думающих так больше чем кажется. Зачем это нужно? Представьте, что вы видите 100-1000 логов подряд (да не важно, хоть 2). Полезно знать какие логи были записаны в рамках атомарного действия пользователя.
Вместо итога – вообще было бы хорошо, если все разработчики в команде знают что и зачем делают. Если люди не понимают, зачем логировать процесс – я могу тут исписать любое количество бумаги и любыми красноречивыми словами. Все будет бесполезно. Я считаю, что таких людей может исправить только посадка править собственные баги в не логированном сценарии. Ну а если вы в здравом уме и твердой памяти – к моим советам вы и сами должны прийти в рамках рабочего процесса. Кому тогда я это написал? Да, наверное, себе. Просто выговориться.
%��@ߏ