Журналы: Голос кода

Данные - это новое масло, поэтому регистрация так важна!

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

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

В общем, наш код разговаривает с нами тремя способами.

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

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

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

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

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

На что обращать внимание во фреймворке логирования?

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

Влияние на скорость

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

ALL - lowest possible rank and is intended to turn on all logging.
DEBUG - fine-grained informational events for debugging.
ERROR - error events that might still allow the application to continue running.
FATAL - very severe error events that will presumably lead the application to abort.
INFO - informational messages that highlight the progress of the application at coarse-grained level.
WARN - potentially harmful situations.

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

logger.debug("Some $expensive message!")

Это в основном позволит оценить дорогое сообщение. Чего мы не хотим делать. Вместо этого сделайте следующее:

if (logger.isDebugEnabled) logger.debug("Some $expensive message!")

Легкость использования

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

Достаточно ли ведения журнала?

логирование

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

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

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

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

Отслеживание

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

Для этого используется идентификатор трассировки для ведения журнала, который согласован для вызовов микросервисов. Это позволяет узнать, как отдельный запрос перемещается от одного микросервиса к другому.

Kibana, Zipkin, Jaeger - немногие из провайдеров распределенной трассировки.

Заключение

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

Внедрите ведение журнала и позвольте вашим службам общаться с вами!

Другие интересные статьи: