СправочникОбновлено · 07.2026

Журналирование событий (Event Logging): запись, управление и аудит информации

14 июля 2023 · 8 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Обновлено в 2026 году. Автор: Дмитрий Соколов, backend-разработчик, преподаватель Зерокодера.

Журналирование (логирование, event logging) — это запись хода работы программы или системы в отдельные файлы или хранилище: кто что сделал, когда, с каким результатом и какая ошибка возникла. Эти записи называют логами. Они нужны для отладки, аудита действий пользователей, мониторинга нагрузки и расследования инцидентов безопасности — то есть чтобы понять, что происходило в системе, когда рядом не было человека.

• Лог — это структурированная запись события: время, уровень важности, источник, сообщение.
• Уровни (DEBUG, INFO, WARNING, ERROR, CRITICAL) регулируют, насколько подробно вы пишете.
• В прод обычно оставляют INFO и выше, в разработке включают DEBUG.
• Пароли, токены и персональные данные в логи писать нельзя — это утечка.
• Структурированный формат (JSON) и ротация файлов — стандарт для боевых сервисов.

Что такое журналирование событий (event logging)

Журналирование событий — процесс записи информации о действиях в системе или приложении: обращения пользователей, запуск процессов, ошибки, изменения настроек, попытки входа. Каждая запись фиксирует, что произошло и в какой момент. В отличие от отладки «руками» через вывод на экран, лог сохраняется и остаётся доступным после того, как программа завершилась или упала. Именно поэтому по логам восстанавливают картину сбоя, который не удаётся воспроизвести.

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

Зачем нужно журналирование

Четыре задачи, ради которых логи ведут:

1. Отладка и поиск ошибок. Запись помогает найти место сбоя, его причину и последствия — особенно для багов, которые проявляются только в проде и не ловятся тестами.
2. Мониторинг и производительность. Логи показывают нагрузку, время ответа, узкие места. По ним строят графики и настраивают алерты.
3. Аудит и безопасность. Кто вошёл, что изменил, откуда была попытка несанкционированного доступа. Логи — источник доказательств при расследовании инцидента и часть требований по комплаенсу.
4. Разбор инцидентов постфактум. Когда сервис лежал ночью, единственный свидетель — лог. Без него разбор превращается в гадание.

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

Уровни логирования: DEBUG, INFO, WARNING, ERROR, CRITICAL

Уровень — это метка важности записи. Он позволяет одним параметром регулировать, сколько деталей писать. У каждого уровня есть числовое значение: чем оно выше, тем серьёзнее событие. Логгер пропускает только записи со значением не ниже порога, который вы задали. Значения ниже взяты из официальной документации Python logging.

Уровень	Значение	Что означает	Когда использовать
DEBUG	10	Детальная диагностика: переменные, шаги выполнения	Разработка и тесты. В проде обычно выключен из-за объёма
INFO	20	Штатный ход работы: запуск, ключевые этапы	Подтверждение, что всё идёт как задумано
WARNING	30	Что-то пошло не так, но система работает	Мало места на диске, устаревший вызов, повтор запроса
ERROR	40	Сбой: функция не выполнилась	Не удалось подключиться к базе, упал внешний сервис
CRITICAL	50	Фатальная ошибка, система может остановиться	Кончилась память, сервис прекращает обработку запросов

Важная деталь, о которую спотыкаются новички: в Python корневой логгер по умолчанию имеет уровень WARNING. Это значит, что без явной настройки ваши вызовы logger.info() и logger.debug() просто не появятся в выводе — не потому что код неверный, а потому что порог отсекает их. Чтобы увидеть INFO и DEBUG, уровень нужно опустить вручную.

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

Что писать в лог, а что нельзя

Полезная запись отвечает на три вопроса: что произошло, где и с какими данными контекста. Хорошая практика — писать идентификаторы (ID заказа, ID пользователя, ID запроса), коды ошибок, длительность операций, имена внешних сервисов.

Категорически нельзя писать в логи в открытом виде:

• пароли, токены доступа, JWT, ключи API, секреты;
• персональные данные: ФИО, паспорт, телефон, email, адрес;
• номера банковских карт, CVV, реквизиты платежей;
• содержимое переписки и любые данные под требования по защите ПД.

Лог часто уходит в централизованное хранилище, к которому имеет доступ вся команда и внешние системы мониторинга. Секрет, попавший в лог, считается скомпрометированным. Поэтому чувствительные поля маскируют (card=****1234) или вырезают ещё до записи. Это не паранойя, а прямое требование безопасности и закона о персональных данных.

Структурированное логирование (JSON)

Классический лог — это строка текста: удобно читать глазами, тяжело обрабатывать машиной. Структурированный лог пишет каждую запись как объект с именованными полями, чаще всего в формате JSON:

{"time": "2026-07-06T10:15:23Z", "level": "ERROR", "service": "payments", "order_id": 48213, "msg": "gateway timeout", "duration_ms": 5001}

Преимущество в том, что по такому логу можно искать и фильтровать по полям: показать все ERROR сервиса payments за час, посчитать среднюю длительность, построить график. Именно поэтому системы сбора логов (ELK, Loki, Grafana, облачные CloudWatch и Datadog) ждут структурированный ввод. Для микросервисов и распределённых систем JSON-логи давно стали стандартом де-факто: без общего формата собрать картину из десятков сервисов невозможно.

Ротация логов: как не забить диск

Лог растёт постоянно, и без ограничений он способен заполнить весь диск и уронить сервис. Ротация — это автоматическая замена активного файла новым при достижении порога, с сохранением старых версий. Есть два подхода: по размеру и по времени. В Python оба реализованы штатными обработчиками.

• По размеру — RotatingFileHandler. Задаёте maxBytes (порог) и backupCount (сколько копий хранить). При переполнении app.log закрывается, переименовывается в app.log.1, старые сдвигаются дальше, а самая старая удаляется.
• По времени — TimedRotatingFileHandler. Параметр when задаёт интервал ('H' — час, 'D' — день, 'midnight' — в полночь), backupCount ограничивает число архивов.

На уровне сервера ту же задачу решает утилита logrotate в Linux: она архивирует старые логи, сжимает их в .gz и удаляет по расписанию.

Где хранить логи

Три типовых варианта, от простого к зрелому:

1. Локальные файлы. Просто и надёжно для одного сервера. Минус — при десятке машин логи разбросаны, искать неудобно.
2. Централизованный сбор. Агент забирает логи со всех серверов в единое хранилище (ELK, Grafana Loki, облачные сервисы). Поиск по всей системе из одного окна — стандарт для продакшена.
3. База данных / специализированное хранилище. Для аудита и долгого хранения, где важны неизменяемость и быстрый поиск по полям.

Инструменты журналирования

Обзорно, что используют на практике: встроенные библиотеки языков (Python logging, Java Logback и Log4j, Go slog); системный journald и syslog на Linux; для сбора и анализа — стек ELK (Elasticsearch, Logstash, Kibana), Grafana Loki, а также облачные Amazon CloudWatch и Datadog. Выбор зависит от масштаба: одному сервису хватит файла и logrotate, распределённой системе нужен централизованный сбор.

Пример журналирования на Python

Минимальная настройка через стандартную библиотеку logging. Ниже — запись в файл с уровнем INFO и понятным форматом строки:

import logging

logging.basicConfig(
    filename="app.log",
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
)

logger = logging.getLogger(__name__)

logger.debug("Подробность для отладки")   # не попадёт: ниже порога INFO
logger.info("Сервис запущен")
logger.warning("Осталось 10%% свободного места")

try:
    1 / 0
except ZeroDivisionError:
    logger.error("Деление на ноль", exc_info=True)  # запишет и трейсбек

Здесь basicConfig настраивает корневой логгер: файл, порог и формат. Вызов getLogger(__name__) возвращает именованный логгер — при одинаковом имени это всегда один и тот же объект, поэтому логгеры удобно заводить в каждом модуле. Строка debug в вывод не пойдёт, потому что уровень задан INFO. А флаг exc_info=True добавит к записи полный стек ошибки — незаменимо при разборе исключений.

Чтобы включить ротацию по размеру, вместо basicConfig подключают обработчик:

from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler("app.log", maxBytes=5_000_000, backupCount=5)
logger.addHandler(handler)
# держим не более 5 архивов по ~5 МБ: app.log, app.log.1 ... app.log.5

Вывод: рабочее журналирование в Python — это три решения: куда писать (файл/поток), с каким порогом (уровень) и как ограничить рост (ротация). Всё остальное — детали формата.

Чек-лист настройки журналирования

• Определите, какие события критичны для вашей системы, и не логируйте всё подряд.
• Проставьте уровни: детали — в DEBUG, штатное — в INFO, проблемы — в WARNING и выше.
• В проде оставьте INFO и выше, DEBUG включайте точечно при разборе.
• Никогда не пишите пароли, токены и ПД — маскируйте чувствительные поля.
• Для боевого сервиса используйте структурированный формат (JSON).
• Настройте ротацию по размеру или времени, чтобы не забить диск.
• Ограничьте доступ к логам и настройте резервное копирование.

Частые вопросы

Чем журналирование отличается от логирования? Это синонимы. «Журналирование» — русский термин, «логирование» — калька с английского log. Оба означают запись событий системы. Английское название — event logging.

Какие уровни логов существуют? Стандартный набор — DEBUG, INFO, WARNING, ERROR, CRITICAL, по возрастанию важности. В Python им соответствуют числа 10, 20, 30, 40 и 50.

Что нельзя писать в логи? Пароли, токены доступа, ключи API, персональные данные (ФИО, паспорт, телефон, email), номера карт. Такие данные маскируют или вырезают до записи.

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

Что такое структурированное логирование? Запись каждого события как объекта с именованными полями (обычно JSON) вместо простой строки. Такой лог удобно искать, фильтровать и агрегировать машинными средствами.

Точные значения уровней и поведение обработчиков сверены с официальной документацией: docs.python.org — модуль logging.