Java 로깅을 올바르게 사용하는 방법

로그에 관해서는 모두가 상대적으로 간단하다고 생각합니다. 관련 종속성 패키지만 도입하면 되고, 나머지는 프로젝트에 필요한 정보를 인쇄하는 것을 "즐기는 것"입니다. 그러나 일이 단순할수록 무시하기가 더 쉬워서 엄격한 프로그래머로서 버그가 발생하지 않는 경우가 많습니다. 어떻게 이런 일이 발생하도록 놔둘 수 있습니까? 그럼 로그에 대한 올바른 사용 자세에 대해 알아보겠습니다.

Text

로그 사양

Naming

첫 번째는 로그 파일의 이름 지정입니다. 팀은 이름도 숙지해야 합니다. 그렇지 않으면 "더럽고 지저분한" 로그 파일이 영향을 받게 됩니다. 문제 해결에 있어서 모든 사람의 효율성. 이름을 통해 로그 파일이 어떤 프로젝트에 속해 있는지, 어떤 유형인지, 어떤 기능을 가지고 있는지 명확하게 알 수 있도록 "projectName_logName_logType.log"로 이름을 지정하는 것이 좋습니다. 예를 들어 MessageServer 프로젝트에서는 Rabbitmq 소비자 모니터링과 관련된 로그 파일 이름을 "messageserver_rabbitmqconsumer_monitor.log"로 정의할 수 있습니다.

저장 시간

로그 저장 시간은 일반 로그 파일을 15일 동안 보관하는 것이 더 중요할 경우 실제 상황에 따라 연장될 수 있습니다. 자세한 내용은 해당 서버 디스크를 참조하세요. 공간과 로그 파일 크기를 고려하여 최적의 선택을 하세요.

로그 수준

일반적인 로그 수준은 다음과 같습니다.

DEBUG 수준: 디버거 관련 정보를 기록합니다. INFO 수준: 프로그램의 정상적인 작동에 대한 의미 있는 정보를 기록합니다. WARN 수준: 잠재적으로 오류를 일으킬 수 있는 정보를 기록합니다. ERROR 수준: 현재 프로그램 오류에 대한 정보를 기록하며 주의와 처리가 필요합니다. 치명적 수준: 심각한 오류가 발생하여 프로그램 실행이 중단됨을 나타냅니다.

프로젝트에서는 ERROR, WARN, INFO, DEBUG 4가지 레벨을 사용하는 것이 좋습니다.

올바른 자세

1. 로그레벨을 미리 판단하세요

//条件判断if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}//使用占位符logger.debug("server info , id : {}, user : {}",id,user);

DEBUG 및 INFO 레벨 로그가 비교적 자주 존재합니다. 프로젝트가 커지고 로그 수가 증가하면 프로그램을 보다 효율적으로 실행하기 위해 조건에 ​​따라 로그를 인쇄해야 합니다. 자리 표시자. 왜? 프로젝트에 구성된 로그 수준이 WARN이면 다음 로그 출력 문 'logger.debug("server info, id: " + id + ", user: " + user);'에 대해 로그는 그렇지 않지만 인쇄되지만 문자열 연결 작업이 수행됩니다. 여기서는 사용자가 인스턴스 개체이므로 toString 메서드도 실행되므로 시스템 리소스가 많이 낭비됩니다.

2. 중복 로그 출력 방지

우리 프로덕션 환경에서는 일반적으로 DEBUG 로그 출력이 매우 높아 정상적인 작동에 쉽게 영향을 미칠 수 있습니다. 이 프로그램은 심각한 영향을 미쳤으며 최근 프로젝트에서도 비슷한 상황에 직면했습니다.

그런 다음 가산성 속성을 사용하는 방법을 배울 시간입니다.

<logger name="xx" additivity="true">

여기에서 true로 구성하면(기본 상황) 현재 Logger는 상위 Logger의 Appender를 상속합니다. . 직설적으로 말하면 현재 로그 파일에 출력되는 것 외에도 현재 로그의 출력은 상위 파일에도 출력됩니다. 따라서 일반적으로 반복 인쇄를 피하기 위해 이 매개변수를 false로 설정하여 불필요한 출력을 줄입니다.

3. 로그 기록 정보가 완전한지 확인하세요

우리 코드에서 로그 기록 내용에는 "XX"와 같은 간단한 메시지가 포함되어야 합니다. error"를 임의로 로그에 기록하는 것은 오류 디버깅에 도움이 되지 않습니다. 따라서 예외를 기록할 때는

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

과 같은 스택 정보를 가져와야 합니다. 객체 인스턴스를 출력할 때 객체가 toString 메서드를 재정의하는지 확인해야 합니다. 그렇지 않으면 해당 hashCode 값만 출력됩니다.

4. 로거 변수를 static

private static final Logger logger = LoggerFactory.getLogger(XX.class);

으로 정의하여 매번 다시 생성되지 않도록 개체가 하나의 Logger 개체만 사용하는지 확인하세요. 그렇지 않으면 OOM이 발생할 수 있습니다.

5. 로그 수준을 올바르게 사용하세요

try{    //..}catch(xx){
    logger.info(..);
}

이렇게 하면 원래 ERROR였던 모든 정보가 INFO 로그 파일에 인쇄되고, 정보를 모르는 동료는 계속 죽게 됩니다. 오류 로그를 보고도 문제를 찾을 수 없으면 작업 효율성에 영향을 미치겠죠?

6 slf4j+logback 조합

로그백 라이브러리를 사용하는 것이 좋습니다. slf4j 인터페이스를 사용하면 중복 어댑터를 도입할 필요가 없으며, 로그백도 이 조합을 사용하는 것이 더 많은 이점이 있습니다. 또 한 가지 주의할 점은 slf4j를 도입한 후에는 실제로 사용되는 로그 라이브러리가 우리가 도입한 것인지, 아니면 타사 종속성 패키지에서 가져온 로그 라이브러리를 사용할 수 있는지 주의해야 한다는 것입니다. 이로 인해 로그가 유효하지 않습니다. .

7. 로그 집계 분석

로그 집계는 분석 및 처리를 위해 여러 서버 간의 로그를 통합할 수 있습니다. 요즘에는 ELK 기술 스택 또는 EFG(fluentd+elasticsearch+grafana)가 있습니다. 등은 비교적 성숙한 오픈 소스 솔루션입니다.

ELK를 예로 들면, 우리 서버의 logstash를 통해 애플리케이션에서 출력한 로그 파일을 직접 읽을 수도 있고, 우리 프로젝트의 로그 구성 파일에서 관련 소켓 정보를 구성할 수도 있습니다. 인쇄하면 로그 정보가 logstash에 직접 출력됩니다. 그런 다음 저장 및 Kibana 표시를 위해 Elasticsearch로 넘겨집니다.

관련 튜토리얼: Java 비디오 튜토리얼

위 내용은 Java 로깅을 올바르게 사용하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!