빠르게 진행되는 현대 소프트웨어 개발 환경에서 효율적인 디버깅 및 시스템 모니터링을 위해서는 효과적인 로깅이 매우 중요합니다. 그러나 로그 출력의 줄 번호가 일관되지 않거나 부정확하면 문제 해결에 시간이 많이 걸릴 수 있습니다. 최근에 저는 내부 로깅 유틸리티가 자신을 로그 소스로 보고하고 있음을 확인했습니다. 로그 정밀도를 높이기 위해 이 문제를 해결해야 했습니다.

문제

로그를 처리하기 위해 사용자 정의 유틸리티 클래스를 사용하면 유틸리티 클래스가 최종적으로 실제 로그 프레임워크를 호출하는 클래스이므로 자체적으로 로그 소스로 보고되기 시작합니다(제 경우에는 SLF4J였습니다). , Log4J2를 백엔드로 사용).

따라서 유틸리티 클래스를 InternalLogger라고 하면 로그는 다음과 같습니다.

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

여기서 보고된 소스 파일과 줄 번호는 실제로 애플리케이션 코드에서 로그 호출이 이루어진 위치가 아니라 로깅 유틸리티 자체 내의 위치를 ​​가리킵니다. 이 동작은 문제를 신속하게 디버깅하고 찾아낼 때 로그의 효율성을 완화합니다.

해결책

먼저 줄 번호를 보고하기 전에 수동으로 스택 추적을 살펴보고 일부 요소를 필터링하는 방법을 생각했습니다. 이 접근 방식은 비용이 매우 많이 들기 때문에 로깅 프로세스를 늦추고 싶지 않았습니다.

운 좋게도 이 StackOverflow 답변에서 SLF4J가 Log4J2가 지원하는 LocationAwareLogger라는 인터페이스를 제공하므로 간단히 로그 유틸리티 클래스의 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(레벨, 메시지))을 제공하지 않습니다. 만약 그렇다면 코드는 좀 덜 장황해질 것입니다.

이 변경 사항을 구현한 후 이제 로그에 발신자의 회선 번호가 정확하게 보고되어 추적성이 크게 향상되었습니다.

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

차이점을 확인하세요. InternalLogger.java:34와 ActualLogic.java:1059는 애플리케이션 코드 내 로그 원본의 보다 정확한 위치를 나타냅니다.

결론

SLF4J의 LocationAwareLogger를 통합함으로써 우리의 로깅 시스템을 혼란의 근원에서 정확한 진단 도구로 전환했습니다. 이번 변경을 통해 로깅 유틸리티 대신 발신자의 회선 번호를 정확하게 보고할 수 있어 문제를 신속하고 정확하게 진단하는 능력이 크게 향상되었습니다.

이 개선 사항은 디버깅을 간소화할 뿐만 아니라 소프트웨어 문제를 해결할 때 응답 시간도 단축합니다.

비슷한 문제에 직면한 개발자는 로깅 시스템의 효율성을 높이기 위해 이 접근 방식을 고려해야 합니다. 더 명확하고 정확한 로그를 통해 한때 모호했던 데이터를 실행 가능한 통찰력으로 전환하여 운영 효율성과 소프트웨어 안정성을 모두 향상시킬 수 있습니다. 최적화된 로깅은 오늘날 빠르게 변화하는 개발 환경의 과제를 해결하고 고품질 소프트웨어 결과를 보장하는 데 중요합니다.