Java 로그 유틸리티 클래스가 자신을 로그 소스로 보고하고 있습니까? 문제를 해결하는 방법을 알아보세요!

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

문제

로그를 처리하기 위해 사용자 정의 유틸리티 클래스를 사용할 때 유틸리티 클래스는 최종적으로 실제 로그 프레임워크를 호출하는 클래스이기 때문에 자체적으로 로그 소스로 보고되기 시작합니다(제 경우에는 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를 통합하여 혼란의 원인이었던 로깅 시스템을 정확한 진단 도구로 전환했습니다. 이번 변경을 통해 로깅 유틸리티 대신 발신자의 회선 번호를 정확하게 보고할 수 있어 문제를 신속하고 정확하게 진단하는 능력이 크게 향상되었습니다.

이러한 개선으로 디버깅이 간소화될 뿐만 아니라 소프트웨어 문제를 해결할 때 응답 시간도 단축됩니다.

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

위 내용은 Java 로그 유틸리티 클래스가 자신을 로그 소스로 보고하고 있습니까? 문제를 해결하는 방법을 알아보세요!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!