답변:
나는 일반적으로 다음 규칙을 구독합니다.
Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).. Logger.Debug는 개발자가 프로덕션에서 매우 까다로운 문제를 추적 할 수 있도록합니다.If you want to print the value of a variable at any given point inside a for loop against a condition
한밤중에 시스템 관리자에게 메시지가 표시되도록 하시겠습니까?
FATALsysadmin이 깨어 났을 때 충분히 지불하지 않았다고 판단하고 다시 잠자기 상태가됩니다.
로그 파일을 보는 관점에서 심각도에 대해 생각하는 것이 더 도움이됩니다.
치명적 / 중요 : 즉시 조사해야하는 전체 응용 프로그램 또는 시스템 오류. 예, SysAdmin을 깨 웁니다. 우리는 SysAdmins 경고를 선호하고 잘 정돈되어 있으므로이 심각도는 매우 드물게 사용해야합니다. 그것이 매일 일어나고 BFD가 아니라면, 그것은 의미를 잃어 버렸습니다. 일반적으로 치명적 오류는 프로세스 수명 동안 한 번만 발생하므로 로그 파일이 프로세스에 연결되어 있으면 일반적으로 로그의 마지막 메시지입니다.
오류 : 확실히 조사해야 할 문제입니다. SysAdmin에 자동으로 알려야하지만 침대에서 끌어 올 필요는 없습니다. 오류를 확인하기 위해 로그를 필터링하면 오류 빈도에 대한 개요를 얻을 수 있으며 일련의 추가 오류가 발생할 수있는 초기 오류를 신속하게 식별 할 수 있습니다. 응용 프로그램 사용과 비교하여 오류율을 추적하면 전체 품질을 평가하는 데 사용할 수있는 MTBF와 같은 유용한 품질 메트릭을 얻을 수 있습니다. 예를 들어이 메트릭은 릴리스 전에 다른 베타 테스트주기가 필요한지 여부를 결정하는 데 도움이 될 수 있습니다.
경고 : 이것은 문제가 될 수도 있고 아닐 수도 있습니다. 예를 들어 네트워크의 짧은 손실 또는 데이터베이스 연결과 같은 예상되는 일시적인 환경 조건은 오류가 아니라 경고로 기록되어야합니다. 경고 및 오류 만 표시하도록 필터링 된 로그를 보면 후속 오류의 근본 원인에 대한 초기 힌트를 신속하게 파악할 수 있습니다. 의미가 없어지지 않도록 경고를 드물게 사용해야합니다. 예를 들어, 네트워크 액세스 손실은 서버 응용 프로그램에서 경고 또는 오류 여야하지만 간혹 연결이 끊긴 랩톱 사용자를 위해 설계된 데스크톱 응용 프로그램의 정보 일 수 있습니다.
정보 : 성공적인 초기화, 서비스 시작 및 중지 또는 중요한 트랜잭션 완료와 같은 정상적인 조건에서 기록해야하는 중요한 정보입니다. 정보 이상을 표시하는 로그를 보면 발생하는 모든 경고 또는 오류를 이해하기위한 최상위 컨텍스트를 제공하는 프로세스의 주요 상태 변경에 대한 빠른 개요를 제공해야합니다. 정보 메시지가 너무 많지 않습니다. 추적과 관련하여 일반적으로 <5 % 정보 메시지가 있습니다.
추적 : 추적은 가장 일반적으로 사용되는 심각도이며 오류 및 경고로 이어지는 단계를 이해하기위한 컨텍스트를 제공해야합니다. 추적 메시지의 올바른 밀도를 가지면 소프트웨어를 유지 관리하기가 훨씬 쉬워 지지만 프로그램이 발전함에 따라 개별 Trace 문의 값이 시간이 지남에 따라 변경 될 수 있으므로 약간의주의가 필요합니다. 이를 달성하는 가장 좋은 방법은 개발자 팀이 고객이보고 한 문제를 해결하는 표준 부분으로 정기적으로 로그를 검토하는 습관을 갖도록하는 것입니다. 더 이상 유용한 컨텍스트를 제공하지 않는 추적 메시지를 제거하고 후속 메시지의 컨텍스트를 이해하는 데 필요한 메시지를 추가하도록 팀에 권장하십시오. 예를 들어, 디스플레이 또는 탭 변경과 같은 사용자 입력을 로그하는 것이 종종 도움이됩니다.
디버그 : 디버그 <트레이스를 고려합니다. 차이점은 디버그 메시지가 릴리스 빌드에서 컴파일된다는 것입니다. 즉, 디버그 메시지 사용을 권장하지 않습니다. 디버그 메시지를 허용하면 점점 더 많은 디버그 메시지가 추가되고 제거되지 않는 경향이 있습니다. 시간이 지나면 노이즈에서 신호를 필터링하기가 너무 어려워 로그 파일이 거의 쓸모 없게됩니다. 이로 인해 개발자는 로그를 사용하지 않아 죽음의 나선이 계속됩니다. 반대로 추적 메시지를 지속적으로 정리하면 개발자는이 메시지를 사용하여 선순환이됩니다. 또한 릴리스 빌드에 포함되지 않은 디버그 코드에서 필요한 부작용으로 인해 버그가 발생할 가능성을 제거합니다. 예, 좋은 코드에서는 발생하지 않아야하지만 안타깝게도 안전합니다.
다음은 "로거"의 목록입니다.
FATAL:
[ v1.2 : ..] 매우 심각한 오류 이벤트로 인해 응용 프로그램이 중단 될 수 있습니다.
[ v2.0 : ..] 응용 프로그램을 계속하지 못하게하는 심각한 오류입니다.
ERROR:
[ v1.2 : ..] 오류 이벤트로 여전히 응용 프로그램을 계속 실행할 수 있습니다.
응용 프로그램에서 [ v2.0 : ..] 오류가 발생했을 가능성이 있습니다.
WARN:
[ v1.2 : ..] 잠재적으로 위험한 상황.
[ sic ] 일 수있는 [ v2.0 : ..] 이벤트 에서 오류가 발생했습니다.
INFO:
[ v1.2 : ..] 대략적인 수준에서 응용 프로그램의 진행 상황을 강조하는 정보 메시지.
정보 제공을위한 [ v2.0 : ..] 이벤트.
DEBUG:
[ v1.2 : ..] 응용 프로그램을 디버깅하는 데 가장 유용한 세분화 된 정보 이벤트입니다.
[ v2.0 : ..] 일반 디버깅 이벤트.
TRACE:
[ v1.2 : ..]보다 세밀한 정보 이벤트
DEBUG.[ v2.0 : ..] 세밀한 디버그 메시지로, 일반적으로 응용 프로그램을 통한 흐름을 캡처합니다.
아파치 Httpd는 (평소와 같이) 오버 킬을 좋아한다 : §
에머 :
비상 – 시스템을 사용할 수 없습니다.
경고 :
즉시 조치를 취해야합니다 (그러나 시스템은 여전히 사용 가능합니다).
치명타 :
중요 조건 [조치가 즉시 수행 될 필요는 없음].
- " socket : 소켓을 가져 오지 못했습니다 (자식을 종료하는 중 "
오류 :
오류 조건 [중요하지는 않음].
- " 스크립트 헤더의 조기 끝 "
경고 :
경고 조건. [오류에 가깝지만 오류는 아님]
공지 사항 :
정상이지만 중요한 [ 주목할만한 ] 상태.
- " httpd : 적발
SIGBUS, 코어 덤프 시도 중 ... "
정보 :
정보 제공 및 주목할 만함.
- [ " 서버가 x 시간 동안 실행되었습니다. "]
디버그 :
디버그 레벨 메시지 [즉, 디버깅을 위해 로그 된 메시지 )].
- " 설정 파일을 여는 중 ... "
trace1 → trace6 :
추적 메시지 [즉, 추적을 위해 기록 된 메시지 ].
- " 프록시 : FTP : 제어 연결 완료 "
- " 프록시 : CONNECT : CONNECT 요청을 원격 프록시로 보내기 "
- " openssl : 핸드 셰이크 : 시작 "
- " 버퍼링 된 SSL 여단에서 읽기, 모드 0, 17 바이트 "
- " 지도 조회 실패 :
map=rewritemapkey=keyname"- " 캐시 조회가 실패하여 새 맵 조회가 강제 실행되었습니다 "
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 |"
아파치 공통 로깅 : §
치명적 :
조기 종료를 유발하는 심각한 오류. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.
오류 :
기타 런타임 오류 또는 예기치 않은 조건 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.
경고 :
더 이상 사용되지 않는 API 사용, API 사용 불량, '거의'오류, 바람직하지 않거나 예상치 않지만 반드시 "잘못된"기타 런타임 상황. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.
정보 :
흥미로운 런타임 이벤트 (시작 / 종료) 이것들은 콘솔에서 즉시 볼 수 있으므로 보수적이며 최소한으로 유지하십시오.
디버그 :
시스템을 통한 흐름에 대한 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.
추적 :
더 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.
엔터프라이즈 사용에 대한 Apache 공통 로깅 "모범 사례"는 교차하는 경계의 종류에 따라 디버그 와 정보를 구분 합니다.
경계는 다음과 같습니다.
외부 경계-예상 예외.
외부 경계-예기치 않은 예외.
내부 경계.
중요한 내부 경계.
(자세한 내용은 공통 로깅 안내서 를 참조하십시오 .)
문제에서 복구 할 수 있으면 경고입니다. 실행이 계속되지 않으면 오류입니다.
fatalError는 파일이 존재하지 않는 경우 와 관련된 어설 션을 작성하는 것이 일반적 입니다. 기본적으로 그것은 당신이 말한 것과 반대입니다.
Syslog 심각도 수준을 채택하는 것이 좋습니다 DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. http://en.wikipedia.org/wiki/Syslog#Severity_levels를
참조하십시오 .
대부분의 사용 사례에 대해 세밀한 심각도 수준을 충분히 제공해야하며 기존 로그 파서에 의해 인식됩니다. 물론 DEBUG, ERROR, EMERGENCY앱의 요구 사항에 따라 하위 집합 만 구현할 수있는 자유 는 있습니다.
우리가 만드는 모든 다른 앱에 대한 자체 표준을 제시하는 대신 오랜 세월 동안 있었던 것에 대해 표준화합시다. 로그 집계를 시작하고 서로 다른 패턴에서 패턴을 감지하려고하면 실제로 도움이됩니다.
DEBUG, INFO, WARNING와 ERROR. 개발자는 모든 수준을 볼 수 있어야합니다. SysAdmins INFO및 최종 사용자는 경고 및 오류를 볼 수 있지만 경고 할 프레임 워크가있는 경우에만 볼 수 있습니다 .
DEBUG와 TRACE개발자 모두 를 위해. 그리고 ERROR다른 레벨이 좋아에 확장 CRITICAL, ALERT, EMERGENCY심각도에 따라 작업을 오류의 심각도를 구별하고 결정합니다.
복구 할 수있는 경고. 당신이 할 수없는 오류. 그것은 휴리스틱입니다. 다른 사람들은 다른 아이디어를 가질 수 있습니다.
예를 들어, 이름 "Angela Müller"을 응용 프로그램에 입력 / 가져 오기한다고 가정 해 봅시다 (의 움라우트 참고 u). 귀하의 코드 / 데이터베이스 (아마 불구하고 영어를 할 수 없습니다해야 이 시대에있을) 따라서 모든 "이상한"문자는 일반 영어 문자로 변환되었다는 것을 경고 할 수있다.
그 정보를 데이터베이스에 쓰려고 시도하고 60 초 동안 네트워크 다운 메시지를 다시받는 것과는 대조적입니다. 경고보다 오류가 더 많습니다.
다른 사람들이 말했듯이 오류는 문제입니다. 경고는 잠재적 인 문제입니다.
개발시에는 어설 션 오류에 해당하지만 응용 프로그램은 계속 작동 할 수있는 경고를 자주 사용합니다. 이를 통해 그 사건이 실제로 발생하는지 또는 내 상상력인지 확인할 수 있습니다.
그러나 그렇습니다. 그것은 회복 가능성과 현실 측면으로 내려갑니다. 회복 할 수 있다면 아마도 경고 일 것입니다. 실제로 오류가 발생하면 오류입니다.
SYSLOG 수준 NOTICE 및 ALERT / EMERGENCY는 응용 프로그램 수준 로깅에 크게 불필요한 것으로 생각되지만 CRITICAL / ALERT / EMERGENCY는 다른 작업 및 알림을 트리거 할 수있는 운영자에게 유용한 경고 수준 일 수 있습니다. 치명적인. 그리고 나는 통지를받는 것과 정보를 얻는 것을 충분히 구별 할 수 없습니다. 정보가 주목할 만하지 않으면 실제로 정보가 아닙니다 :)
Jay Cincotta의 해석이 가장 좋습니다. 코드 실행 추적은 기술 지원에 매우 유용하며, 특히 특정 응용 프로그램 구성 요소의 추적 메시지를 기록하는 동적 필터링 메커니즘과 함께 추적 문을 코드에 자유롭게 입력하는 것이 좋습니다. 그러나 나에게 DEBUG 레벨은 현재 진행중인 것을 파악하는 과정에 있음을 나타냅니다. DEBUG 레벨 출력은 프로덕션 로그에 표시되어야하는 것이 아니라 개발 전용 옵션으로 간주합니다.
그러나 운영 메시지에 대한 기술 지원 또는 개발자 : OPER만큼 sysadmin의 모자를 쓸 때 오류 로그에보고 싶은 로깅 수준이 있습니다. 타임 스탬프, 호출 된 작업 유형, 제공된 인수, (고유 한) 작업 식별자 및 작업 완료를 기록하는 데 사용합니다. 예를 들어 독립 실행 형 작업이 시작될 때 사용됩니다. 더 큰 장기 실행 앱 내에서 실제로 호출됩니다. 문제가 발생했는지 여부에 관계없이 항상 기록하고 싶은 종류이므로 OPER 수준이 치명적보다 높으므로 완전히 자동 모드로 전환하여 끌 수 있습니다. 또한 단순한 INFO 로그 데이터 이상의 기능을 제공합니다. 로그 수준은 종종 과거 가치가없는 사소한 운영 메시지로 스팸 로그에 악용됩니다.
경우에 따라이 정보는 별도의 호출 로그로 보내지거나 더 많은 정보를 기록하는 큰 로그에서 필터링하여 얻을 수 있습니다. 그러나 과거 정보로서, 현재 수행중인 작업을 알기 위해서는 항상 필요합니다. 오작동 또는 시스템 작동과 관련이없는 완전히 별도의 로그 수준 인 AUDIT 수준으로 내려 가지 않고 실제로 위의 수준에 맞지 않습니다 ( 심각도 분류가 아닌 자체 제어 스위치가 필요하며 자체 로그 파일이 필요합니다.
RFC 5424에서 Syslog 프로토콜 (IETF)-페이지 10 :
각 메시지 우선 순위에는 십진 심각도 레벨 표시기가 있습니다. 이것들은 숫자 값과 함께 다음 표에 설명되어 있습니다. 심각도 값은 0에서 7 사이의 범위에 있어야합니다.
Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. Syslog Message Severities
나는 다른 사람들과 완전히 동의하고 GrayWizardx가 가장 잘 말했다고 생각합니다.
내가 추가 할 수있는 것은이 레벨이 일반적으로 사전 정의와 일치하므로 어렵지 않다는 것입니다. 의심스러운 경우 퍼즐처럼 취급하십시오. 특정 프로젝트의 경우 로그하려는 모든 것을 생각하십시오.
이제 치명적일 수있는 것을 알아낼 수 있습니까? 치명적인 의미가 무엇인지 아십니까? 따라서 목록에서 어떤 항목이 치명적입니까?
자, 그것은 치명적입니다. 이제 오류를 봅시다 ... 헹구고 반복하십시오.
치명적인 오류 또는 오류 일 경우, 더 많은 정보가 항상 적은 것보다 낫다는 것을 제안하므로 "위로"오류를 범하십시오. 정보 또는 경고인지 확실하지 않습니까? 그런 다음 경고하십시오.
치명적인 오류는 우리 모두에게 분명해야한다고 생각합니다. 다른 것들은 더 흐릿 할 수 있지만, 그것들을 올바르게하는 것은 덜 중요합니다.
여기 몇 가지 예가 있어요.
치명적 -메모리, 데이터베이스 등을 할당 할 수 없음-계속할 수 없습니다.
오류 -메시지에 답장이없고, 트랜잭션이 중단되었으며, 파일을 저장할 수 없습니다.
경고 -리소스 할당이 X % (예 : 80 %)에 도달했습니다. 이는 다시 차원을 조정하려는 징후입니다.
정보 -사용자 로그인 / 로그 아웃, 새 트랜잭션, 파일 분류, 새 d / b 필드 또는 필드가 삭제되었습니다.
디버그 -내부 데이터 구조 덤프, 파일 이름 및 줄 번호가있는 모든 항목 추적 레벨.
추적-작업 성공 / 실패, d / b 업데이트
오류는 잘못된 것, 명백한 잘못된 것, 그 주위에 방법이 없으며 수정해야합니다.
경고는 패턴의 징조 수도 틀릴 수도 있지만, 다음도하지 않을 수 있습니다.
말했듯이, 나는 오류가 아닌 경고의 좋은 예를 생각해 낼 수 없습니다. 이것이 의미하는 것은 경고를 기록하는 데 어려움을 겪으면 근본적인 문제를 해결할 수도 있다는 것입니다.
그러나 "sql execution takes long long"과 같은 것은 경고 일 수 있지만 "sql execution deadlocks"는 오류이므로 결국 몇 가지 경우가있을 수 있습니다.
varchar정의 된 것보다 많은 문자를 삽입하려고 하면 값이 잘 렸지만 여전히 삽입한다는 경고입니다. 그러나 한 사람의 경고가 다른 사람의 오류 일 수 있습니다. 제 경우에는 이것이 오류입니다. 데이터베이스와 일치하지 않는 길이를 정의하여 유효성 검사 코드에서 오류가 발생했음을 의미합니다. 그리고 다른 DB 엔진 이이 오류를 오류로 간주하더라도 놀라지 않을 것입니다. 결국 불명예 할 권리가 없습니다. 결국 잘못되었습니다.
Btw, 나는 모든 것을 포착하고 나중에 정보를 필터링하는 훌륭한 팬입니다.
경고 수준에서 캡처하고 경고와 관련된 디버그 정보를 원하지만 경고를 다시 만들 수없는 경우 어떻게됩니까?
모든 것을 캡처 하고 나중에 필터링하십시오!
프로세서를 유지할 수 없다는 것을 알지 못하면 임베디드 소프트웨어에서도 마찬가지입니다.이 경우 추적을보다 효율적으로 만들기 위해 다시 디자인하거나 추적이 타이밍을 방해합니다 ( 디버깅을 고려할 수 있음) 더 강력한 프로세서이지만 웜의 모든 캔을 열어줍니다).
모든 것을 포착 하고 나중에 필터링하십시오!
(btw, 디버그 추적을 보여주는 것 이상의 도구를 개발할 수 있기 때문에 모든 것을 캡처하는 것도 좋습니다. 메시지에서 메시지 시퀀스 차트와 메모리 사용 히스토그램을 그립니다. 미래 (통과 또는 실패 여부에 관계없이 모든 로그를 유지하고 로그 파일에 빌드 번호를 포함시켜야 함).
내 두 센트 FATAL및 TRACE오류 로그 수준.
ERROR FAULT (예외)가 발생할 때입니다.
FATAL 실제로 DOUBLE FAULT : 예외 처리 중 예외가 발생하는 경우
웹 서비스에 대한 이해가 쉽습니다.
INFO WARNERRORFATALTRACE함수 시작 / 종료를 추적 할 수있는 시점입니다. 이 메시지는 일부 디버거에서 생성 할 수 있고 코드가 전혀 호출되지 않았기 때문에 로깅에 관한 것이 아닙니다 log. 따라서 응용 프로그램에서 보내지 않은 메시지는 TRACE레벨 처럼 표시 됩니다. 예를 들어 응용 프로그램을strace
그래서 일반적으로 프로그램에서 당신이 할 DEBUG, INFO및 WARN로깅. 웹 서비스 / 프레임 워크를 작성하는 경우에만 사용 FATAL합니다. 그리고 응용 프로그램을 디버깅 할 때 TRACE이러한 유형의 소프트웨어에서 로깅을 받습니다 .
세 가지 수준 만 사용하는 것이 좋습니다
notice이 컬렉션에서 누군가가 그리워 하지 않을 것입니다 ...