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

Проблема

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

Итак, если служебный класс называется InternalLogger, журнал будет выглядеть примерно так:

2024-10-11T18:10:57,345 [finagle/netty4-6] (InternalLogger.java:34) INFO ...  

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

Решение

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

К счастью, в этом ответе StackOverflow я обнаружил, что SLF4J предоставляет интерфейс под названием LocationAwareLogger, который поддерживает Log4J2, поэтому мы можем фильтровать служебный класс, просто передавая FQCN (полное имя класса) класса утилиты журнала.

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

public class InternalLogger {

  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);

  public void log(EventLog eventLog) {
    //... get message and logLevel from eventLog
    switch (logLevel) {
      case DEBUG:
        LOG.debug(message);
        break;
      case WARN:
        LOG.warn(message);

Для этого решения я объявил класс Logger FQCN и добавил частную вспомогательную функцию для регистрации с помощью LocationAwareLogger:

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();

  private void locationAwareLog(int level, String message) {
    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);
  }

И изменил свой старый код, чтобы он вызывал его, если он поддерживается:

switch (logLevel) {
  case DEBUG:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);
    } else {
      LOG.debug(message);
    }
    break;
  case WARN:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.WARN_INT, message);
    } else {
      LOG.warn(message);
    }
//...

К сожалению, SLF4J не предоставляет возможности указать уровень в качестве аргумента (т. е. LOG.log(level, message)). Если бы это было так, код был бы менее подробным.

После реализации этого изменения журналы теперь точно сообщают номер линии вызывающего абонента, что значительно улучшает отслеживаемость:

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

Обратите внимание на разницу: InternalLogger.java:34 и ActualLogic.java:1059, что указывает на более точное расположение источника журнала в коде приложения.

Заключение

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

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

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