로그를 잘 남기자

지금 다니는 회사에서 백엔드 개발자로 일 한지 4개월 정도 되었다. 로그를 남기는 것에 대해 짧게 이야기를 해본다.

사수님이 보는 나의 모습이 이럴까...

 최근 암호화폐 가격 정보를 다루는 새 프로젝트를 진행하게 되었다. 데이터를 저장하기 위해 crontab에서 작업을 등록하고 실행된 프로그램의 로그를 저장하면서 느낀 점과 로그를 저장하는 더 나은 방법에 대해 이야기해보려고 한다.

 

Crontab

cron은 시간 기반 작업 스케줄러이다. 주어진 스케줄에 따라 정기적으로 실행되는 쉘 명령을 지정하는 구성 파일인 crontab (cron table)에 의해 구동된다. crontab에 쉘 명령을 적어 놓으면 해당 시간에 해당 작업이 실행된다.

 

crontab으로 여러 가지 작업들을 할 수 있다. 외부 API를 이용해 매 분 데이터를 받아와서 저장하거나, 매일 자정에 특정 항목을 갱신하거나, 수정한 지 오래된 파일을 삭제하는 등 정기적으로 해야 하는 작업들을 crontab에 등록하여 원하는 시간에 작업이 수행되도록 등록할 수 있다.

 

crontab에 대한 기본적인 내용들은 아래 링크에서 확인 가능. 명령어와 어떻게 시간을 지정하는지 자세히 나와있다.

- https://kb.iu.edu/d/afiz

 

Log

내가 만든 cron이 제시간에 실행됐는지 확인하고 싶다면 로그를 저장하는 것이 가장 기본적인 방법이다. 로그를 남기는 건 할 수 있는 가장 쉽고 정확한 방법이다.

 

현 상황

flask에 app.logger를 이용해 로그를 남기고 있다. crontab 작업이 원하는 대로 수행되지 않아 문제 파악을 위해 로그를 보니, 지금까지 쌓은 로그들이 큰 도움이 안 됐다.

 

외부 API를 호출하여 그 데이터를 저장한다. 이때 데이터가 쌓이지 않았는데, 외부 API 호출에 문제가 있었는지 아니면 데이터를 계산하는 과정(내부 로직)에서 문제가 있었던 건지 알 수가 없었다.

 

로그를 한 파일에만 저장을 했는데, 이것도 큰 문제였다. 과거 데이터를 지우지 않으면 파일 용량이 한없이 커진다. 그 파일을 열어서 검색하거나 grep 명령어로 검색할 때 조회할 데이터가 너무 많아서 시간이 오래 걸린다. 심한 경우는 아래 사진처럼 로그 파일이 계속 쌓여서 90%까지 찬다. 다행히도 서버 모니터링 알람을 해놔서 큰일이 나기 전에 로그 파일들을 정리했다. 

disk 용량 터져욧!!! y축이 disk사용량, x축이 시간이다.

변경한 것들

1. 로그 파일 디렉토리 구조 변경

기존에는 logs 디렉토리 한 곳에 모든 파일을 다 저장했는데, 지금은 작업의 성격에 따라 logs 아래에 폴더별로 저장했다. 로그 파일명에 날짜를 남겨 원하는 날짜의 데이터만 조회할 수 있다. 

# 기존 방식 예시
logs
    - food.log
    - sports.log
    - fruit.log
    

# 변경한 방식 예시
logs
    - food
    	- chicken_update_2020-06-25.log
        - pizza_update_2020-06-25.log
    - sports
    	- soccer_update_2020-06-25.log
        - baseball_update_2020-06-25.log
    - fruit
    	- apple_update_2020-06-25.log
        - melon_update_2020-06-25.log

 

2. 디스크 용량을 위해 오래된 로그 파일은 삭제한다. 나는 수정한 지 7일이 지난 파일은 삭제하도록 했다. 7일은 정해진 것은 아니고 통상적으로 문제 발생 시 바로 처리하기 때문에 짧게 7일로 설정했다.

# Delete files that have not been modified for 7 days
0 0 * * * find /home/ubuntu/log/ -mtime +7 -type f -ls -exec rm -f {} \;

크론탭에 위와 같은 작업을 추가하면 된다. 저 명령은 /home/ubuntu/log/ 디렉토리에서 수정한 지 7일이 지난 파일을 찾아 삭제하는 일을 한다.

 

3. 파일 이름을 자동완성을 고려하여 명명했다.

예를 들어, 2020년 6월 25일, 치킨에 대한 정보를 업데이트하는 작업에 대한 로그 파일 이름은 'chicken_update_2020-06-25.log'라고 했다. 예전에 food.log한 곳에 chicken과 pizza 로그 모두 저장한 것에 비해 작업의 성별로, 날짜별로 나눠서 로그를 볼 수 있어서 편하다.

 

파일 이름을 정할 때는 날짜나 동사 부분에 해당하는 것을 먼저 쓰면 탭의 자동완성 기능을 못쓰게 되어서 식별할 수 있는 명사를 먼저 써주었다. update(동사 부분), 2020-06-25(날짜 부분)을 먼저 쓰면 겹치는 것들이 많아서 c만 입력하고 tab으로 자동완성이 되니 파일을 찾는데 시간을 아주 조금이나마 단축할 수 있다.

 

4. 어떤 정보를 로그파일에 저장할 것인가?

시간, 키워드에 대한 정보를 남기는 것이 좋다. 예를 들어, 치킨 메뉴 API가 있어서 이를 데이터베이스에 저장하고 싶다고 가정해보자. 이 때 저장할 만한 것은 API 요청 시간, 어떤 브랜드의 치킨 메뉴를 요청했는지, 요청이 안 와서 재시도를 몇 번 한다면 그것에 대한 정보, 데이터를 잘 받았다면 데이터베이스에 저장하고 완료된 것에 대한 정보, 혹은 저장에 실패했다는 정보를 저장하는 것이 좋다.

마치며

외부 API 연동, 데이터베이스를 연결할 때 로그를 작성하여 연결 상태를 확인해야 한다. 내부 로직에 관련된 코드를 잘 짜는 건 물론이지만, 예기치 못한 에러가 발생했을 때, 그 에러가 어디서 발생했는지 blame을 하려면 반드시 이런 연결 포인트(API나 데이터베이스 연동)에 대한 로그를 남기는 것이 문제 해결하는데 시간을 단축할 수 있는 지름길이다.

참고 자료

- 로그를 잘 남기자 http://blog.weirdx.io/post/50159

- find 명령어 https://dbrang.tistory.com/867

- crontab https://kb.iu.edu/d/afiz