로그 규칙

1. [필수] 로그 시스템의 API(Log 4 j, Logback)는 애플리케이션에서 직접 사용할 수 없으며 대신 로그 프레임워크 SLF 4 J의 API를 사용해야 합니다. Facade 모드는 유지 관리에 도움이 되며 클래스 로그 처리 방법이 통일되어 있습니다. import org.slf4j.Logger;

import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);

2. [필수] 일부 예외는 "주간" 발생 빈도 특성을 가지므로 최소 15일 동안 로그 파일을 저장하는 것이 좋습니다.

3. 애플리케이션 내 확장 로그 이름 지정 방법(예: 관리, 임시 모니터링, 액세스 로그 등):

appName _ logType _ logName . logType: 로그 유형, 권장 카테고리에는

stats / desc / monitor / Visit 등이 포함됩니다. logName: 로그 설명. 이런 이름 지정의 장점은 파일 이름을 통해 해당 로그 파일이 어떤 애플리케이션에 속해 있는지, 어떤 유형인지, 어떤 목적인지 알 수 있다는 점입니다. 분류 및 검색에도 도움이 됩니다.

긍정적인 예: mppserver 애플리케이션에서 시간대 변환 예외를 별도로 모니터링합니다. 예: mppserver _ monitor _ timeZoneConvert log

설명: 로그를 분류하고 오류 로그를 저장하는 것이 좋습니다. 업무 로그는 편의상 별도로 분리하여 로그를 통해 적시에 시스템을 확인하고 모니터링할 수 있어 개발자에게도 편리합니다.

4. [필수] 추적/디버그/정보 수준 로그 출력의 경우 조건부 출력 형식을 사용하거나 자리 표시자 방식을 사용해야 합니다.

설명:

logger . debug( " id로 거래 처리 : " + id + " 기호 : " + 기호);

로그 수준이 경고인 경우 위의 로그는 인쇄되지 않지만 문자열 접합 작업이 수행됩니다. 기호가 객체인 경우 는 toString() 메서드를 실행하므로 위 작업을 수행한 후 최종 로그가 인쇄되지 않습니다.

긍정적 예시:

(조건)

if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
}

긍정적 예시:

(자리 표시자)

logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);

5 [필수] 로그를 반복적으로 인쇄하여 디스크 공간을 낭비하지 않도록 하세요. 가산성 = 거짓 .

긍정적 예:

6. 비정상적인 정보에는 범죄 현장 정보라는 두 가지 유형이 포함되어야 합니다. 및 예외 스택 정보. 처리되지 않으면 버리세요
.

긍정적인 예:

logger.error(다양한 매개변수 또는 객체 toString + "_" + e.getMessage(), e);

7. [권장] 경고 로그 수준을 사용하여 사용자 입력 매개변수 오류를 기록하면 사용자가 불만을 제기할 때 당황하지 않을 수 있습니다. 로그 출력 수준에 주의하세요. 오류 수준은 시스템 논리 오류 및 예외와 같은 중요한 오류 정보만 기록합니다. 반드시 필요한 것이 아니라면 이 시나리오에서는 오류 수준을 입력하지 마십시오.

8. [권장] 로그를 꼼꼼히 기록하세요. 프로덕션 환경에서는 디버그 로그를 출력하는 것이 금지되어 있습니다. 경고를 사용하여 처음 시작할 때 비즈니스 동작 정보를 기록하는 경우 서버 디스크가 버스트되지 않도록 로그 출력량에 주의해야 합니다. 적시에 이러한 관찰 로그를 삭제하는 것을 잊지 마십시오.

참고: 잘못된 로그를 많이 출력하는 것은 시스템 성능 향상에 도움이 되지 않으며 오류 지점을 빠르게 찾는 데 도움이 되지 않습니다. 로그를 기록할 때 생각해 보세요. 실제로 이 로그를 읽는 사람이 있나요? 이 로그를 본 후 무엇을 할 수 있나요? 문제 해결에 이점을 가져올 수 있습니까?

로그 규칙

PHP 중국어 웹사이트