Jenkins Log Parser 사용해서 Application 오류 처리하기

엄청나게 편리한 Jenkins이지만 불편한점도 있다. 예를 들자면 Jenkins를 이용해 batch를 처리할때 분명 batch job은 내가 원하는대로 수행되지 않고 Error가 발생했는데 Jenkins job은 이를 Success 처리를 하는 경우이다. 오류가 발생을 하면 slack이든 email이든 noti를 보내야 하는데 오류가 발생하지 않았다고 판단하여 아무런 후속조치를 하지 않는다. 이럴 경우에 Log Parser 라는 Jenkins plugin을 사용해서 해결할 수 있다. 설치부터 어떻게 사용하는지 알아보자. 

---

Jenkins Log Parser 설치

Jenkins Log Parser

Jenkins 관리 > 플러그인 관리 > 설치 가능 > Log Parser 선택 > 재시작 없이 설치하기 

 

 

Log Parser Rule 파일 생성 (log_parser_sample.rule)

ok /not really/

# match line starting with 'error ', case-insensitive
# error /(?i)^error /
error /ERROR/

# list of warnings here...
warning /[Ww]arning/
warning /WARNING/

# create a quick access link to lines in the report containing 'INFO'
info /INFO/

# each line containing 'BUILD' represents the start of a section for grouping errors and warnings found after the line.
# also creates a quick access link.
start /BUILD/

 

참고 : plugins.jenkins.io/log-parser/

적당한 위치에 log_parser_sample.rule 파일을 생성한다. 공홈에 나온대로 일단 작성을 하였다. 

작성규칙은 다음과 같다. 

 

파일의 각 행은 레벨 (ok / error / warn / info / start) 및 슬래시 ("/")로 구분 된 정규식 ( java.util.regex.Pattern 기반 )을 지정하여 해당 레벨과 일치하는 라인을 찾는다.

• ok / error / warn
  문제 라인을 식별하는 데 사용된다.

• info
  console에서 파란색으로 강조 표시된다. 특정 섹션에 빠르게 액세스 할 수 있도록 console에 링크 집합을 만드는 데 사용된다.
• start
  info와 마찬가지로 console에서 파란색으로 강조 표시되고 console에 대한 빠른 액세스 링크 집합에 나타난다. 또한 해당 섹션에서 발견 된 오류 및 경고 목록을 그룹화하는 데 사용된다.

 

 

 

Jenkins Log Parser 설정

Jenkins 관리 > 시스템 설정 > Console Output Parsing 에서 만들어 놓은 rule 파일을 매핑시켜준다. 

 

 

Jenkins Job에 Log Parser 적용

일단 Log Parser가 어떤 방식으로 동작하는지 알아보기 위해 maven project를 build 하는 job을 하나 만들어 보도록 하겠다. 

 

 

maven 빌드를 수행하고 빌드 후 조치 부분에 위와 같이 Console ouput (build log) parsing 을 선택한다. 

 

 

1. "Mark build Unstable on Warning"옵션 : 구문 분석 된 경고가 빌드를 'Unstable'으로 표시하도록 선택
2. "Mark build Failed on Error"옵션 : 구문 분석 된 오류가 빌드를 'Failed'로 표시하도록 선택
3. "Select Parsing Rules":이 작업의 빌드 로그를 구문 분석하는 데 사용할 규칙 세트를 선택
   (이 목록은 전역 구성에서 파생됨에 유의).

위의 설정의 뜻을 풀어서 설명하자면 "log_parser_sample 이라는 global rule을 사용할 것이고 Console output 으로 Waning이 나오면 Unstable 상태로 표시하고 Error가 나오면 Failed 처리를 하겠다는 것이다. 

 

이렇게 설정을 하고 저장하고 Jenkins job을 실행시켜보자. 

 

 

빌드를 하고 나면 이전과는 다르게 좌측에 Console Output (parsed) 라는것이 보일것이다. 이걸 클릭해보자. 

그럼 우측에 빌드한 결과가 parsing이 되어서 나온다. Error, Waning, Info 등 각 항목별로 검출된 결과를 확인할 수 있다. 

현재는 오류가 나지 않는 프로젝트 빌드를 하는 작업을 수행했기에 Console Log를 Parsing을 해도 오류에 대해서는 검출이 되지 않는다. 

 

 

위의 화면은 빌드하는 과정에 오류가 발생하도록 한 경우다. 빌드가 되다가 오류가 발생해서 Console log에 ERROR이라는 단어가 찍혔고 Log Parser가 rule에 따라 이를 인지하고 Error로 수집을 했다. 

 

 

사실 위와 같은 test는 큰 의미는 없다. 왜냐면 이건 Jenkins Job도 문제로 인식을 하고 있는것이고 실패한 결과가 Failed로 떨어지기 때문이다. 문제는 application runtime에 발생한 Error이다. application 내부적으로 발생한 오류를 Jenkins가 Fail로 인식을 하게 하는게 지금 하고 있는 일의 목적이다. 

 

 

테스트를 하려고 하는 batch job에서 error 로그를 찍어준다. 강제로 error 로그를 생성하기 위함이다. 

 

 

실제로 해당 batch job 을 돌려봐도 분명 application 실행 로그에는 ERROR라고 명시가 되어 있음에도 불구하고 Jenkins는 SUCCESS로 Finished 한것을 볼 수 있다. 이 부분이 문제라는 말이다. 물론 이것은 log parser를 적용하지 않은 Jenkins Job이다. 

 

 

이 batch job에 Log Parser를 적용하고 다시 실행을 시켜보자. Console Log에 ERROR라고 나오면 Jenkins Job도 FAILURE로 종료를 하게 된다. 목적을 달성했다. 이제 이 Jenkins Job은 실패했으므로 실패한 경우에 email이나 slack 등으로 noti를 보낼 수 있게 되었다. 

 

 

Console Output (parsed) 에 들어가서 보면 Error가 발생한 부분에 대해서만 명확하게 볼 수 있다. 

글은 길게 썼지만 아주 간단하게 내가 원하는대로 결과를 컨트롤 할 수 있다. 자신의 application에 맞게 rule을 잘 지정한다면 더 좋은 결과를 도출해 낼 수 있다. 

 

끝!