TRACE 레벨이 존재하는 이유는 무엇이며 DEBUG 대신 언제 사용해야합니까?

Java의 Log4J, Slf4J 및 몇 가지 다른 로깅 프레임 워크에는 두 가지 "개발자"레벨의 로깅이 있습니다.

• 디버그
• 자취

설명이 명확하기 때문에 DEBUG의 기능을 이해합니다.

DEBUG 수준은 응용 프로그램을 디버깅하는 데 가장 유용한 세분화 된 정보 이벤트를 지정합니다.

그러나 TRACE 레벨은 유스 케이스에 대해 구체적이지 않습니다.

TRACE 레벨은 DEBUG보다 세분화 된 정보 이벤트를 지정합니다.

(출처 : log4J JavaDoc )

TRACE를 언제 어떻게 사용하는지 알려주지 않습니다. 흥미롭게도 이것은 syslog standard에 정의 된 심각도 수준이 아닙니다 . TRACE와 DEBUG의 차이점에 대한 인터넷 검색은 "DEBUG를 사용하십시오. 아, TRACE도 있습니다". TRACE 수준에 대한 특정 사용 사례를 찾을 수 없습니다. 내가 찾은 최고 는 레벨의 존재에 대한 장점을 토론하는 이 오래된 위키 페이지 였습니다 .

이것은 건축가로서 내 머리 속에 많은 깃발과 질문을 제기합니다. 젊은 개발자가 내 아키텍처에 TRACE를 추가하도록 요청한 경우 다음과 같이 질문을합니다.

• DEBUG가 아닌 TRACE로 기록해야하는 정보의 예는 무엇입니까?
• 해당 정보를 기록하여 어떤 특정 문제를 해결합니까?
• 이 예 에서 DEBUG 레벨이 아닌 TRACE 레벨에서의 로깅 을 명확히 구분 하는 로깅 된 정보의 특성은 무엇 입니까?
• 해당 정보가 로그 인프라를 통과해야하는 이유는 무엇입니까?
  • 해당 정보를 단순히 사용하는 것이 아니라 로그 저널에 유지하면 어떤 이점이 System.out.println있습니까?
  • 디버거보다는 로그를 사용하는 것이 더 좋은 이유는 무엇입니까?
• TRACE 레벨에서 로깅의 표준 예는 무엇입니까?
  • 예제에서 DEBUG 대신 TRACE 레벨에서 로깅하여 얻은 특정 이점은 무엇입니까?
  • 그 이익이 왜 중요한가?
  • 반대로 : DEBUG 대신 TRACE에 로깅하면 어떤 문제를 피할 수 있습니까?
  • 다른 문제를 어떻게 해결할 수 있습니까? TRACE 수준에서 로깅하는 것이 다른 솔루션보다 나은 이유는 무엇입니까?
• 프로덕션 레벨에 TRACE 레벨 로그 명령문이 남아 있어야합니까? 왜?

그러나 대부분의 주요 프레임 워크에 존재한다고 가정하면 뭔가 유용하다고 생각합니다. 그렇다면 ... TRACE는 무엇이며 DEBUG와 다른 점은 무엇입니까?

DEBUG가 아닌 TRACE로 기록해야하는 정보의 예는 무엇입니까?

여러 단계를 거치는 알고리즘이있는 경우 추적 수준은 각 단계에 대한 정보를 가장 높은 수준으로 인쇄합니다. 모든 단계의 리터럴 입력 및 출력과 같은 것.

일반적으로 추적에는 모든 디버그가 포함됩니다 (디버그에 모든 경고 및 오류가 포함되는 것처럼).

해당 정보를 기록하여 어떤 특정 문제를 해결합니까?

특정 항목을 대상으로하고 오류나 기타 로깅 정보를 신경 쓰지 않을 때 특정 빌드 외부에 로그하기에는 너무 많은 데이터를 출력 하는 무언가를 디버깅해야합니다 (트레이스 정보의 양이 모호하기 때문에). 일부 로거에서는 특정 모듈을 추적 레벨로만 설정합니다.

이 예에서 DEBUG 레벨이 아닌 TRACE 레벨에서의 로깅을 명확히 구분하는 로깅 된 정보의 특성은 무엇입니까?

일반적으로 추적 레벨 로깅은 응용 프로그램의 성능을 크게 저하 시키거나 디스크 / 대역폭 제한으로 인해 지속 불가능한 많은 로그 데이터를 작성하기 때문에 지속 기간 동안 지속될 수 없습니다.

앱을 사용할 수 없게 만들지 않고 디버그 수준 로깅을 일반적으로 더 오랜 기간 동안 사용할 수 있습니다.

해당 정보가 로그 인프라를 통과해야하는 이유는 무엇입니까?

필요하지 않습니다. 일부 프레임 워크에는 별도의 추적 프로그램이 있습니다.

추적 로그 작성기 및 일반 로그 작성기는 디스크 / 네트워크에 쓰기, 오류 처리, 로그 회전 등과 관련하여 유사한 요구가 있기 때문에 일반적으로 로그에 기록됩니다.

디버거보다는 로그를 사용하는 것이 더 좋은 이유는 무엇입니까?

디버거가 문제 머신에 연결하지 못할 수 있기 때문입니다. 중단 점을 설정하거나 코드를 단계별로 수행 할 위치를 알기에 충분하지 않을 수 있습니다. 디버거에서 오류를 안정적으로 재현하지 못할 수 있으므로 로그를 사용하여 "발생하는 경우"를 파악하십시오.

그러나 그들은 단지 이름 일뿐입니다. 다른 레이블과 마찬가지로 사람들이 물건에 넣는 이름을 짓는 것이며 보통 사람들마다 다른 것을 의미합니다. 그리고 레이블 자체는 레이블이 참조하는 비트보다 중요하지 않습니다.

slf4j는 특히 추적 사용을 권장하지 않습니다 ( http://slf4j.org/faq.html#trace ).

요컨대, 대안이 존재하거나 많은 경우 TRACE 레벨의 로그 요청이 낭비되어 많은 사람들이 TRACE 레벨의 사용을 권장하지 않지만 사람들이 계속 요구하기 때문에 대중의 요구에 부응하기로 결정했습니다.

개인적으로, 추적은 모든 것을 기록 할 것으로 예상됩니다 (예를 들어, "시간 Y에 인수 A, B, C가있는 함수 MyFunc와 같은 것"). 이것의 단점은 이것이 엄청나게 시끄러울뿐만 아니라 디스크 공간 문제를 일으키는 경향이 있다는 것입니다. 정상적인 작업 중에는 이러한 로깅이 비활성화 될 것으로 예상됩니다. 거꾸로 이것은 디버거를 연결하는 것이 실용적이지 않은 경우 프로그램을 단계별로 실행할 때 얻는 것과 비슷한 수준의 정보를 제공한다는 것입니다.

일반적으로 추적은 다른 접근 방식보다 더 많은 노력이 필요하다는 것을 알았습니다.

일반적으로 디버그 수준은 전적으로 임의적이며 언어, 라이브러리 및 회사마다 다를 수 있습니다.

즉, 여기에 내가 사용한 것을 보았습니다.

TRACE : 로직 레벨 프로그램 흐름을 표시하는 데 사용됩니다. 기능을 입력 했습니까? "if"문이 메인 또는 "else"분기를 선택 했습니까? 그것은 추적의 후보입니다. 다시 말해, 추적 로깅은 일반적으로 "현재 위치"를 지정하는 데 사용됩니다. 이는 오류 또는 기타 정보를 기록 할 수있는 다른 로깅 명령문의 컨텍스트에서 유용합니다. 추적 로깅은 코드에서 오류 또는 다른 수준에서 로깅 된 기타 이벤트의 위치를 ​​정확히 파악하는 데 도움이 될 수 있습니다.

DEBUG : 변수 상태, 특정 오류 코드 등을 덤프하는 데 사용됩니다. 예를 들어, 웹 서비스는 오류 코드 809214를 반환 할 수 있습니다.이 코드는 응용 프로그램이 사용자에게 "통신 실패"를 알려주는 동안 기록 될 수 있습니다. 오류가 발생한 후 오랫동안 개발자가 사용자 시스템에서 로그를 수신하고 " 실패 가 발생한 이유 "가 궁금하다고 상상해보십시오. 디버그 수준에서 로그하는 것이 좋습니다. 또 다른 예는 버그가 프로덕션 환경에서 계속 발생하지만 재현하기 어려운 경우 문제가있는 모듈에서 특정 변수 또는 이벤트를 디버그하여 문제 해결에 도움이되는 오류가 발생했을 때 개발자에게 프로그램 상태를 알려주는 데 도움이됩니다.

일반적으로 지정된 수준 (또는 그 이상)에서 로그하도록 응용 프로그램을 구성합니다. 예를 들어, 추적이 가장 낮은 수준 인 경우가 많습니다. 해당 수준에서 로깅하면 모든 것이 기록됩니다. 디버그 수준은 추적을 생략하지만 높은 수준 (예 : 경고 및 오류)을 포함합니다.

로그 레벨 분리의 이점은 로그 된 양을 제어하는 ​​것입니다. 복잡한 응용 프로그램의 경우 추적 로깅으로 인해 엄청난 양의 데이터가 기록 될 수 있으며 대부분의 시간이 거의 쓸모가 없습니다. 버그를 일으키는 방법을 알아 내려고 하지 않는 한 중요한 정보 (일부 시작 정보, 오류 만)를 기록하는 것이 가장 좋습니다 . 또한 이는 일반적으로 디버거 및 기타 개발 도구가없는 프로덕션 환경에서만 유용합니다.

이에 대한 실제 제한은 없으며 특정 방식으로 로그인해야한다는 규칙도 없습니다. 일부 라이브러리 또는 응용 프로그램이 따르거나 따르지 않을 수있는 광범위한 규칙 만 있습니다.

내 생각 Telastyn의 훌륭한 대답은 엄지 손가락의 내 짧은 규칙에 요약 될 수있다 :

• DEBUG 로깅은 프로덕션 환경에서 사용할 수 있어야하지만 여전히 정상적으로 꺼져있는 경향이 있습니다.
• TRACE 프로덕션에서 (특정 / 짧은 세션이 아닌) 로깅을 사용할 수 없도록 로깅이 허용됩니다.

여기 내 엄지 법칙이 있습니다

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

이에 대한 가정은 운영팀이

• 항상 생산 수준을 로그 수준 정보로 설정
• 프로덕션이 로그 레벨 디버그로 설정되었을 수 있습니다.
• 로그 레벨 추적으로 프로덕션을 설정하지 마십시오.

이러한 가정을 바탕으로 개발자가 로그 수준을 사용하는 방법은 다음과 같습니다.

문제 # 1) 생산 성능이 너무 느려지지 않음

debug# 1을 해결합니다. 소음을 너무 많이 내지 않으면 서 장비 속도를 늦추지 않고 프로덕션에서 필요할 수있는 정보의 균형을 맞추기 위해 최선을 다하는 것은 개발자입니다. "원하는 경우이를 프로덕션에 지속적으로 기록하는 것이 좋습니다."

문제 # 2) 개발 중 자세한 정보가있는 경우

trace문제 # 2를 해결합니다. 프로덕션 머신에 어떤 영향을 미치는지 전혀 걱정하지 않지만 코드를 개발하는 동안 해당 정보가 필요합니다. "이 정보를 항상 프로덕션에 기록하는 것은 좋은 생각이 아닙니다."

물론 (다른 사람들이 말했듯이) 이러한 것들은 임의적입니다. 따라서 개발팀 (및 운영팀 / 모니터링 팀-로깅 사용자이기도 함)이 무언가에 동의하는지 확인하십시오.

TRACE 레벨에서 로깅의 표준 예는 무엇입니까?

메소드의 ENTRY / EXIT 로그 이 로그 는 프로그램의 흐름 을 추적 하는 데 도움 이되며 다음과 같은 경우에 매우 유용합니다.

1. 프로그램이 갑자기 충돌합니다-로그의 마지막 줄을보고 충돌 한 기능을 정확히 알고 있습니다.

2. 예외를 흡수하여 일부 불량 기능이 자동으로 실패

코드베이스의 모든 메소드에 대해 ENTRY / EXIT 로그를 활성화 하면 DEBUG 컨텍스트에서도 항상 켜져 있지 않은 엄청난 양의 추가 로그가 생성되므로 DEBUG를 사용하는 대신 별도의 TRACE 레벨을 보증합니다 .