Skip to main content

5 уровней ведения журнала

  • Эта публикация - перевод статьи. Ее автор - Orhan 'aib' Kavrakoglu. Оригинал доступен по ссылке ниже:

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

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

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

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

Ошибка

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

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

Стиль: что-то, что привлекает внимание. Я использую красный текст (на моем черном фоне терминала).

Примеры:

  • Не удается найти файл "ital.dat"
  • Ошибка обработки данных: <Exception> [трассировка стека здесь или как последующее сообщение отладки]
  • <Exception> при подключении к базе данных

Предупреждение

Возможно, произошла ошибка. Я, просто сообщение журнала, не могу проанализировать ситуацию. Люди, вероятно, должны посмотреть на это.

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

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

Примеры:

  • Соединение закрыто, переподключение через 2 секунд
  • Невозможно найти «logging.conf» [указанный в файле конфигурации], возвращаясь к конфигурации по умолчанию
  • Тайм-аут попытки подключения через 30 секунд
  • Получил FileVersionTooOldException, возвращаясь к Version12Parser

Информация

Пользователь информируется об операции или изменении статуса. Сохраняйте спокойствие и продолжайте.

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

Стиль: что-то, что выделяется из уровней ниже. Я использую белый текст.

Примеры:

  • Агент инициализирован
  • Загрузка сохранить "yeti02"
  • Ввод скорости варпа
  • Текущий каталог "/ tmp"
  • Uplink установлен
  • Отрисовка завершена, заняло 42,999

Отладка

Если вы можете прочитать это, вы стоите слишком близко к программе.

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

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

Стиль: что-то, что легко игнорировать. Я использую светло-серый / бежевый текст, цвет текста моего терминала по умолчанию.

Примеры:

  • Чтение конфигурации из "/etc/octarine/octarine.conf"
  • Переопределение конфигурации с помощью "/home/aib/.octarinerc"
  • Анализ завершен, построение графика ...
  • Подключение к серверу: 4242 как «пользователь»
  • Отправка 2 сообщений
  • Отображение разбивки по времени:
  • Foo 0.990s
  • Bar 42.009 с

След

Вот некоторые технические детали, которые не имеют отношения к делу, если только вы не искали их.

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

Сообщения трассировки будут в основном содержать информацию, о которой вы уже можете догадаться («Debug говорит« вход в систему », так что это пакет входа в систему»), и, как таковая, возможно, не окажет особой помощи, если не делать ошибочных предположений. («Подождите, это выход из системы ?!», «Хм, здесь fooнужно позвонить. Почему тогда не fooпечатается« Трассировка »?»)

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

Примеры:

  • Вызов функции «foo» с параметрами («baz», «bar», 42)
  • ->GET / HTTP/1.1\nHost: localhost\n\n
  • Получил: <?xml version="1.0" encoding="UTF-8" ?>\n<ohboy>\n[...]

Фатальный

Произошла ошибка - нет, извините, произошла фатальная ошибка. Мы уходим сейчас. Удачи!

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

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

Примеры:

  • Недостаточно памяти
  • Невозможно выделить 65536 байт дискового пространства.
  • Срок действия лицензии истек, перейдите на бесплатное программное обеспечение

Внешние примеры

Любой уважающий себя API журналирования или библиотека должны иметь встроенные уровни (и, вероятно, поддержку пользовательских). Вот некоторые широко используемые для справки: