Как использовать уровни логирования

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

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

Значение уровней журнала.
Краткая история уровней журнала.
Общие уровни журналов и как их эффективно использовать.
Использование уровней для регулирования объема генерируемого журнала.
Как использовать уровни журнала для последующего анализа.

Краткая история уровней логирования

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

Ниже приведены уровни, определенные системным журналом в порядке убывания важности:

Emergency (emerg): указывает, что система непригодна для использования и требует немедленного вмешательства.
Предупреждение (alert): указывает на необходимость немедленных действий для решения критической проблемы.
Критический (crit): обозначает критические состояния в программе, которые требуют вмешательства для предотвращения сбоя системы.
Ошибка (error): указывает на обстоятельства с ошибкой, которые нарушают некоторые операции, но менее серьезны, чем критические ситуации.
Предупреждение (warn): обозначает потенциальные проблемы, которые могут привести к ошибкам или неожиданному поведению в будущем, если их не устранить.
Примечание (notice): применяется к нормальным, но важным состояниям, которые могут потребовать наблюдения.
Информационное (info): включает сообщения, отражающие нормальную работу системы.
Отладка (debug): предназначена для записи подробной информации о системе в целях отладки.

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

Конкретные уровни ведения журнала, доступные вам, могут меняться в зависимости от языка программирования, фреймворка для ведения журнала или используемой службы. Однако в большинстве случаев вы можете столкнуться с такими уровнями, как FATAL, ERROR, WARN, INFO, DEBUG, и TRACE. Хотя многие платформы ведения журналов позволяют вам переопределять уровни журналов по умолчанию и определять собственные уровни, мы обычно рекомендуем придерживаться уровней, описанных ниже. Они расположены в порядке убывания срочности.

1. FATAL

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

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

Примеры событий, которые могут регистрироваться как FATALошибки, включают следующее:

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

Записывая такие серьезные инциденты на уровне FATAL вы обеспечите максимальное внимание к этим инцидентам и их быстрое разрешение ответсвенной стороной. Вот минимальный пример того, как вести журнал на уровне FATAL с помощью фреймворка Pino для приложений Node.js:

const pino = require('pino');

const logger = pino({
  formatters: {
    bindings: (bindings) => {
      return {
        env: process.env.NODE_ENV || 'production',
        server: process.env.server,
      };
    },
    level: (label) => {
      return { level: label };
    },
  },
});

logger.fatal(
  new Error('no space available for write operations'),
  'Disk space critically low'
);
process.exit(1);

{"level":"fatal","time":1685998234741,"env":"production","err":{"type":"Error","message":"no space available for write operations","stack":"Error: no space available for write operations\n    at Object.<anonymous> (/home/ayo/dev/betterstack/demo/nodejs-logging/index.js:21:3)\n    at Module._compile (node:internal/modules/cjs/loader:1254:14)\n    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)\n    at Module.load (node:internal/modules/cjs/loader:1117:32)\n    at Module._load (node:internal/modules/cjs/loader:958:12)\n    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)\n    at node:internal/main/run_main_module:23:47"},"msg":"Disk space critically low"}

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

2. ERROR

Уровень журнала ERRORуказывает на ошибки в приложении, которые препятствуют выполнению определенной операции. Хотя приложение может продолжать работать с пониженным уровнем функциональности или производительности, ERRORв журналах указываются проблемы, которые следует незамедлительно исследовать. В отличие от FATALсообщений, ERRORжурналы не имеют такой срочности, поскольку приложение может продолжать выполнять полезную работу.

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

Некоторые примеры ситуаций, которые обычно регистрируются на уровне ERROR:

Сбои внешнего API или службы, влияющие на функциональность приложения (после неудачных попыток автоматического восстановления).
Ошибки сетевой связи, такие как тайм-ауты подключения или сбои разрешения DNS.
Сбой при создании или обновлении ресурса в системе.
Непредвиденная ошибка, например сбой при декодировании объекта JSON.

В приведенном ниже примере показано, как вы можете записать состояние ошибки в своем приложении. Он использует фреймворк Zap для Go :

func main() {
    logger := zap.Must(zap.NewProduction())

    defer logger.Sync()

    err := someThingThatCanFail()
    if err != nil {
        logger.Error(
            "an error occurred while doing something that can fail",
            zap.Error(err),
        )
    }
}

{"level":"error","ts":1686002351.601908,"caller":"slog/main.go:20","msg":"an error occurred while doing something that can fail","error":"Unhandled exception: division by zero","stacktrace":"main.main\n\t/home/ayo/dev/demo/slog/main.go:20\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

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

3. WARN

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

Некоторые примеры событий, которые могут быть зарегистрированы на WARNуровне, включают следующее:

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

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

Вот пример журнала предупреждений, созданного с использованием модуля ведения журнала Python в сочетании с python-json-logger :

import logging
from pythonjsonlogger import jsonlogger

logHandler = logging.StreamHandler()
jsonHandler = logHandler.setFormatter(
    jsonlogger.JsonFormatter(
        "%(name)s %(asctime)s %(levelname)s %(filename)s %(lineno)s %(message)s",
        rename_fields={"levelname": "level", "asctime": "timestamp"},
    )
)
logger = logging.getLogger(__name__)
logger.addHandler(logHandler)

logger.warning("Disk usage warning", extra={"disk_usage": 85.2, "threshold": 80})

{"name": "__main__", "filename": "main.py", "lineno": 38, "message": "Disk usage warning", "disk_usage": 85.2, "threshold": 80, "level": "WARNING", "timestamp": "2023-06-07 12:48:35,251"}

4. INFO

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

Некоторые события, которые обычно регистрируются на уровне INFO, включают следующее:

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

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

Вот пример того, как вести журнал на уровне INFO, используя структуру Semantic Logger для программ Ruby:

require 'semantic_logger'

SemanticLogger.add_appender(io: $stdout, formatter: :json)

logger = SemanticLogger['MyApp']

logger.info('API request to /api/v1/users completed successfully',
            method: 'GET', status_code: 200, elapsed_ms: 212, endpoint: '/api/v1/users')

{"host":"fedora","application":"Semantic Logger","timestamp":"2023-06-05T22:59:17.869874Z","level":"info","level_index":2,"pid":3824579,"thread":"60","name":"MyApp","message":"API request to /api/v1/users completed successfully","payload":{"method":"GET","status_code":200,"elapsed_ms":212,"endpoint":"/api/v1/users"}}

5. DEBUG

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

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

Некоторые повседневные события, которые обычно регистрируются на уровне DEBUG, включают следующее:

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

Вот пример того, как писать DEBUGжурналы:

logger.debug(
  {
    query: 'SELECT * FROM users WHERE age >= 18',
    time_taken_ms: 2.57,
  },
  'Select 18+ users from the database'
);

Когда DEBUGведение журнала включено ( см. ниже ), вы увидите следующий вывод:

{"level":"debug","time":1686043946948,"env":"production","query":"SELECT * FROM users WHERE age >= 18","time_taken_ms":2.57,"msg":"Select 18+ users from the database"}

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

6. TRACE

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

Конкретные примеры событий, которые должны регистрироваться на уровне TRACE, включают следующее:

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

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

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

Вот пример, который использует фреймворк Zerolog для Go для создания журналов TRACE внутри функции, которая выполняет некоторые вычисления:

package main

import (
    logger "github.com/rs/zerolog/log"
)

func complexCalculation(input int) int {
    logger.Trace().Msg("Entering complexCalculation() function")

    logger.Trace().Int("input", input).Msgf("Received input: %d", input)

    // step 1
    result := input * 2

    logger.Trace().
        Int("step1-result", result).
        Msg("Intermediate value after step 1")

    // step 2
    result += 10

    logger.Trace().
        Int("step2-result", result).
        Msg("Intermediate value after step 2")

    // final result
    result *= 3

    logger.Trace().
        Int("final-result", result).
        Msgf("Final result is: %d", result)

    logger.Trace().Msg("Exiting complexCalculation() function")

    return result
}

func main() {
    result := complexCalculation(5)

    logger.Info().Int("result", result).Msg("Calculation completed")
}

{"level":"trace","time":"2023-06-06T11:01:55+01:00","message":"Entering complexCalculation() function"}
{"level":"trace","input":5,"time":"2023-06-06T11:01:55+01:00","message":"Received input: 5"}
{"level":"trace","step1-result":10,"time":"2023-06-06T11:01:55+01:00","message":"Intermediate value after step 1"}
{"level":"trace","step2-result":20,"time":"2023-06-06T11:01:55+01:00","message":"Intermediate value after step 2"}
{"level":"trace","final-result":60,"time":"2023-06-06T11:01:55+01:00","message":"Final result is: 60"}
{"level":"trace","time":"2023-06-06T11:01:55+01:00","message":"Exiting complexCalculation() function"}
{"level":"info","result":60,"time":"2023-06-06T11:01:55+01:00","message":"Calculation completed"}

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

Управление объемом журнала приложения

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

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

После того, как вы выберете уровень по умолчанию, все записи журнала с серьезностью ниже значения по умолчанию будут исключены. Например, в производственных средах обычно по умолчанию устанавливается уровень INFO, захватывая только сообщения INFO уровня или выше ( WARN, ERROR, и FATAL). Если вы хотите сосредоточиться исключительно на индикаторах проблем, вы можете установить уровень по умолчанию WARN:

func main() {
    // this logger is set to the INFO level
    logger := zerolog.New(os.Stdout).
        Level(zerolog.InfoLevel).
        With().
        Timestamp().
        Logger()

    logger.Trace().Msg("Trace message")
    logger.Debug().Msg("Debug message")
    logger.Info().Msg("Info message")
    logger.Warn().Msg("Warn message")
    logger.Warn().Msg("Error message")
    logger.Fatal().Msg("Fatal message")
}

Обратите внимание, что журналы DEBUGи INFOздесь отсутствуют:

{"level":"info","time":"2023-06-06T11:54:28+01:00","message":"Info message"}
{"level":"warn","time":"2023-06-06T11:54:28+01:00","message":"Warn message"}
{"level":"warn","time":"2023-06-06T11:54:28+01:00","message":"Error message"}
{"level":"fatal","time":"2023-06-06T11:54:28+01:00","message":"Fatal message"}

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

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

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

// set the log level from the environment
logLevel, err := zerolog.ParseLevel(os.Getenv("APP_LOG_LEVEL"))
if err != nil {
    // default to INFO if log level is not set in the environment
    logLevel = zerolog.InfoLevel
}

logger := zerolog.New(os.Stdout).
    Level(logLevel).
    With().
    Timestamp().
    Logger()

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

Создание и использование собственных уровней

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

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

const pino = require('pino');

const levels = {
  fatal: 60,
  error: 50,
  warn: 40,
  security: 35,
  info: 30,
  debug: 20,
  trace: 10,
};

const logger = pino({
  level: 'debug',
  customLevels: levels,
  useOnlyCustomLevels: true,
  formatters: {
    bindings: (bindings) => {
      return {
        env: process.env.NODE_ENV || 'production',
        server: process.env.server,
      };
    },
    level: (label) => {
      return { level: label };
    },
  },
});

logger.security('A notable security event');

{"level":"security","time":1686051401495,"env":"production","msg":"A notable security event"}

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

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

Как использовать уровни журналов для мониторинга и анализа

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

1. Фильтрация и поиск

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

2. Оповещение

Уровни журнала могут активировать механизмы оповещения и уведомления для упреждающего реагирования на критические события. Вы можете получать немедленные уведомления об этих событиях, настроив оповещения на основе определенных уровней журнала, таких как FATALили ERROR. В приведенном ниже примере отправляется предупреждение на настроенные адреса электронной почты, когда в течение 30-секундного периода регистрируется более пяти записей ERROR, что указывает на то, что они могут быть постоянной проблемой, требующей внимания.

3. Расчет различных показателей (metrics)

Уровни журналов также являются полезным инструментом для создания различных метрик о приложении, особенно при отсутствии специализированных инструментов, таких как Prometheus . Например, значительное увеличение количества журналов ERROR или FATAL может указывать на важные проблемы или ошибки, требующие немедленного внимания. Эта информация может помочь вам расставить приоритеты по отладке или спланировать специальный «спринт по устранению ошибок» для устранения выявленных проблем.

Заключительные мысли

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

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

Спасибо за прочтение и удачной регистрации!

Источник: https://betterstack.com/community/guides/logging/log-levels-explained/