[LOG] Log4j, LogBack 정리

Log4j 및 LogBack 정리.

 

1. Log4j(Log for Java) 특징

“Log4j” (현재는 Apache Logging Service라는 Top Project)는  “Ceki Gülcü“라는 개발자가 최초로 만들었다.

 

1.1 주요 기능 및 특징

① 속도와 유연성을 고려하여 디자인되었으며, 속도에 최적화 되어 있다.
② 멀티스레드 환경에서 사용해도 안전하다.
③ 계층적인 로그 설정과 처리를 지원한다.
④ 출력을 파일, 콘솔, java.io.OutputStream, java.io.Writer, TCP를 사용하는 원격서버, 원격 Unix Syslog 데몬, 원격 JMS 구독자, 윈도우NT EventLog로 보낼 수 있고, 심지어는 e-mail 로 보낼 수도 있다.
⑤ 계층적인 6가지의 로그 메시지 레벨을 사용한다. (TRACE, DEBUG, INFO, WARN, ERROR, FATAL.)

 

1.2 기능 특성

1.2.1 Log4j 구조

①Logger(Category) : Log4J 에서 지원하는 핵심 클래스로서, 로깅이 일어나는 부분을 그룹화해, 필요한 그룹의 로그만을 출력하거나, 카테고리에 우선순위를 부여함으로써, 여러가지 출력 방법을 지원한다. 실제 로그 기능을 수행하는 역할을 담당한다.

②Appender : 로그의 출력 위치를 지정한다. Appender로 설정 가능한 출력은 콘솔, 파일, OutputStream, java.io.Writer,     Email(SMTP), Network 등이 있다.
    ConsoleAppender : 콘솔에 로그 메시지를 출력한다.
    FileAppender : 파일에 로그 메시지를 출력한다.
    RollingFileAppender : 로그의 크기가 지정한 용량 이상이 되면 다른 이름의 파일을 출력한다.
    DailyRollingFileAppender : 하루를 단위로 로그 메시지를 파일에 출력한다.
    SMTPAppender : 로그 메시지를 이메일로 보낸다.
    NTEventLogAppender : 윈도우의 이벤트 로그 시스템에 기록한다.
③Layout : 로그의 출력 포맷을 지정한다. 단순한 텍스트 출력, 포맷을 직접 지정한 패턴, HTML 문서 형식 등을 사용할 수 있다.
    %d : 로그의 기록시간을 출력한다.
    %p : 로깅의 레벨을 출력한다.
    %F : 로깅이 발생한 프로그램의 파일명을 출력한다.
    %M : 로깅이 발생한 메소드의 이름을 출력한다.
    %l : 로깅이 발생한 호출지의 정보를 출력한다.
    %L : 로깅이 발생한 호출지의 라인수를 출력한다.
    %t : 로깅이 발생한 Thread명을 출력한다.
    %c : 로깅이 발생한 카테고리를 출력한다.
    %C : 로깅이 발생한 클래스명을 출력한다.
    %m : 로그 메시지를 출력한다.
    %n : 개행 문자를 출력한다.
    %% : %를 출력
    %r : 어플리케이션이 시작 이후부터 로깅이 발생한 시점까지의 시간을 출력한다.(ms)
    %x : 로깅이 발생한 Thread와 관련된 NDC(nested diagnostic context)를 출력한다.
    %X : 로깅이 발생한 Thread와 관련된 MDC(mapped diagnostic context)를 출력한다.

 

1.2.2 Log4j의 로깅 레벨 (지정한 것 이상의 레벨메시지가 출력)

① FATAL : 가장 크리티컬한 에러가 일어 났을 때 사용한다.
② ERROR : 일반 에러가 일어 났을 때 사용한다.
③ WARN : 에러는 아니지만 주의할 필요가 있을 때 사용한다.
④ INFO : 일반 정보를 나타낼 때 사용한다.
⑤ DEBUG : 일반 정보를 상세히 나타낼 때 사용한다.
⑥ TRACE : 경로추적을 위해 사용한다.

 

1.3 장단점

1.3.1장점
①프로그램의 문제 파악이 용이하다.
(Problem diagnosis: No matter how well written our code is, there may be some problems hidden in it. As soon as the triggering conditions occur, the hidden problems come to the surface. If our applications have well-written code for logging the internal state of the system, we will be able to detect the problems precisely and quickly.)

 

②빠른 디버깅 가능하다.
(Quick debugging: Once we diagnose the problem, we know exactly how to solve the problem. The logging trace should be aimed at showing the precise location of the problem, which means we will be able to debug the application in less time. Well-planned and well-written logging code greatly reduces the overall cost of debugging the application.)

 

③로그 파악이 쉽다.
(Easy maintenance: Applications with a good logging feature are easy to debug and therefore easy to maintain compared to any application without a similar logging feature. The logging information typically contains more information than the debugging trace.)

 

④로그 이력을 파일, DB등으로 남길 수 있다.
(History: A good logging feature in an application results in logging information being preserved in a structured way at a desired location. The location may be a file, database, or remote machine. All this enables system administrators to retrieve the logging information at a future date by going through the logging history.)

 

⑤효율적으로 디버깅이 가능하다.
(Cost and time savings: As explained, well-written logging code offers quick debugging, easy maintenance, and structured storage of an application’s runtime information. This makes installation, day-to-day maintenance, and debugging much more cost- and time-effective.)

 

1.3.2단점
①로그에 대한 디바이스(파일) 입출력으로 인해 런타임 오버헤드가 발생한다.
(Logging adds runtime overhead due to the generation of logging information and the device Input/Output (I/O) related to publishing logging information.)

②로깅을 위한 추가 코드로 인해 전체 코드 사이즈가 증가한다.
(Logging adds programming overhead due to the extra code required for producing logging information. The logging process increases the size of the code.)

③심하게 생성되는 로그는 혼란을 일으킬 수 있다.
(Badly produced logging information can cause confusion.)

④심하게 생성되는 로그는 어플리케이션 성능에 영향을 미칠 수 있다.
(Badly written logging code can seriously affect the application’s performance.)

⑤개발 중간에 로깅 코드를 추가하기 어렵다.
(Last but not least, logging requires planning ahead, as adding logging code at a late stage of development is difficult.)

 

 

2. SLF4J 로깅 처리

2.0 개요

여러가지 Logger중 무엇을 쓸지 선택 해야하고 또한 기존에 사용하고 있는 logger를 변경하는 작업이 있을 수도 있다. 이때 섞어 쓸 수도 있지만, logging을 제어하려면 하나로 통일 되어야 좋다. 여기서 내가 쓰고 싶은 Logger로 통일하고 싶다면 방법은 SLF4J를 쓰면 간편하다.

 

“SLF4J“는 “로깅 구현체“라기 보다는 “Logging Facade” 이다.
SLF4J는 로깅 Facade이다. 로깅에 대한 추상 레이어를 제공하는것이고 java로 따지면 interface덩어리 라고 볼 수 있다. (artifact이름도 api)

 

“일명 창구 일원화” 패턴인데, “SLF4J“의 API를 사용하면, 구현체의 종류와 상관없이 “일관된 로깅 코드“를 작성할 수있으며,  “Apache Commons Logging“를 사용하다가 “Log4J“로 변경을 할 경우 최소한의 수정으로 구현체를 교체 할수 있다.

 

2.1 dependency

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.7</version>
</dependency>

 

2.2 log4j => logback 전환 방식 설명

LOG4j

log4j-over-slfj.jar  =====================>

SLF4J

logback-classic.jar  =====================>

logback-core.jar LOGBACK

 

logback-core.jar              ::=  logback 코어.

logback-classic.jar           ::=  slf4j에서 logback을 호출할 수 있도록 처리.

log4j-over-slf4j.jar (선택) ::=  log4j 로깅 -> slf4j 전환.

 

적용시 유의할 점

만약 기존에 logback이 아닌 log4j가 slf4j와 연동되어 있을 경우, 반드시 slf4j-log4j12.jar 라이브러리를 제거해야 한다. slf4j-log4j12.jar 라이브러리는 slf4j가 log4j에게 로깅 처리를 호출하는 라이브러리인데, 이 라이브러리가 포함되어 있을 경우 다음과 같은 이슈가 발생한다.
 - slf4j 멀티 바인딩 이슈 발생.
 - log4j-over-slf4j.jar가 포함되어 있을 경우, 순환 오류로 인한 StackOverflowError 발생.

이 문제점들은 써드파티 라이브러리 dependency 추가시에도 발생할 수 있다. 써드파티 라이브러리에 slf4j-log4j12.jar가 dependency가 되어 있을 수 있다. 이 경우 반드시 exclusion을 해줘야 한다.
http://stackoverflow.com/questions/31044619/slf4j-log4j12-vs-log4j-over-slf4j

 

3. Logback

log4j를 토대로 새롭게 만든 Logging 라이브러리다.

slf4j를 통해 연관 라이브러리들이 다른 logging framework를 쓰더라도 logback으로 통합할 수 있다.

Logback을 이용하여 로깅을 수행하기 위해서 필요한 주요 설정요소로는 Logger, Appender, Encoder의 3가지가 있으며 각각은 다음과 같은 역할을 수행한다.

 

3.0 개요

Logback은 구성요소 측면에서 Log4j와 유사한 구조를 가지고 있다. Logback을 이용하여 로깅을 수행하기 위해서 필요한 주요 설정요소로는 Logger, Appender, Encoder의 3가지가 있으며 각각은 다음과 같은 역할을 수행한다.
•Logger : 실제 로깅을 수행하는 구성요소로 Level 속성을 통해서 출력할 로그의 레벨을 조절할 수 있다.
•Appender : 로그 메시지가 출력될 대상을 결정하는 요소
•Encoder : Appender에 포함되어 사용자가 지정한 형식으로 표현 될 로그메시지를 변환하는 역할을 담당하는 요소
Logback에서 설정파일을 작성하는 방법은 크게 두 가지가 있다.
•XML을 이용한 설정방법 : logback.xml로 설정 파일 작성 후 해당 파일을 클래스패스에 위치시킨다.
•Groovy 언어를 이용한 설정방법 : logback.groovy로 설정 파일 작성 후 해당 파일을 클래스패스에 위치시킨다.

 

3.1 장점 (http://logback.qos.ch/reasonsToSwitch.html)

①log4j보다 약 10배 정도 빠르게 수행되도록 내부가 변경되었으며, 메모리 효율성도 좋아졌다.
②log4j때부터 광범위한 테스트를 진행한 경험을 가지고 있으며, logback은 더욱 높은 레벨의 테스트를 통해 검증되었다.
③문서화가 잘 되어 있다.
④설정 파일을 변경하였을 경우, 서버 재기동 없이 변경 내용이 자동으로 갱신된다.
⑤서버 중지 없이 I/O Faliure에 대한 복구를 지원한다.
⑥RollingFileAppender를 사용할 경우 자동적으로 오래된 로그를 지워주며 Rolling 백업을 처리한다.

 

3.2 logback과 slf4j
logback을 사용하기 위해선 slf4j(simple logging facade for java)를 함께 사용해야 한다.

slf4j는 facade 패턴을 적용한 로깅 프레임워크다. facade 패턴은 인터페이스와 비슷한 역할이라 할 수 있다. slf4j와 함께 개발자는 원하는 로깅 라이브러리를 선택해 사용하면 된다. 따라서 slf4j를 사용한다면 개발하면서 로깅 라이브러리 변경이 필요한 경우 쉽게 교체가 가능하다.

(1.3.2의 ⑤개발 중간에 로깅 코드를 추가하기 어렵다. 단점 해결 가능)

 

3.3 Maven dependencies

logback 은 logback-core, logback-classic, logback-access의 3개의 모듈이 있다.
core는 classic과 access의 공통라이브러리.
maven repository를 쓴다면 classic만 추가하면 관련 라이브러리가 추가 된다.

<dependencies>
    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.2.3</version>
    </dependency>
</dependencies>

 

3.4logback.groovy, logback-test.xml, logback.xml

logback.groovy, logback-test.xml, logback.xml resource가 없다면 디폴트 설정 이라는 정보를 출력한다.
만약 모든 설졍이 root classpath에 등록이 되어 있다면. 우선순위 전략을 따르게 된다.
1.logback.groovy 파일을 먼저 찾는다.
2.없다면 logback-test.xml 을 찾는다.
3.그래도 없다면 logback.xml을 찾는다.
4.모두 없다면 기본 설정 전략(BasicConfiguration)을 따른다.

 

3.5 logback 로깅 레벨

log4j와 다르게 5단계라고 하는데 확인해보자...

TRACE라고 선언하면 모든 LEVEL 포함. INFO로 설정하면 info, warn, error 포함
① ERROR : 일반 에러가 일어 났을 때 사용한다.
② WARN : 에러는 아니지만 주의할 필요가 있을 때 사용한다.
③ INFO : 일반 정보를 나타낼 때 사용한다.
④ DEBUG : 일반 정보를 상세히 나타낼 때 사용한다.
⑤ TRACE : 경로추적을 위해 사용한다.

 

3.6 layout

(http://logback.qos.ch/manual/layouts.html 참고)

1.%logger{length} •Logger name의 이름을 축약할 수 있다. {length}는 최대 차릿수
2.%thread •현재 Thread name
3.%-5level •log level -5는 출력 고정폭 값
4.%msg •log message %message은 alias
5.%n •new line

 

3.7 logback 정렬

3.7.1나와 같은경우 log4jdbc-log4j2를 이용하였다.

Dependency 추가

<dependency>
     <groupId>org.bgee.log4jdbc-log4j2</groupId>
     <artifactId>log4jdbc-log4j2-jdbc4</artifactId>
     <version>1.16</version>
</dependency>

 

src/main/resources 폴더에 log4jdbc.log4j2.properties 파일 추가 (logback.xml과 같은 경로)

log4jdbc.spylogdelegator.name = net.sf.log4jdbc.log.slf4j.Slf4jSpyLogDelegator
log4jdbc.dump.sql.maxlinelength=0

 

마이바티스 연동시 설정 변경

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
   <property name="driverClassName" value="com.mysql.jdbc.Driver"></property>

   <property name="driverClassName" value="net.sf.log4jdbc.sql.jdbcapi.DriverSpy"></property>
   <property name="url" value="jdbc:mysql://localhost:3306/db명"></property>
   <property name="username" value="sql아이디"></property>
   <property name="password" value="sql패스워드"></property>
</bean>

이후 다음과 같은 쿼리가

1. SELECT A.GRP_CD , A.GRP_CD_NM , A.GRP_CD_DESC
, A.USE_YN , B.CD , B.CD_NM , B.USE_YN , B.CD_DESC , B.EXP_NM_1 , B.EXP_NM_2 , B.EXP_NM_3 ,
B.EXP_NM_4 , B.REF_CHR , B.REF_NUMR FROM TCOMM_GRP_CD_BAS A , TCOMM_CD_DTL B WHERE 1 = 1 AND
A.GRP_CD = B.GRP_CD AND A.USE_YN = 'Y' AND B.USE_YN = 'Y' ORDER BY A.GRP_CD, B.DISP_PRIR, B.CD
 {executed in 50 msec}

 

다음과같이 정렬 되어짐을 볼 수 있다.

1. SELECT
         A.GRP_CD
       , A.GRP_CD_NM
       , A.GRP_CD_DESC
       , A.USE_YN
       , B.CD
       , B.CD_NM
       , B.USE_YN
       , B.CD_DESC
       , B.EXP_NM_1
       , B.EXP_NM_2
       , B.EXP_NM_3
       , B.EXP_NM_4
       , B.REF_CHR
       , B.REF_NUMR
  FROM
      TCOMM_GRP_CD_BAS A
    , TCOMM_CD_DTL B
  WHERE  1 = 1
  AND    A.GRP_CD = B.GRP_CD
  AND    A.USE_YN = 'Y'
  AND    B.USE_YN = 'Y'
  ORDER BY A.GRP_CD, B.DISP_PRIR, B.CD
 {executed in 43 msec}

 

3.7.2 위와같이 하지 않더라도 톰캣 arguments를 추가하여 정렬 가능하다.

 

톰캣 Open launch Configuration => Arguments에 VM arguments를 추가하여 준다.

-Dlog4jdbc.dump.sql.maxlinelength=0

 

3.8 logback.xml 설정 예제

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="10 seconds">
    <!-- Console Appender -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%-5level]\(%file:%line\) %msg%n</pattern>
        </encoder>
    </appender>

 

<!-- File Appender -->
    <appender name="all" class="ch.qos.logback.core.rolling.RollingFileAppender">
         <file>/logs/admin.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>/logs/admin-%d{yyyy-MM-dd}log</fileNamePattern>
            <maxHistory>60</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
    </appender>

 

 <!-- Logger -->
    <logger name="com" additivity="false">
        <level value="error"/>
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="all"/>
    </logger>

    <logger name="org" additivity="false">
        <level value="error"/>
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="all"/>
     </logger>

 

<!-- Root Logger -->
    <root>
        <level value="info"/>
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="all"/>
    </root>
</configuration>

 

3.9 별첨 - 로그back을사용하였을 경우 이점 (https://beyondj2ee.wordpress.com/2012/11/09/logback-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0-reasons-to-prefer-logback-over-log4j/)

(1) Faster implementation
“LOGBack“은 새롭게 작성 한것이 아니라, 오랫동안 검증된 “LOG4J”의 아키텍쳐 기반으로
 재작성 되었습니다.
특히 성능은 약 10배 정도 빠르게 개선을 했고, 또한 메모리 점유도 보다 적게 사용을 합니다.
역시 성능에 관련된 얘기 입니다.

(2) Extensive battery of tests
위에서 말씀 드렸듯 “새로운 오픈소스” 이지만 , 이미  “Log4j” 시절 부터 수년간 수 많은 광범위한 테스트
 를 진행했고, 더욱더 많은 테스트의 반복 과정을 수행 했습니다.
“Log4j보다 훨씬 뛰어난 가장 큰 이유중 하나“라고 합니다.
그 만큼 “높은 쿼리티“에 대한 자신감을 엿볼수 있습니다.

(3) logback-classic speaks SLF4J natively
“LOGBack“은 크게 3가지 컴포넌트로 구성이 되어 있습니다.
“logback-core“는 말 그대로 핵심 코어 컴포넌트 입니다.
“logback-classic“은 “slf4j“에서 사용이 가능하도록 만든 플러그인 컴포넌트 입니다.
“logback-access“는 사용하는 어플리케이션이 “웹 어플리케이션“일 경우 빛을 바라는
 컴포넌트 입니다.” HTTP 요청에 대한 강력한 디버깅 기능을 제공 합니다.”

(4) Extensive documentation
“오픈소스 선택“에 있어서 레퍼런스 메뉴얼은 상당히 중요한 포인트 입니다.
“LOGBack“은 지속적이면서, 상세한 메뉴얼을 제공 합니다.

(5) Configuration files in XML or Groovy
logging 설정에 대한 syntax는 기본적으로 “XML” 형태로 되어 있습니다.
또한 Groovy의 “syntax” 를 지원 합니다.

(6) Automatic reloading of configuration files
개인적으로 호감이 가는 기능중 하나 입니다. 일하는 도메인 마다 틀리겠지만
 기본적으로 “운영 서버” 모드에서는 로그레벨을 “WARN” 또는 “ERROR” 입니다.

하지만 만약 운영중에 좀더 상세한 로그를 보기 원할 경우가 있습니다.
예를 들어서 “INFO” 레벨로 변경하는 경우 입니다.

“log4j” 같은 경우는 다음과 같이  “서버를 셧다운 -> 재설정 -> 서버 기동” 의
 절차로 진행을 합니다. 즉, 핵심 포인트는 “서버를 재기동” 해야 한다는 것입니다.

이러한 매커니즘은 “내부 스캐닝하는 별도의 쓰레드“가 감지를 하기 때문 입니다.
하지만 이런 “스캐닝 쓰레드”는 메모리에 대한 점유율을 최소화 하며,
심지어 “100개의 쓰레드가 초당 백만 invocation“을 발생해도 시스템에
 크게 무리를 주지 않는 다고 합니다.

주로 이런 기능은 “WAS에서 동장하는 웹 어플리케이션“에서 많이 사용이 될듯 합니다.

(7) Graceful recovery from I/O failures
“Log4j” 같은 경우  “JDBC” , “Socket“등 다양한 “Appender“를 지원 합니다.
특히. 대다수의 환경에서는 “File”에 제일 많이 로그를 저장 할 것입니다.

하지만 만약 “파일 서버가 일시적으로 장애가 발생 할경우” , “파일 서버가 복구 될때까지”
 “어플리케이션을 중지 시켰다가” 다시 파일 서버가 복구되면, 그때 서버를 재기동 할것 입니다.
하지만 “LOGBack“은 “서버 중지 없이, 이전 시점부터 복구를 graceful “하게 지원을 합니다.

(8) Automatic removal of old log archives
대부분 환경에서는 “하나의 파일”에 기록하는 것이 아니고, “특정 시간” 또는 “특정 파일 사이즈”
로 “Rolling” 해서 “Archiving“을 할 것입니다.

하지만 “Archiving된 로그 파일“을 계속 유지하지 않고, 일정 기간 지나면
“서비스에  부담을 주지 않기 위해서” 파일을 삭제 할것 입니다.

이럴경우 “Crontab” 또는 다른 삭제 스케줄러를 설정 또는 개발을 할것입니다.
“LOGBack“은 “maxHistory“라는 설정 정보를 통해서 주기적으로 “Archive”
파일을 자동 삭제 합니다.
“maxHistory“의 값이 “12“일 경우, “12개월 이후 삭제 하라는” 뜻입니다.

(9) Automatic compression of archived log files
“Archived Log File“를 만들때 비동기적으로 롤링 할 동안
 자동 압축을 실행 합니다. 심지어 파일 용량이 커도, 또한
 이러한 압축 작업은 어플리케이션을 block 시키지 않습니다.

(10) Prudent mode
만약 하나의 서버에서 “다수의 JVM“이 기동중일 경우 “하나의 파일“에
 로그를 수집하려고 할때 사용하는 기능 입니다.

즉, “Log Aggregation” 기능 입니다. 조금만 아이디어를 내면, 매우 유용하게
 사용이 가능 합니다.
다만 서로 쓰레드간 writing 할때 경합이 생기기 때문에 대량의 데이터를 사용할때
 는 다소 피해야 합니다.

그렇기 때문에 반드시 해당 옵션을 적용시 “LOGBack” 메뉴얼을 참고 하시기 바랍니다.

(11) Lilith
“Lilith“은 “현재 발생하는 로그 이벤트에 대한 상태 정보를 볼수 있도록 지원 하는
뷰어” 입니다.
“log4j“를 지원하는 “chainsaw” 와 비슷한 기능을 합니다. 다만 차이점은 “Lilith”
 “Large data“를 지원 합니다.

(12) Conditional processing of configuration files
빌드를 해본 사람이라면 아실듯 합니다. 빌드시 제일 골치가 아픈 것이 “config” 정보 와
“log file path” 입니다.
이유는 어플리케이션이 구동하는 환경이 “로컬, staging, cbt” 마다 틀리기 때문 입니다.
이런점을 해결 하기 위해서 “Maven Filter” 기능을 사용 하거나,  “JVM -D환경변수“를
 통해서 각 환경 마다 선택적으로 “log 설정파일“을 선택하도록 구성을 할 것입니다.

“LOGBack“은 이런 이슈를 좀더 “Graceful“하게 지원을 합니다.
“JSTL” 같이 분기 스크립트 (<if>, <then> and <else>)를 제공해서 하나의 파일
 에서 다양한 빌드 환경을 제공 하도록 지원을 합니다.

(13) Filters
“Filter” 기능은 “Log4j“에서 지원하는 기능입니다. 주 기능은 “로깅을 남길지 , 말지를”
핸드링 할수 있는 기능 입니다.
좀더 이해를 돕기 위해서 “UseCase“를 설명 드리겠습니다.

만약 “A“라는 사용자에게 비즈니스적으로 문제점이 발견이 되었습니다.
이럴경우는 “logical exception“이기 때문에 원인을 잡기가 쉽지가 않습니다.
또한 현재 “운영 서버“의 “Log LEVEL“이 “ERROR“일 경우 로그를 확인 할수가 없을
 것입니다.
더우기 “운영 서버 logical exception“은 “staging” 환경과 데이터가 틀리기 때문에
 실제 운영 로그를 확인하지 않고서는 재현을 할수가 없습니다.

그래서 “운영 서버의 로그 레벨“을   “DEBUG“로 수정합니다. 하지만 로그는 보이지만 전체 사용자가
 해당이 되기 때문에 로그 데이터를 분석하기가 어렵습니다.
이럴 경우 “Filter“를 사용해서 “다른 사용자“는 “ERROR” 레벨을 유지하고,
“A” 사용자만 “DEBUG“로 설정을 하면, 분석하는데 많은 도움을 받을 수 있습니다.

(14) SiftingAppender
“SiftingAppender“는 “Filter“의 기능과 유사하면서 다른 기능을 제공 합니다.
“로그 파일을 특정 주제별로 분류“를 할 수 있도록 합니다.
예를 들어서 “HTTP Session“별로 로그 파일을 저장한다거나, “사용자별“로 별도의 로그파일을
 저장 할 수 있습니다.

(15) Stack traces with packaging data
자바 어플리케이션에서 “Exception“이 발생을 하면 “Stack Trace“를 출력을 합니다.
자바는 “Exception” 정의가 잘되어 있어서 쉽게 “디버깅“을 할 수 있습니다.

하지만 제일 디버깅이 힘든 것중 하나가 “라이브러리에 의한 Exception” 입니다.
이럴 경우 “LOGBack“은 Exception 발생시 참조 했던 외부 라이브러리 버전을
 출력하게 해줍니다.

 

(16) Logback-access, i.e. HTTP-access logging with brains, is an integral part of logback
위에서 언급했듯이 “logback-access“는 “웹 어플리케이션” 사용시 유용한 툴로써 제공 됩니다.
특히나 요새는 전통적인 “HTML” 출력이 아닌 “REST 서버“로써의 역할을 많이 합니다.
이럴 경우 “HTTP 디버깅“을 제공 합니다.
Conclusion

지금 까지 간략하게 “LOGBack” 기능을 살펴 봤습니다.
이외에 유용하고, 멋진 기능들이 많이 있습니다.
“logging“의 중요함은 지나치게 말씀을 드려도 지나치지 않습니다.
특히나 “클라우드 빅데이터” 시대에서 “logger“는 바로 최초 시작점 입니다.

제일 궁금했던 것이 “log4j를 만든 사람이 왜 ? logback를 만들었을까?” 입니다.

개인적 생각은 “log4j“를 “하위 호환성을 유지하면서 큰 리팩토링을 하기에는 다소 부담감”
과 “상용 버전을 위한 비즈니스적 관점“이 아닐까 조심 스럽게 말씀 드리고 싶습니다.

“LOGBack“의 큰 매력은 “Log4J 와 상당히 친숙함” 일것입니다. 이말은 그 만큼 사용하는데
 있어서 낯설지 않다는 얘기 입니다.
심지어 “log4j.properties“를 “logback.xml” 설정 파일로 변환하는 “웹 변환기“도 제공 합니다.

또한 “SLF4J“를 지원하기 때문에 마음에 들지 않으면 “언제든지 다른 로거로 swiching“이 가능 합니다.