Что такое логирование ошибок

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

• Сложность реальных приложений
• Логирование
• Уровни логирования
• Ротация логов

Сложность реальных приложений

Возьмем для примера типичный сайт. Что он в себя включает?

• DNS. Система трансляции имени сайта в ip-адрес сервера.
• Веб-сервер. Программа, обслуживающая входящие запросы, перенаправляет их в код приложения и забирает от приложения данные для пользователей.
• Физический сервер (или виртуальный) с его окружением. Включает в себя операционную систему, установленные и запущенные обслуживающие программы, например, мониторинг.
• База данных. Внешнее хранилище, с которым связывается код приложения и обменивается информацией.
• Само приложение. Помимо кода, который пишут программисты, приложение включает в себя сотни тысяч и миллионы строк кода сторонних библиотек. Кроме этого, код работает внутри фреймворка, у которого свои собственные правила обработки входящих запросов.
• Фронтенд часть. Код, который выполняется в браузере пользователя. И системы сборки для разработки, например, Webpack.

И это только самый простой случай. Реальность же значительно сложнее: множество разноплановых серверов, системы кеширования (ускорения доступа), асинхронный код, очереди, внешние сервисы, облачные сервисы. Все это выглядит как многослойный пирог, внутри которого где-то работает написанный нами код. И этот код составляет лишь небольшую часть всего происходящего. Как в такой ситуации понять, на каком этапе был сбой, или все пошло не по плану? Для этого, как минимум, нужно определить, в каком слое произошла ошибка. Но даже это не самое сложное. Об ошибках в работающем приложении узнают не сразу, а уже потом, — когда ошибка случилась и, иногда, больше не воспроизводится.

Логирование

И для всего этого многообразия систем существует единое решение — логирование. В простейшем случае логирование сводится к файлу на диске, куда разные программы записывают (логируют) свои действия во время работы. Такой файл называют логом или журналом. Как правило, внутри лога одна строчка соответствует одному действию.

# Формат: ip-address / date / HTTP-method / uri / response code / body size 
173.245.52.110 - [19/Jan/2021:01:54:20 +0000] "GET /my HTTP/1.1" 200 46018
108.162.219.13 - [19/Jan/2021:01:54:20 +0000] "GET /sockjs-node/244/gdt1vvwa/websocket HTTP/1.1" 0 0
162.158.62.12 - [19/Jan/2021:01:54:20 +0000] "GET /packs/css/application.css HTTP/1.1" 304 0
162.158.62.84 - [19/Jan/2021:01:54:20 +0000] "GET /packs/js/runtime-eb0a99abbe8cf813f110.js HTTP/1.1" 304 0
108.162.219.111 - [19/Jan/2021:01:54:20 +0000] "GET /packs/js/application-2cba5619945c4e5946f1.js HTTP/1.1" 304 0
108.162.219.21 - [19/Jan/2021:01:54:20 +0000] "GET /packs/js/0564a7b5d773bab52e53.js HTTP/1.1" 304 0
108.162.219.243 - [19/Jan/2021:01:54:20 +0000] "GET /packs/js/6fb7e908211839fac06e.js HTTP/1.1" 304 0

Выше небольшой кусок лога веб-сервера Хекслета. Из него видно ip-адрес, с которого выполнялся запрос на страницу и какие ресурсы загружались, метод HTTP, ответ бекенда (кода) и размер тела ответа в HTTP. Очень важно наличие даты. Благодаря ей всегда можно найти лог за конкретный период, например на то время, когда возникла ошибка. Для этого логи грепают:

# Выведет 4 минуты логов за 31 марта 2020 года с 19:31 по 19:35
grep "31/Mar/2020:19:3[1-5]" access.log

Когда программисты только начинают свой путь, они, часто не зная причину ошибки, опускают руки и говорят «я не знаю, что случилось, и что делать». Опытный же разработчик всегда первым делом говорит «а что в логах?». Анализировать логи — один из базовых навыков в разработке. В любой непонятной ситуации нужно смотреть логи. Логи пишут все программы без исключения, но делают это по-разному и в разные места. Чтобы точно узнать, куда и как, нужно идти в документацию конкретной программы и читать соответствующий раздел документации. Вот несколько примеров:

• Ruby On Rails (Ruby)
• Django (Python)
• Laravel (PHP)
• Spring Boot (Java)
• Fastify (Node.js)

Многие программы логируют прямо в консоль, например Webpack показывает процесс и результаты сборки:

# Сюда же выводятся ошибки, если они были
｢wds｣: Project is running at http://hexletdev4.com/
｢wds｣: webpack output is served from /packs/
｢wds｣: Content not from webpack is served from /root/hexlet/public/packs
｢wds｣: 404s will fallback to /index.html
｢wdm｣: assets by chunk 10.8 MiB (auxiliary name: application) 115 assets
sets by path js/ 13.8 MiB
assets by path js/*.js 13.8 MiB 52 assets
assets by path js/pages/*.js 5.1 KiB
  asset js/pages/da223d3affe56711f31f.js 2.6 KiB [emitted] [immutable] (name: pages/my_learning) 1 related asset
  asset js/pages/04adacfdd660803b19f1.js 2.5 KiB [emitted] [immutable] (name: pages/referral) 1 related asset
sets by chunk 9.14 KiB (auxiliary id hint: vendors)

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

Уровни логирования

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

• debug
• info
• warning
• error

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

// Пример логирования внутри программы
// Логер: https://github.com/pinojs/pino

import buildLogger from 'pino';

const logger = buildLogger(/* возможная конфигурация */);
logger.info('тут что то полезное');

Во-вторых, во время запуска программы указывается уровень логирования, необходимый в конкретной ситуации. По умолчанию используется уровень info, который используется для описания каких-то ключевых и важных вещей. При таком уровне будут выводиться и warning, и error. Если поставить уровень error, то будут выводиться только ошибки. А если debug, то мы получим лог, максимально наполненный данными. Обычно debug приводит к многократному росту выводимой информации.

Уровни логирования, обычно, выставляются через переменную окружения во время запуска программы. Например, так:

# https://github.com/fastify/fastify-cli#options
FASTIFY_LOG_LEVEL=debug fastify-server.js

Существует и другой подход, основанный не на уровнях, а на пространствах имен. Этот подход получил широкое распространение в JS-среде, и является там основным. Фактически, он построен вокруг одной единственной библиотеки debug для логирования, которой пронизаны практически все JavaScript-библиотеки как на фронтенде, так и на бекенде.

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

import debug from 'debug';

// Пространство имен http
const logHttp = debug('http');
const logSomethingElse = debug('another-namespace');

// Где-то в коде

logHttp(/* информация о http запросе */);

Запуск с нужным пространством:

DEBUG=http server.js

Ротация логов

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

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

Здесь тоже есть несколько путей. Можно воспользоваться готовыми решениями, такими как DataDog Logging, либо устанавливать и настраивать все самостоятельно через, например, ELK Stack

О чём могут рассказать логи: важный инструмент в работе тестировщика

Привет, Хабр! Меня зовут Анфиса Одинцова, я — наставница в Яндекс Практикуме на курсе «Инженер по тестированию». Сейчас работаю в JoomPay, а раньше — в Яндекс Дзен и ВК. В этой статье расскажу о важном аспекте тестирования — работе с логами. Ведь в мире разработки программного обеспечения логирование играет ключевую роль в обеспечении качества и отладке приложений. Для тестировщиков логи — ценный инструмент, который помогает нам понять работу приложения, обнаружить потенциальные проблемы и сделать наше тестирование более эффективным.

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

Что такое логи и когда в них смотреть

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

Когда тестировщик смотрит в логи

В зависимости от вида проводимого тестирования тестировщик может воспользоваться информацией из логов. 

• При тестировании новой фичи. Стоит держать логи открытыми, они помогут отследить правильность выполнения определенных операций, последовательность событий и другие аспекты функциональности приложения.
  К примеру, если упадет ошибка (ERROR) или предупреждение (WARN) — о них мы подробнее поговорим дальше, — мы всегда могли сообщить разработчику и быстро нейтрализовать проблему.

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

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

• Для более точного определения причины бага и отладки ошибки. В логах может содержаться необходимая информация для идентификации бага, логи могут содержать полезную информацию о возникших исключениях, трассировке стека, сообщениях об ошибках или недостаточных данных, которые могут помочь воспроизвести и понять причину ошибки. А чем больше информации мы принесём разработчику, тем быстрее он починит баг. 

• Для оценки производительности приложения. Логи могут содержать информацию о времени выполнения определенных операций, использовании ресурсов (например, процессора, памяти) и других показателях производительности. Тестировщик может использовать эти данные для определения узких мест в приложении и предложения улучшений.

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

Типы и уровни логов

Для начала разберёмся в категориях логов. Логи бывают разных типов и уровней детализации и критичности. 

Уровни логирования 

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

Тестировщику они нужны для понимания того, есть ли ошибка / насколько она серьёзная и нужно ли заводить баг и отнести баг-репорт.

Уровни логирования бывают: 

• FATAL: является наивысшим уровнем критичности логов и указывает на самые критические ошибки и проблемы, которые могут привести к немедленному завершению программы или системы. Логи с уровнем FATAL обычно означают серьезные сбои, которые требуют немедленного вмешательства и исправления. 

• ERROR: этот уровень используется для записи ошибок и проблем, которые могут привести к некорректной работе приложения. Логи с уровнем ERROR указывают на проблемы, которые требуют вмешательства и исправления.

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

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

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

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

Уровни детализации, с которыми чаще всего сталкивается тестировщик

Тестировщик чаще всего работает с ошибками (ERROR, реже FATAL) и c предупреждениями (WARN). Но для получения информации иногда, бывает, обращается к информационным логам (INFO). 

Уровень логирования может быть настроен в зависимости от потребностей разработчика или тестировщика. 

Обычно в продакшене уровень детализации не устанавливается на самый высокий, чтобы не перегружать логи большим объёмом информации. В то время как во время разработки или отладки можно использовать такие уровни детализации, как DEBUG или TRACE, для более глубокого анализа и отслеживания проблем.

Визуально уровни логирования можно представить таким образом:

Какие виды логов бывают и зачем их знать тестировщику

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

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

Тестировщик чаще всего работает с логами приложения, логами сервера и системными логами. Разберёмся, что значит каждый из видов:

1. Логи приложений (Application logs). Это логи, создаваемые самим приложением в процессе его работы. Это может быть веб, десктоп и мобильное приложение. Они содержат информацию о выполнении операций, событиях, ошибочных ситуациях, запросах, ответах и других событиях, внутри приложения.

1. Логи сервера (Server logs). Это логи, генерируемые серверами и веб-серверами. Они содержат информацию о работе сервера, запросах, ошибочных ситуациях, подключениях и других событиях, происходящих на сервере. Логи сервера помогают администраторам серверов и разработчикам отслеживать состояние сервера, обнаруживать проблемы с производительностью, безопасностью и настраивать серверное окружение.

Логи сервера часто делятся на два типа: 

• Error logs (это информация об ошибках)

• Access Logs (общая информация о запросах и ответах к серверу) 

1. Системные логи (System logs): Это логи, записываемые операционной системой. Они содержат информацию о работе операционной системы, событиях, ошибках, состоянии системы, процессах, сетевых подключениях и других системных событиях.

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

Что хранится в логах

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

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

• системную информацию (время и дата события, ID события и другая служебная информация);

• уровень лога;

• текст сообщения (например, сообщения об ошибке);

• контекст (дополнительная информация).

Разберем, как это выглядит, на сообщении об ошибке: 

Дата и время: 2023-05-18 10:23:45 — указывает точное время, когда произошла ошибка.

Уровень лога: [ERROR] — указывает на уровень ошибки.

Контекст: [Server] — указывает на компонент или модуль системы, в котором произошла ошибка.

Сообщение об ошибке: Exception occurred while processing request — описание самой ошибки.

Стек вызовов: Последующие строки показывают стек вызовов и указывают на классы и методы, в которых произошла ошибка. В данном примере указывается, что ошибка возникла в методе handleRequest класса MyController (строка 32), затем в методе processRequest класса Server (строка 87) и так далее.

Заключение

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

13.04.2021

Дата обновления: 02.03.2022

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

Логирование: что это и где применяется

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

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

Логи должны записываться во время работы каждого ИТ-компонента.

Вот несколько типичных случаев, в которых применяются логи:

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

Типы логов

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

Для удобной работы с логами их делят на типы. Это помогает быстрее находить нужные и выбирать правильные инструменты для работы с ними. Например, выделяют:

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

Также логи можно типизировать по степени их важности:

• Fatal/critical error — то, что нужно срочно исправить.
• Not critical error — ошибки, которые не влияют на пользователя.
• Warning — предупреждения, то, на что нужно обратить внимание.
• Initial information — информация о вызовах API сервиса, запросах в БД, вызовах других сервисов.

Где ITGLOBAL.COM использует логирование

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

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

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

Инструменты

Сбор, хранение и анализ логов выполняется с помощью специальных инструментов. Расскажем, какие из них используют специалисты ITGLOBAL.COM.

Elasticsearch, Logstash и Kibana

Логи всех информационных систем, подключенных к услуге Managed IT, хранятся в распределенном хранилище на базе решения ELK (Elasticsearch, Logstash и Kibana). Механизм сбора логов выглядит так: Logstash собирает логи и переносит их в хранилище, Elasticsearch помогает найти нужные строки в этих логах, а Kibana визуализирует их. Все три компонента разработаны на основе открытого кода, благодаря чему их можно модифицировать под потребности компании.

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

Wazuh

Решение с открытым кодом для поиска логов, коррелирующих с моделями угроз информационной безопасности. С его помощью специалисты ITGLOBAL.COM мониторят целостность ИТ-систем и оперативно реагируют на инциденты.

Wazuh помогает:

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

Почему логирование нужно каждой компании

Логирование — еще один способ эффективно контролировать состояние инфраструктуры. В ITGLOBAL.COM оно входит в пакет услуг Managed IT. Вместе с сервисами мониторинга логирование существенно экономит время инженеров при расследовании тех или иных инцидентов. А главное, с помощью анализа логов можно предотвратить инциденты в будущем.

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

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

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

Что такое логгер

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

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

Где может храниться лог

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

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

Также логи могут отправляться в другую программу, например в систему мониторинга и аналитики.

Как работает логгер

Логгер ничего не делает сам по себе, и, чтобы в лог попала какая-то запись, программист должен добавить в программу команду типа такой:

«Запиши в лог: в {hour} часов {min} минут к серверу подключился новый пользователь с адресом {IP}»

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

<script src="debug.js">

После этого мы получаем доступ к логгеру и можем что-нибудь отправить в лог:

debug('Такой-то модуль загрузился')

Уровни логирования

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

• Debug — когда мы пишем в лог сообщения, что стартовала какая-то функция или мы получили ответ от сервера.
• Info — информация о разовых ситуациях, например: считали базу данных при запуске, установили соединение с сервером, начали работу.
• Warning — ещё не ошибка, но происходит что-то странное: сервер не ответил, пользователь ввёл не тот пароль, вместо данных пришли нули.
• Error — ошибки в работе программы. Обычно их отлавливают с помощью исключений.

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

logger.info('Запустился модуль проверки лицензии, ждём ответ')

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

А можно сделать свой логгер и им пользоваться в проектах?

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

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

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

Что дальше

Теперь, когда мы знаем о логгерах достаточно, попробуем применить их в разных проектах — сначала на JavaScript, а потом на Python.