로깅 레벨-로그 백-로그 레벨을 지정하기위한 룰

현재 프로젝트에서 로그 백 을 사용하고 있습니다.

6 가지 레벨의 로깅을 제공합니다. TRACE DEBUG INFO WARN ERROR OFF

일반적인 활동에 대한 로그 수준을 결정하는 경험 법칙을 찾고 있습니다. 예를 들어, 스레드가 잠긴 경우 로그 메시지를 디버그 레벨 또는 정보 레벨로 설정해야합니다. 또는 소켓을 사용중인 경우 특정 ID가 디버그 레벨 또는 추적 레벨에 기록되어야합니다.

각 로깅 수준에 대한 더 많은 예를 들어 답변을 부탁드립니다.

나는 주로 대규모 고 가용성 유형 시스템을 구축하므로 프로덕션 지원 관점에서 시스템을 바라 보는 방향으로 편향되어 있습니다. 즉, 우리는 대략 다음과 같이 할당합니다.

• error : 시스템이 조난 상태에 있고 고객이 영향을 받거나 조만간 수정 될 것이며 수정에는 사람의 개입이 필요할 수 있습니다. "2AM 규칙"이 여기에 적용됩니다. 통화중인 경우이 조건이 발생하면 오전 2시에 깨어나시겠습니까? 그렇다면 "오류"로 기록하십시오.

• 경고 : 예기치 않은 기술 또는 비즈니스 이벤트가 발생하여 고객에게 영향을 줄 수 있지만 즉각적인 사람의 개입이 필요하지 않을 수 있습니다. 통화중인 사람들은 즉시 전화를받지 않지만 지원 담당자는 이러한 문제를 검토하여 영향이 무엇인지 이해하려고합니다. 기본적으로 추적해야하지만 즉각적인 개입이 필요하지 않은 모든 문제.

• info : 문제를 법 의학적으로 분석해야 할 경우를 대비하여 대량으로보고 싶은 것. 시스템 수명주기 이벤트 (시스템 시작, 중지)가 여기에 있습니다. "세션"라이프 사이클 이벤트 (로그인, 로그 아웃 등)가 여기에 있습니다. 중요한 경계 이벤트 (예 : 데이터베이스 호출, 원격 API 호출)도 고려해야합니다. 일반적인 비즈니스 예외는 여기로 갈 수 있습니다 (예 : 자격 증명이 잘못되어 로그인에 실패). 대량 생산에서 볼 필요가 있다고 생각되는 다른 이벤트는 여기에 있습니다.

• 디버그 : "정보"를 자르지 않는 모든 것, 특히 시스템의 흐름을 추적하고 특히 개발 및 QA 단계에서 문제를 격리하는 데 도움이되는 메시지. 우리는 사소하지 않은 대부분의 메소드의 시작 / 종료 및 메소드 내부의 흥미로운 이벤트 및 결정 지점을 표시하기 위해 "디버그"레벨 로그를 사용합니다.

• trace : 우리는 이것을 자주 사용하지 않지만, 정상적인 개발 중에도 일반적으로 사용하지 않으려는 매우 상세하고 잠재적으로 많은 양의 로그에 사용됩니다. 예를 들어 전체 객체 계층 덤프, 대형 루프 반복시 일부 상태 로깅 등이 있습니다.

올바른 로그 수준을 선택하는 것 이상으로 중요한 것은 로그가 의미 있고 필요한 컨텍스트를 갖도록하는 것입니다. 예를 들어, 거의 항상 스레드 ID를 로그에 포함시켜 필요한 경우 단일 스레드를 따를 수 있습니다. 비즈니스 정보 (예 : 사용자 ID)를 스레드에 연결하여 기록되도록하는 메커니즘을 사용할 수도 있습니다. 로그 메시지에 메시지를 실행할 수 있도록 충분한 정보를 포함하고 싶을 것입니다. "FileNotFound 예외 발견됨"과 같은 로그는 그다지 도움이되지 않습니다. 더 좋은 메시지는 "구성 파일을 열려는 중에 FileNotFound 예외가 발견되었습니다 : /usr/local/app/somefile.txt. userId = 12344."

좋은 로깅 가이드도 많이 있습니다 ... 예를 들어 JCL (Jakarta Commons Logging) 에서 편집 한 스 니펫은 다음과 같습니다.

• error-기타 런타임 오류 또는 예기치 않은 조건. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.
• 경고-더 이상 사용되지 않는 API 사용, API 사용 불량, '거의'오류, 바람직하지 않거나 예상치 않지만 반드시 "잘못된"기타 런타임 상황. 상태 콘솔에 즉시 표시 될 것으로 예상됩니다.
• info-재미있는 런타임 이벤트 (시작 / 종료). 이것들은 콘솔에서 즉시 볼 수 있으므로 보수적이며 최소한으로 유지하십시오.
• 디버그-시스템을 통한 흐름에 대한 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.
• 추적-더 자세한 정보. 이것들은 로그에만 쓰여질 것으로 예상됩니다.

내 접근 방식은 운영 관점보다 개발에서 더 많이 오는 것이라고 생각합니다.

• 오류 는 일부 작업의 실행을 완료 할 수 없음을 의미합니다. 이메일을 보낼 수없고, 페이지를 렌더링 할 수 없으며, 일부 데이터를 데이터베이스에 저장할 수 없습니다. 확실하게 잘못되었습니다.
• 경고 는 예기치 않은 일이 발생했지만 성능이 저하 된 모드에서 계속 실행될 수 있음을 의미합니다. 구성 파일이 누락되었지만 기본값이 사용되었고 가격이 음수로 계산되어 0으로 고정되었습니다. 무언가 잘못되었지만 아직 제대로 잘못되지 않았습니다. 경고는 종종있을 것입니다. 곧 오류가 발생했습니다.
• 정보 는 정상이지만 중요한 일이 발생했음을 의미합니다. 시스템 시작, 시스템 중지, 일일 인벤토리 업데이트 작업 실행 등이 계속 발생하지 않아야합니다. 그렇지 않으면 읽을 내용이 너무 많습니다.
• 디버그 는 정상적이고 중요하지 않은 일이 발생했음을 의미합니다. 새로운 사용자가 사이트를 방문하여 페이지가 렌더링되고 주문이 이루어졌으며 가격이 업데이트되었습니다. 정보가 너무 많기 때문에 정보에서 제외 된 것입니다.
• 추적 은 실제로 사용하지 않은 것입니다.

또한 특정 수준 의 로깅 요청 (코드의 요청 )으로 인해 배포가 구성된 유효한 로깅 수준이 주어지면 실제로 기록 되는지 확인할 수 있습니다 . 여기에있는 다른 답변에서 배포를 구성 할 효과적인 수준을 결정한 다음 코드 의 특정 로깅 요청 이 실제로 기록되는지 확인하려면이를 참조하십시오 .

예를 들면 다음과 같습니다.

• "WARN에서 로깅하는 로깅 코드 라인이 실제로 ERROR로 구성된 배치에 로깅됩니까?" 표에 NO라고 나와 있습니다.
• "WARN에서 로깅하는 로깅 코드 라인이 실제로 DEBUG로 구성된 배치에 로깅됩니까?" 테이블에 예라고 말합니다.

에서 logback 문서 :

보다 그래픽적인 방식으로 선택 규칙의 작동 방식은 다음과 같습니다. 다음 표에서 세로 헤더는 p로 지정된 로깅 요청의 레벨을 표시하고 가로 헤더는 q로 지정된 로거의 유효 레벨을 표시합니다. 행 (레벨 요청)과 열 (유효 레벨)의 교차는 기본 선택 규칙으로 인한 부울입니다.

따라서 로깅을 요청하는 코드 라인은 실제로 배치 의 유효 로깅 레벨이 해당 코드 라인의 요청 된 심각도 레벨 보다 작거나 같은 경우에만 로그됩니다 .

조직이 서로 의존 할 수있는 많은 구성 요소를 실행하는 구성 요소 기반 아키텍처에서이 문제에 답합니다. 전파 실패 중에 로깅 레벨은 영향을받는 구성 요소와 근본 원인을 식별하는 데 도움이됩니다.

• ERROR- 이 구성 요소에 오류 가 발생했으며 원인은 내부적 (내부 처리되지 않은 예외, 캡슐화 된 종속성 실패 ... 예 : 데이터베이스, REST 예는 종속성에서 4xx 오류를 수신했을 것임)으로 간주됩니다. 침대에서 나와 (이 구성 요소의 유지 관리자)를 꺼내십시오.

• WARN- 이 구성 요소는 종속 구성 요소로 인한 것으로 생각되는 장애가 있습니다 (REST 예는 종속성의 5xx 상태 임). THAT 구성 요소의 관리자를 침대에서 꺼내십시오.

• 정보 -우리가 운영자에게 전달하고 싶은 다른 것. 올바른 경로를 기록하기로 결정한 경우 중요한 작업 (예 : 들어오는 http 요청) 당 1 개의 로그 메시지로 제한하는 것이 좋습니다.

모든 로그 메시지에 대해 유용한 컨텍스트를 기록해야합니다 (그리고 "오류 코드"를 많이 보지 않고 사람이 읽을 수 있도록 / 유용하도록 메시지의 우선 순위를 정하십시오)

• DEBUG (및 이하)-전혀 사용해서는 안됩니다 (및 프로덕션에서는 사용하지 않아야 함). 개발 중에는 로그 문이있는 오염 코드와 달리 TDD와 디버깅 (필요한 경우)의 조합을 사용하는 것이 좋습니다. 프로덕션에서는 다른 메트릭과 결합 된 위의 INFO 로깅이면 충분합니다.

위의 로깅 수준을 시각화하는 좋은 방법은 각 구성 요소에 대한 모니터링 화면 세트를 상상하는 것입니다. 모두 제대로 실행되면 녹색이고, 구성 요소에 경고가 기록되면 오류가 기록되면 주황색 (황색)이됩니다.

사고가 발생하면 하나의 (근본 원인) 구성 요소가 빨간색으로 바뀌고 영향을받는 모든 구성 요소가 주황색 / 황색으로 표시됩니다.

다른 답변과 다르지 않지만 내 프레임 워크는 거의 같은 수준입니다.

1. 오류 : 데이터베이스 연결 시간 초과와 같은 응용 프로그램의 중요한 논리적 오류입니다. 가까운 장래에 버그 수정을 요구하는 것
2. 경고 : 끊임없는 문제이지만주의해야 할 사항. 요청한 페이지를 찾을 수 없습니다
3. 정보 : 함수 / 메소드 첫 번째 라인에서 사용되어 삽입 쿼리가 완료 된 것처럼 호출 된 절차 또는 단계가 제대로 진행되었음을 보여줍니다.
4. log : if 문의 결과와 같은 논리 정보
5. 디버그 : 영구적으로 감시되는 변수 내용