[logging] 다른 로그 레벨을 사용하는시기

Program / 글쓴이

치명적인 순서로 메시지를 기록하는 방법에는 여러 가지가 있습니다.

  1. FATAL

  2. ERROR

  3. WARN

  4. INFO

  5. DEBUG

  6. TRACE

언제 사용할 것인지 어떻게 결정합니까?

사용하기에 좋은 휴리스틱이란 무엇입니까?

답변

나는 일반적으로 다음 규칙을 구독합니다.

  • 추적 -코드를 “추적”하고 함수의 한 부분 을 구체적 으로 찾으려고 할 때만 가능 합니다.
  • 디버그 -개발자 (IT, sysadmins 등) 이상의 사람들에게 진 단적으로 유용한 정보입니다.
  • 정보 -일반적으로 유용한 로그 정보 (서비스 시작 / 중지, 구성 가정 등). 정보 항상 사용할 수 있기를 원하지만 일반적으로 정상적인 상황에서는 신경 쓰지 않습니다. 이것이 바로 기본 구성 수준입니다.
  • 경고 -응용 프로그램의 이상을 일으킬 수 있지만 자동으로 복구되는 모든 것. (기본 서버에서 백업 서버로 전환, 작업 재시도, 보조 데이터 누락 등)
  • 오류 – 작업에 치명적 이지만 서비스 나 응용 프로그램에는없는 오류입니다 (필수 파일을 열 수 없거나 데이터가 누락되는 등). 이러한 오류는 사용자 (관리자 또는 직접 사용자)의 개입을 강요합니다. 이들은 일반적으로 잘못된 연결 문자열, 누락 된 서비스 등을 위해 (내 앱에서) 예약되어 있습니다.
  • 치명적 -데이터 손실 (또는 추가 데이터 손실)을 방지하기 위해 서비스 또는 응용 프로그램을 강제 종료시키는 오류입니다. 나는 데이터 손상이나 손실이 보장 된 가장 심각한 오류 및 상황에 대해서만이를 예약합니다.

답변

한밤중에 시스템 관리자에게 메시지가 표시되도록 하시겠습니까?

  • 예-> 오류
  • 아니오-> 경고

답변

로그 파일을 보는 관점에서 심각도에 대해 생각하는 것이 더 도움이됩니다.

치명적 / 중요 : 즉시 조사해야하는 전체 응용 프로그램 또는 시스템 오류. 예, SysAdmin을 깨 웁니다. 우리는 SysAdmins 경고를 선호하고 잘 정돈되어 있으므로이 심각도는 매우 드물게 사용해야합니다. 그것이 매일 일어나고 BFD가 아니라면, 그것은 의미를 잃어 버렸습니다. 일반적으로 치명적 오류는 프로세스 수명 동안 한 번만 발생하므로 로그 파일이 프로세스에 연결되어 있으면 일반적으로 로그의 마지막 메시지입니다.

오류 : 확실히 조사해야 할 문제입니다. SysAdmin에 자동으로 알려야하지만 침대에서 끌어 올 필요는 없습니다. 오류를 확인하기 위해 로그를 필터링하면 오류 빈도에 대한 개요를 얻을 수 있으며 일련의 추가 오류가 발생할 수있는 초기 오류를 신속하게 식별 할 수 있습니다. 응용 프로그램 사용과 비교하여 오류율을 추적하면 전체 품질을 평가하는 데 사용할 수있는 MTBF와 같은 유용한 품질 메트릭을 얻을 수 있습니다. 예를 들어이 메트릭은 릴리스 전에 다른 베타 테스트주기가 필요한지 여부를 결정하는 데 도움이 될 수 있습니다.

경고 : 이것은 문제가 될 수도 있고 아닐 수도 있습니다. 예를 들어 네트워크의 짧은 손실 또는 데이터베이스 연결과 같은 예상되는 일시적인 환경 조건은 오류가 아니라 경고로 기록되어야합니다. 경고 및 오류 만 표시하도록 필터링 된 로그를 보면 후속 오류의 근본 원인에 대한 초기 힌트를 신속하게 파악할 수 있습니다. 의미가 없어지지 않도록 경고를 드물게 사용해야합니다. 예를 들어, 네트워크 액세스 손실은 서버 응용 프로그램에서 경고 또는 오류 여야하지만 간혹 연결이 끊긴 랩톱 사용자를 위해 설계된 데스크톱 응용 프로그램의 정보 일 수 있습니다.

정보 : 성공적인 초기화, 서비스 시작 및 중지 또는 중요한 트랜잭션 완료와 같은 정상적인 조건에서 기록해야하는 중요한 정보입니다. 정보 이상을 표시하는 로그를 보면 발생하는 모든 경고 또는 오류를 이해하기위한 최상위 컨텍스트를 제공하는 프로세스의 주요 상태 변경에 대한 빠른 개요를 제공해야합니다. 정보 메시지가 너무 많지 않습니다. 추적과 관련하여 일반적으로 <5 % 정보 메시지가 있습니다.

추적 : 추적은 가장 일반적으로 사용되는 심각도이며 오류 및 경고로 이어지는 단계를 이해하기위한 컨텍스트를 제공해야합니다. 추적 메시지의 올바른 밀도를 가지면 소프트웨어를 유지 관리하기가 훨씬 쉬워 지지만 프로그램이 발전함에 따라 개별 Trace 문의 값이 시간이 지남에 따라 변경 될 수 있으므로 약간의주의가 필요합니다. 이를 달성하는 가장 좋은 방법은 개발자 팀이 고객이보고 한 문제를 해결하는 표준 부분으로 정기적으로 로그를 검토하는 습관을 갖도록하는 것입니다. 더 이상 유용한 컨텍스트를 제공하지 않는 추적 메시지를 제거하고 후속 메시지의 컨텍스트를 이해하는 데 필요한 메시지를 추가하도록 팀에 권장하십시오. 예를 들어, 디스플레이 또는 탭 변경과 같은 사용자 입력을 로그하는 것이 종종 도움이됩니다.

디버그 : 디버그 <트레이스를 고려합니다. 차이점은 디버그 메시지가 릴리스 빌드에서 컴파일된다는 것입니다. 즉, 디버그 메시지 사용을 권장하지 않습니다. 디버그 메시지를 허용하면 점점 더 많은 디버그 메시지가 추가되고 제거되지 않는 경향이 있습니다. 시간이 지나면 노이즈에서 신호를 필터링하기가 너무 어려워 로그 파일이 거의 쓸모 없게됩니다. 이로 인해 개발자는 로그를 사용하지 않아 죽음의 나선이 계속됩니다. 반대로 추적 메시지를 지속적으로 정리하면 개발자는이 메시지를 사용하여 선순환이됩니다. 또한 릴리스 빌드에 포함되지 않은 디버그 코드에서 필요한 부작용으로 인해 버그가 발생할 가능성을 제거합니다. 예, 좋은 코드에서는 발생하지 않아야하지만 안타깝게도 안전합니다.

답변

다음은 “로거”의 목록입니다.

아파치 log4j : §1 , §2

  1. FATAL:

    [ v1.2 : ..] 매우 심각한 오류 이벤트로 인해 응용 프로그램이 중단 될 수 있습니다.

    [ v2.0 : ..] 응용 프로그램을 계속하지 못하게하는 심각한 오류입니다.

  2. ERROR:

    [ v1.2 : ..] 오류 이벤트로 여전히 응용 프로그램을 계속 실행할 수 있습니다.

    응용 프로그램에서 [ v2.0 : ..] 오류가 발생했을 가능성이 있습니다.

  3. WARN:

    [ v1.2 : ..] 잠재적으로 위험한 상황.

    [ sic ] 일 수있는 [ v2.0 : ..] 이벤트 에서 오류가 발생했습니다.

  4. INFO:

    [ v1.2 : ..] 대략적인 수준에서 응용 프로그램의 진행 상황을 강조하는 정보 메시지.

    정보 제공을위한 [ v2.0 : ..] 이벤트.

  5. DEBUG:

    [ v1.2 : ..] 응용 프로그램을 디버깅하는 데 가장 유용한 세분화 된 정보 이벤트입니다.

    [ v2.0 : ..] 일반 디버깅 이벤트.

  6. TRACE:

    [ v1.2 : ..]보다 세밀한 정보 이벤트 DEBUG.

    [ v2.0 : ..] 세밀한 디버그 메시지로, 일반적으로 응용 프로그램을 통한 흐름을 캡처합니다.

아파치 Httpd는 (평소와 같이) 오버 킬을 좋아한다 : §

  1. 에머 :

    비상 – 시스템을 사용할 수 없습니다.

  2. 경고 :

    즉시 조치를 취해야합니다 (그러나 시스템은 여전히 ​​사용 가능합니다).

  3. 치명타 :

    중요 조건 [조치가 즉시 수행 될 필요는 없음].

    • ” socket : 소켓을 가져 오지 못했습니다 (자식을 종료하는 중 “

  4. 오류 :

    오류 조건 [중요하지는 않음].

    • ” 스크립트 헤더의 조기 끝 “

  5. 경고 :

    경고 조건. [오류에 가깝지만 오류는 아님]

  6. 공지 사항 :

    정상이지만 중요한 [ 주목할만한 ] 상태.

    • ” httpd : 적발 SIGBUS, 코어 덤프 시도 중 … “

  7. 정보 :

    정보 제공 및 주목할 만함.

    • [ ” 서버가 x 시간 동안 실행되었습니다. “]

  8. 디버그 :

    디버그 레벨 메시지 [즉, 디버깅을 위해 로그 된 메시지 )].

    • ” 설정 파일을 여는 중 … “

  9. trace1 → trace6 :

    추적 메시지 [즉, 추적을 위해 기록 된 메시지 ].

    • ” 프록시 : FTP : 제어 연결 완료 “
    • ” 프록시 : CONNECT : CONNECT 요청을 원격 프록시로 보내기 “
    • ” openssl : 핸드 셰이크 : 시작 “
    • ” 버퍼링 된 SSL 여단에서 읽기, 모드 0, 17 바이트 “
    • ” 지도 조회 실패 :map=rewritemap key=keyname “
    • ” 캐시 조회가 실패하여 새 맵 조회가 강제 실행되었습니다 “

  10. trace7 → trace8 :

    대량의 데이터를 덤프하는 추적 메시지

    • ” | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |“
    • ” | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |“

아파치 공통 로깅 : §

  1. 치명적 :

    조기 종료를 유발하는 심각한 오류. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.

  2. 오류 :

    기타 런타임 오류 또는 예기치 않은 조건 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.

  3. 경고 :

    더 이상 사용되지 않는 API 사용, API 사용 불량, ‘거의’오류, 바람직하지 않거나 예상치 않지만 반드시 “잘못된”기타 런타임 상황. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.

  4. 정보 :

    흥미로운 런타임 이벤트 (시작 / 종료) 이것들은 콘솔에서 즉시 볼 수 있으므로 보수적이며 최소한으로 유지하십시오.

  5. 디버그 :

    시스템을 통한 흐름에 대한 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.

  6. 추적 :

    더 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.

엔터프라이즈 사용에 대한 Apache 공통 로깅 “모범 사례”는 교차하는 경계의 종류에 따라 디버그 와 정보를 구분 합니다.

경계는 다음과 같습니다.

  • 외부 경계-예상 예외.

  • 외부 경계-예기치 않은 예외.

  • 내부 경계.

  • 중요한 내부 경계.

(자세한 내용은 공통 로깅 안내서 를 참조하십시오 .)

답변

문제에서 복구 할 수 있으면 경고입니다. 실행이 계속되지 않으면 오류입니다.

답변

Syslog 심각도 수준을 채택하는 것이 좋습니다 DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. http://en.wikipedia.org/wiki/Syslog#Severity_levels를
참조하십시오 .

대부분의 사용 사례에 대해 세밀한 심각도 수준을 충분히 제공해야하며 기존 로그 파서에 의해 인식됩니다. 물론 DEBUG, ERROR, EMERGENCY앱의 요구 사항에 따라 하위 집합 만 구현할 수있는 자유 는 있습니다.

우리가 만드는 모든 다른 앱에 대한 자체 표준을 제시하는 대신 오랜 세월 동안 있었던 것에 대해 표준화합시다. 로그 집계를 시작하고 서로 다른 패턴에서 패턴을 감지하려고하면 실제로 도움이됩니다.

답변

복구 할 수있는 경고. 당신이 할 수없는 오류. 그것은 휴리스틱입니다. 다른 사람들은 다른 아이디어를 가질 수 있습니다.

예를 들어, 이름 "Angela Müller"을 응용 프로그램에 입력 / 가져 오기한다고 가정 해 봅시다 (의 움라우트 참고 u). 귀하의 코드 / 데이터베이스 (아마 불구하고 영어를 할 수 없습니다해야 이 시대에있을) 따라서 모든 “이상한”문자는 일반 영어 문자로 변환되었다는 것을 경고 할 수있다.

그 정보를 데이터베이스에 쓰려고 시도하고 60 초 동안 네트워크 다운 메시지를 다시받는 것과는 대조적입니다. 경고보다 오류가 더 많습니다.