Лог включен, но мало помогает

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

И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?

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

Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.

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

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

Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.

Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.

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

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

А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.

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

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

А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».

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

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

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

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

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

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