2.1 첫 번째 로거 - log4j
이미 알고 있듯이 로그의 히스토리는 System.err.println()레코드를 콘솔에 출력하는 것으로 시작되었습니다. 예를 들어 Intellij IDEA는 이를 사용하여 콘솔에 오류 메시지를 표시합니다. 그러나이 옵션에는 설정이 없으므로 계속 진행하겠습니다.
최초이자 가장 인기 있는 로거는 Log4j. 훌륭하고 고도로 사용자 정의 가능한 솔루션이었습니다. 다양한 상황으로 인해 이 결정은 JDK에 전달되지 않았고 전체 커뮤니티를 크게 화나게 했습니다.
이 로거는 단순히 로깅만 하는 것이 아니라 프로그래머가 프로그래머를 위해 만들어서 로깅과 관련하여 끊임없이 발생하는 문제를 해결할 수 있도록 해주었습니다.
이미 알고 있듯이 로그는 마지막에 작성되므로 어떤 사람이 로그를 읽고 프로그램 작동 중에 발생한 일(예상한 대로 무엇이 언제 잘못되었는지)을 이해하려고 시도합니다.
log4j이를 위해 세 가지가 있었습니다 .
- 서브패키지 로깅;
- 어펜더 세트(결과);
- 핫 리로드 설정.
log4j첫째, 한 패키지에서는 로그인을 활성화하고 다른 패키지에서는 비활성화하는 방식으로 설정을 작성할 수 있습니다. com.codegym.server예를 들어 에서는 로그인을 활성화 하고 에서는 비활성화 할 수 있었습니다 com.codegym.server.payment. 이를 통해 로그에서 불필요한 정보를 빠르게 제거할 수 있었습니다.
둘째, log4j한 번에 여러 로그 파일에 로깅 결과를 쓸 수 있었습니다. 그리고 각각에 대한 출력을 개별적으로 구성할 수 있습니다. 예를 들어, 한 파일에는 심각한 오류에 대한 정보만 기록할 수 있었고, 다른 파일에는 특정 모듈의 로그, 세 번째 파일에는 특정 시간 동안의 로그를 기록할 수 있었습니다.
따라서 각 로그 파일은 특정 유형의 예상 문제에 맞게 조정되었습니다. 이것은 기가바이트 로그 파일을 수동으로 살펴보는 것을 좋아하지 않는 프로그래머의 삶을 크게 단순화합니다.
마지막으로 세 번째로 log4j프로그램을 다시 시작하지 않고도 프로그램이 실행되는 동안 로그 설정을 직접 변경할 수 있습니다. 이것은 특정 오류에 대한 추가 정보를 찾기 위해 로그 작업을 수정해야 할 때 매우 편리했습니다.
중요한! 로그에는 1.2.x와 2.xx의 두 가지 버전 log4j이 있으며 서로 호환 되지 않습니다 .
다음 코드를 사용하여 로거를 프로젝트에 연결할 수 있습니다.
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.17.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.2</version>
</dependency>
</dependencies>
2.2 최초의 공식 로거 - 7월: java.util.logging
Java 커뮤니티에 로거 동물원이 등장한 후 개발자는 JDK모두가 사용할 하나의 표준 로거를 만들기로 결정했습니다. 다음은 로거가 나타난 방식 입니다 JUL.java.util.logging
log4j그러나 개발 과정에서 로거 작성자는 가 아니라 개발에 영향을 준 IBM의 로거 변형을 기반으로 했습니다 . 좋은 소식은 로거가 JUL포함되어 있다는 것입니다 JDK. 나쁜 소식은 사용하는 사람이 거의 없다는 것입니다.
개발자는 "또 다른 보편적인 표준"을JUL 만들었을 뿐만 아니라 당시 인기 있는 로거가 허용한 것과는 다른 자체 로깅 수준도 만들었습니다.
그리고 그것은 큰 문제였습니다. 결국 제품은 Java종종 많은 라이브러리에서 수집되며 이러한 각 라이브러리에는 자체 로거가 있습니다. 따라서 애플리케이션에 있는 모든 로거를 구성해야 했습니다.
로거 자체는 꽤 좋지만. 로거 생성은 거의 동일합니다. 이렇게 하려면 다음을 가져와야 합니다.
java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());
로깅이 어디서 오는지 알기 위해 클래스 이름이 특별히 전달됩니다.
릴리스에서만 개발자는 중요한 문제를 해결했으며 그 후에는 JUL사용하기가 정말 편리합니다. 그 전에는 일종의 이류 로거였습니다.
이 로거는 람다 식과 지연 평가도 지원합니다. 로 시작하면 Java 8통과할 수 있습니다 Supplier<String>. 이렇게 하면 이전과 같이 매번이 아니라 실제로 필요한 순간에만 문자열을 읽고 생성하는 데 도움이 됩니다.
인수가 있는 메서드는 Supplier<String> msgSupplier다음과 같습니다.
public void info(Supplier msgSupplier) {
log(Level.INFO, msgSupplier);
}2.3 첫 번째 로거 래퍼 - JCL: jakarta commons 로깅
오랫동안 로거들 사이에 단일 표준이 없었고 JUL하나가 되어야 했지만 더 나빴습니다 log4j. 그래서 단일 표준은 나타나지 않았습니다. 그러나 각각 동일 해지고 싶어하는 로거 동물원 전체가 나타났습니다.
그러나 일반 Java 개발자는 거의 모든 라이브러리에 자체 로거가 있고 특별한 방식으로 구성해야 하는 점을 좋아하지 않았습니다. 따라서 커뮤니티는 다른 로거 위에 특수 래퍼를 만들기로 결정했습니다.JCL: jakarta commons logging
그리고 다시, 리더가 되기 위해 만들어진 프로젝트는 하나가 되지 않았습니다. 승자를 만들 수는 없고 승자가 될 수만 있습니다. 기능이 JCL매우 열악했고 아무도 사용하고 싶어하지 않았습니다. JUL모든 로거를 대체하도록 설계된 로거는 사용되지 않은 것과 같은 운명을 맞이했습니다 .
Apache 커뮤니티에서 출시한 많은 라이브러리에 추가되었지만 로거의 동물원은 성장했습니다.
2.4 첫 번째 마지막 로거 - 로그백
하지만 그게 다가 아닙니다. 개발자는 log4j자신이 가장 똑똑하다고 판단하고(결국 대부분의 사람들이 그의 로거를 사용했습니다) log4j다른 로거의 장점을 결합한 새로운 개선된 로거를 작성하기로 결정했습니다.
새 로거는 Logback. 모두가 사용할 미래의 단일 로거가 될 것으로 예상되는 것은 바로 이 로거였습니다. 에서와 동일한 아이디어를 기반으로 했습니다 log4j.
다음 코드를 사용하여 이 로거를 프로젝트에 연결할 수 있습니다.
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.6</version>
</dependency>차이점은 다음과 같습니다 Logback.
- 향상된 성능;
- 기본 지원 추가
slf4j; - 확장된 필터링 옵션.
이 로거의 또 다른 장점은 매우 좋은 기본 설정을 가지고 있다는 것입니다. 그리고 로거에서 무언가를 변경하려는 경우에만 로거를 구성해야 했습니다. 또한 설정 파일은 기업 소프트웨어에 더 잘 적용되었습니다. 모든 구성이 xml/.
기본적으로 Logback설정이 필요하지 않으며 수준 이상의 모든 로그를 기록합니다 DEBUG. 다른 동작이 필요한 경우 xml구성을 통해 구성할 수 있습니다.
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>app.log</file>
<encoder>
<pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern>
</encoder>
</appender>
<logger name="org.hibernate.SQL" level="DEBUG" />
<logger name="org.hibernate.type.descriptor.sql" level="TRACE" />
<root level="info">
<appender-ref ref="FILE" />
</root>
</configuration>2.5 최신 범용 로거 - SLF4J: Java용 단순 로깅 파사드
황금률을 찾는데 얼마나 걸릴까요...
2006년에 제작자 중 한 명이 log4j프로젝트를 떠나 범용 로거를 만들기 위해 다시 시도하기로 결정했습니다. 그러나 이번에는 새로운 로거가 아니라 서로 다른 로거가 함께 상호 작용할 수 있도록 하는 새로운 범용 표준(래퍼)이었습니다.
이 로거는 , , 를 slf4j — Simple Logging Facade for Java둘러싼 래퍼였습니다 . 이 로거는 로거 동물원을 관리하는 실제 문제를 해결하여 모두가 즉시 사용하기 시작했습니다.log4jJULcommon-loggins and logback
우리는 스스로 만든 문제를 영웅적으로 해결합니다. 보시다시피 래퍼 위에 래퍼를 생성한 지점까지 진행되었습니다...
랩 자체는 두 부분으로 구성됩니다.
API, 응용 프로그램에 사용됩니다.- 각 로거에 대해 별도의 종속성으로 추가되는 구현입니다.
다음 코드를 사용하여 로거를 프로젝트에 연결할 수 있습니다.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.17.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.17.2</version>
</dependency>올바른 구현을 연결하는 것으로 충분하며 그게 전부입니다. 전체 프로젝트가 함께 작동합니다.
2.6 slf4j의 최적화
Slf4j로깅을 위한 문자열 형식 과 같은 모든 새로운 기능을 지원합니다 . 그 전에 이런 문제가 있었습니다. 로그에 메시지를 인쇄하고 싶다고 가정해 보겠습니다.
log.debug("User " + user + " connected from " + request.getRemoteAddr());이 코드에 문제가 있습니다. 응용 프로그램이 작동하고 production로그에 아무것도 쓰지 않는다고 가정 DEBUG-messages하지만 메서드는 log.debug()계속 호출되며 호출 시 다음 메서드도 호출됩니다.
user.toString();request.getRemoteAddr();
이러한 메서드를 호출하면 애플리케이션 속도가 느려집니다. 해당 호출은 디버깅 중에만 필요하지만 어쨌든 호출됩니다.
논리의 관점에서 이 문제는 로깅 라이브러리 자체에서 해결해야 했습니다. 그리고 log4j의 첫 번째 버전에서 솔루션이 나타났습니다.
if (log.isDebugEnabled()) {
log.debug("User " + user + " connected from " + request.getRemoteAddr());
}로그에 대한 한 줄 대신 이제 세 줄을 작성해야 했습니다. 코드의 가독성을 극적으로 악화시키고 log4j.
로거는 slf4j스마트 로깅을 제공하여 상황을 약간 개선할 수 있었습니다. 다음과 같이 생겼습니다.
log.debug("User {} connected from {}", user, request.getRemoteAddr());여기서 는 {}메서드에 전달된 인수의 삽입을 나타냅니다. 즉, 첫 번째는 {}사용자에 해당하고 두 번째는 {}에 해당합니다 request.getRemoteAddr().
이러한 매개변수는 로깅 수준이 로깅을 허용하는 경우에만 단일 메시지로 연결됩니다. 완벽하지는 않지만 다른 모든 옵션보다 낫습니다.
그 후 SLF4J인기가 급격히 높아지기 시작했으며 현재 이것이 최상의 솔루션입니다.
따라서 번들을 예로 들어 로깅을 고려해 보도록 하겠습니다 slf4j-log4j12.