Руководство о том, почему вы должны вести ведение журнала и как выбрать модуль для ведения журнала.

логирование

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

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

Почему важно вести журнал?

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

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

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

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

Различные способы входа в Nodejs

В nodejs есть несколько модулей, которые можно использовать для ведения журнала, некоторые из них — log4js, Winston, morgan, Bunyan и т. д. Вы можете использовать любой из них, потому что большинство модулей имеют аналогичную функцию, вам просто нужно понять модуль глубоко и реализовать их должным образом.

Я лично использовал log4js и Winston, и в обоих случаях они решили все мои варианты использования.

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

  • Ошибка
  • предупреждать
  • Информация
  • подробный
  • отлаживать

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

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

Что нужно помнить при выборе инструмента для ведения журнала

  • Он должен иметь средство ротации журналов.
    Это означает, что вы хотите хранить журналы за последние 10 дней, тогда выбранный вами модуль должен предоставить вам эту возможность. Хотя эту функциональность можно легко реализовать, запустив cronjob, лучше, если ваш модуль предоставляет ее по умолчанию.
  • У него должна быть функция максимальный размер файла.
    Максимальный размер файла дает вам возможность хранить журналы в фрагментах разных файлов. Это помогает легко отлаживать журналы. Например, если вы знаете, что в определенное время ваше приложение не работало, вы можете просто отладить соответствующий файл журнала.
  • Он должен иметь возможность создавать журналы на основе кода состояния. Это означает, что журнал должен быть разделен на основе кода состояния журнала, например, код состояния 2xx должен быть журналом успеха, и наоборот, 4xx или 5xx должен быть журналом ошибок.

Советы, которым следует следовать при реализации логгера

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

Различные проблемы, возникающие при реализации надлежащего ведения журнала

  • Неправильная ротация журналов i. е. вам не хватает знаний о том, как должна выполняться правильная ротация журналов.
  • Вы не регистрируете нужные вещи, а просто регистрируете ради регистрации. Даже если вы получите терабайт данных, это будет просто мусором для вас, так как вы не сможете извлечь из него ничего полезного.
  • Файл журнала слишком длинный. Так как с файлом в 20гб будет очень сложно обращаться. Уменьшите размер файла, чтобы он был под рукой.
  • Не регистрирует метку времени. Вероятно, это самая большая ошибка, если только вы не сможете записывать время, будет практически невозможно отлаживать журнал в зависимости от времени возникновения проблемы.
  • Не регистрировать важную информацию, которую можно использовать для отладки.
  • Пользовательские данные не отслеживаются, поэтому невозможно понять, откуда запрос.
  • Уровень журнала, то есть ошибка, отладка и т. д., не отслеживаются должным образом.
  • Непонимание того, что нужно регистрировать, является самой большой проблемой.

Последние мысли

  • Возьмите за правило записывать все ключевые моменты.
  • Не регистрируйте важную информацию, такую ​​как данные кредитной карты пользователя.
  • Постарайтесь записывать все, что, по вашему мнению, может быть использовано позже. Очевидно, вы разберетесь с этими вещами, когда столкнетесь с этим, но постарайтесь начать с самого минимума.
  • Выберите некоторые инструменты пользовательского интерфейса, такие как мониторинг, уведомления, которые могут предоставить вам расширенные функции, такие как стек ELK, Grafana и т. д.
  • Никогда не регистрируйте бесполезные вещи, которые очень очевидны, это похоже на комментарий, нет смысла регистрировать то, что не дает вам никакого сообщения.
  • Попробуйте сохранить резервную копию журнала как минимум за 3 дня, вы можете увеличить его в соответствии с вашими требованиями.