Правила и советы по ведению журнала?

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

Мы используем Java, но вы можете в целом прокомментировать логин - правила и советы

1. Используйте правильный уровень регистрации

   • ОШИБКА: что-то пошло не так и нужно немедленно исправить
   • ВНИМАНИЕ: Процесс может продолжаться без исправления. Приложение должно терпеть этот уровень, но предупреждение всегда должно быть расследовано.
   • ИНФОРМАЦИЯ: Информация о том, что важный процесс завершен
   • DEBUG. Используется только во время разработки

2. Убедитесь, что вы знаете, что вы регистрируете.

3. Избегайте, чтобы регистрация влияла на поведение приложения

Функция ведения журнала должна заключаться в записи сообщений в журнал.

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

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

1. Поместите правильные свойства в log4j

Поместите в это правильный метод, и класс написан автоматически.

Пример:

Datedfile -web

log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG

log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n

log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/

1. Значение журнала.

Пожалуйста, зарегистрируйте значения из приложения.

1. Префикс журнала.

Укажите, из какой части приложения ведется запись, предпочтительно с указанием префикса, согласованного с проектом, например PANDORA_DB

1. Количество текста.

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

1. Формат регистрации:

Есть несколько вариантов и методов для использования с log4j, но мы бы хотели единообразного использования следующего формата, когда мы регистрируем в исключениях:

logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);

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

Всегда используйте регистратор, а не следующее:

System.out.println(), System.err.println(), e.printStackTrace()

Если веб-приложение использует нашу инфраструктуру, вы можете получить очень подробную информацию об ошибках из EJB, если используете try-catch в обработчике и ведение журнала в соответствии с приведенной выше моделью:

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

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

И в приведенных выше примерах метод и класс будут записаны. В строке номера консоли также будет написано наше.

1. toString()

Пожалуйста, есть toString()для каждого объекта. EX:

@Override
public String toString() {
  StringBuilder sb = new StringBuilder();
  sb.append(" DwfInformation [ ");
  sb.append("cc: ").append(cc);
  sb.append("pn: ").append(pn);
  sb.append("kc: ").append(kc);
  sb.append("numberOfPages: ").append(numberOfPages);
  sb.append("publicationDate: ").append(publicationDate);
  sb.append("version: ").append(version);
  sb.append(" ]");
  return sb.toString();
}

вместо специального метода, который делает эти выводы

public void printAll()
{
    logger.info("inbet: " + getInbetInput());
    logger.info("betdat: " + betdat);
    logger.info("betid: " + betid);
    logger.info("send: " + send);
    logger.info("appr: " + appr);
    logger.info("rereg: " + rereg);   
    logger.info("NY: " + ny);   
    logger.info("CNT: " + cnt);   
}

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

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

Я привык видеть слой ниже отладки, который я называю «Трассировка», но это не обязательно универсальный термин. Регистрация уровня трассировки отслеживает столько, сколько вы можете выдержать, включая вход / выход модуля, временные метки с входом / выходом и бонусные баллы за захват пройденных значений. Очевидно, что это генерирует МНОГО данных, и это не то, что вы включаете волей-неволей. Но он имеет преимущества в отношении отладки, когда вы не можете подключиться к процессу или у вас нет дампов ядра ошибочного приложения.

Мне нравится видеть ссылки на файлы / модули и временные метки с информацией из моего журнала. Это может быть удобно при поиске условий гонки между потоками, а также при координации действий нескольких областей приложения. Честно говоря, я знаю некоторых людей, которые думают, что эти детали загромождают файл журнала. Добавление в метку времени - это то, что нужно обсудить с командой. (Извинения, если log4j уже делает это.)

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

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

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

Кстати, у проекта Apache Commons есть ToStringBuilder класс, который упрощает создание ваших toString()методов.

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

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Я думаю, что этот вид условной трассировки или отладки - не лучший способ.

Помимо регистрации класса / метода, вызвавшего ошибку, было бы полезно также зарегистрировать параметры, переданные в этот метод. Знание, где возникла ошибка, не очень полезно, если это происходит только 1 раз из 1000; Вы также должны знать, какие данные вызвали ошибку.

Я также нашел полезным иметь переменную, которая определяет уровень ведения журнала по умолчанию для приложения. Таким образом, вы можете иметь код DEBUG и INFO вместе с кодом WARNING и ERROR. При работе в производственном режиме вы по умолчанию не выводите информацию DEBUG, но когда появляется ошибка, вы можете обновить флаг и начать записывать сообщения DEBUG в журнал.

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

Чтобы избежать этой и других проблем при смешивании журналов и «реальной» бизнес-логики, следует рассмотреть возможность использования аспектно-ориентированного программирования. Для Java наиболее используемой платформой будет AspectJ. Это видео на YouTube от Google Tech Talks объясняет, как AspectJ и его использование выходят за рамки регистрации. Конечно, вы также найдете много примеров для входа в систему здесь на stackexchange .

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