[Rundeck] Rundeck 로그 정리

[Rundeck] Rundeck 로그 정리

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 RUNDECK 로그 정리하는 방법에 대해서 포스팅을 하고자 합니다. 우선, 로그를 정리하게 된 이유는 어느순간 Rundeck이 엄청나게 느려지는 시점이 있었습니다. 웹에 접속이 불가할정도로 퍼포먼스가 나질 않았습니다.

그래서 확인해보니, Rundeck에 로그들이 Rotaion이 안되고, 계속해서 쌓이고 있었습니다. 로그 용량 자체가 18G에 달할 정도로 엄청나게 차지하고 있어서, rotaion혹은 정리가 필요해 보였습니다.

런덱 관련된 포스팅은 아래와 같이 정리되어있으니, 참고하시기 바랍니다.

1.런덱 설정 파일

1.런덱 설정 파일

런덱 같은 경우는 /etc/rundeck 하위에 설정파일을 갖고 있습니다. 그중에서도 아래 파일에서 로그가 어디로 쌓이는지를 확인하시면됩니다.

  • framework.properties

전체적인 프레임워크엗대한 셋팅을 진행하는 파일입니다. 여기서 중간에 log를 설정하는 위치가 있습니다.

  • log4j.properties

다음과 같은 자료에 보시면, log4j에서 rotaion에 대한 셋팅을 하도록 가이드 되어있습니다. 아직 시도는 안해보았지만, 로그에 대한 셋팅이 버전이 맞는지도 체크해봐야될것 같습니다.

런덱 log4j 로테이션 설정

  • rundeck-config.properties

런덱 설정 파일중 이 파일은 DB연결을 담당하고 있습니다. 필자같은 경우는 AWS RDS로 mysql 을 연결해두었습니다.

2. 런덱 로그 정리

상위의 로그 PATH가 셋팅된대로, /deploy/rundeck/logs의 용량을 체크해보았습니다.

무려 로그가 18.1 G 나 차지를 하고있었고, 로그를 불러오면서, 계속해서 application이 느려지는 현상이 있었습니다.

logs폴더 하위로는 다음의 로그파일들이 있습니다.

  • rundeck.access.log
  • rundeck.api.log
  • rundeck.executions.log

그 외에 더 많은 로그들이 있지만, 중요하게 봐야될 것은 3가지 인것 같습니다. 주로, excutions에 대한 로그가 많이 쌓였습니다. 아무래도 job을 수행하고 그 결과에 대한 내용을 계속해서 저장하는것 같았습니다.

우선 rotaion이 안되는 저위의 로그들을 정리를 했습니다. 그런데 기껏해봐야 gb 단위로는 용량이 줄어들지 않았습니다.

대체 무슨일이 생긴걸까요? 🤔

용량을 많이 차지하는 부분은 logs 폴더 하위에 rundeck이라는 폴더에서 많이 차지하고있었습니다. 들어가서 확인해보니, 각 job에 대한 수행내용을 참조값 형식으로 남겨두었고, 실제 값들은 mysql에 대해서 uuid 형식으로 조회를 해서 가져오는 식으로 되어있었습니다.

실제로 job이라는 폴더 하위에 생성되는 로그들이 굉장히 큰값을 갖고 있었습니다.

그래서 job하위를 삭제 해주고 재기동 해주는 방식으로 로그를 정리했습니다.

  1. 각 프로젝트 job 폴더 하위 내용 삭제 (ex /deploy/rundeck/logs/rundeck/{특정 프로젝트}/job)
  2. 모두 수행후 , 런덱 재기동

3. 런덱 로그 정리 자동화

실제로 위의 내용을 수동으로 진행은 해주고 있지만, mysql에 대한 내용은 정리가 되지 않습니다. mysql 에 정리되는 부분은 실제로 rundeck application에서 보시면, reports를 해주는 부분이 저장되고 있습니다.

위의 내용을 하나씩 정리해보겠습니다.

  1. 런덱 job 수행 이력 아이디 추출

상위 결과를 수행하면 아래와 같은 결과가 나옵니다.

  1. id 추출

for문 안쪽을 보시면, id를 추출하고, 4b0343e5-e51c-4d13-b258-a1ff9964b404 이런식으로 추출이됩니다. 그러면, 이게 MYSQL의 db table의 키가 되어 각 테이블에 접근하여 DELETE를 수행합니다.

  1. JOB폴더 하위 삭제

중간에 보시면, job 폴더하위의 내용을 삭제 하는 부분이 있습니다. 위에서 수동으로 해줬던 부분입니다.

  1. mysql DB 데이터 삭제

excution, base_port, workflow 에서 jobid기반으로 삭제를 해주고, workflow step같은 경우는 1개의 job이 여러개의 w/f step으로 구성될수 있기 때문에 for문을 돌면서 삭제를 해줍니다.

4. 마치며…

런덱에 대한 rotation에 대한 이슈가 구글에서 검색을 해보면 많이 노출이 됩니다. 실제로 log rotaion이 다 셋팅되어있음에도 불구하고, log4j.properties에 영향을 받는것인지 정확하게 로테이션이 안됩니다. 우선 위의 내용들을 하나씩 테스트를 진행해볼 예정입니다.

계속해서 수동으로 삭제를 해줄 수도 없는 부분이기에 자동화를 할 수 있으면 해야될 것 같습니다. MYSQL도 용량이 계속해서 쌓여가기 때문에 삭제 처리를 하는것이 어떤지 팀원들에게 공유를 할예정입니다.

다음시간에는 런덱에 대한 플러그인을 정리해보려고 합니다. 런덱 커뮤니티가 아직 그렇게 활성화가 많이 되지 않아서, 플러그인이 많지는 않지만 필수적으로 설치해서 사용할만한 것들을 정리하고자 합니다. 많은 기대 부탁드립니다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다