배경
- 프로젝트 진행중 저장되는 로그파일 용량이 너무 큰 문제발생
- 몇번 실행하니 용량이 무려 4기가가 넘었다.
- 몇개의 스크립트를 실행하는 프로젝트였는데, 우선 가장 로그가 많은 스크립트(hwpx -> pdf)를 조사해봤다.
log_file = os.path.join(path_daily_download, 'execution.log')
logging.basicConfig(
filename=log_file,
level=logging.DEBUG, # 로그 레벨 설정 (DEBUG, INFO, WARNING, ERROR, CRITICAL)
format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
datefmt='%Y-%m-%d %H:%M:%S'
)
logging.info('스크립트 시작: hwp_to_pdf.py')과정
- 로그 수준 공부 : 로그 코드를 보니 내가 각 로그의 단계가 정확히 뭔지 모르고 있었다. 로그 단계별 기능을 조사하고 공부했다.(내용은 아래에 있음)
- 로그 레벨 변화 : 공부를 해보고 logging.DEBUG -> logging.INFO 로 올려봤다. 25kB -> 6kB로 감소, 계산해보면 (25-6)/25 = 용량 75% 감소. 나중에 프로덕션으로 가면 INFO -> WARNING으로 올려 더 줄일수 있을것 같다. 그럼에도 기가 단위의 결과가 왜 나왔는지 이해가 안됨. 그러면 이 스크립트(hwpx -> pdf)는 원인이 아니였다.
- 다음 후보 조사 : 다음 후보로 LLM 모델의 결과를 내는 스크립트가 있다. 대용량의 언어모델을 사용하기 때문에 로그도 많이 발생할수 있다. 시간이 오래걸려 한번의 사이클 중 일부만 돌려보니, 로그 용량이 무려 290MB로 바뀌여 있었다.
- LLM 모델 디버그 수준 조절 : logging.DEBUG -> logging.INFO 로 올려봤다. 290MB -> 1KB 한단계만에 무려 99.65% 감소했다.
결론
LLM(대규모 언어 모델)을 처리하는 스크립트에서는 특히 디버그 정보가 방대한 양이 될 수 있습니다. 예를 들어, 각 모델 예측의 입력, 출력, 중간 결과 등 모든 세부 사항을 기록할 수 있습니다. 이는 각 예측 단계마다 수천 줄의 로그가 생성될 수 있다
결과적으로 LLM 프로젝트의 경우 로그 수준을 디버그로 하면 재앙이 발생한다.
로그 단계별 기능
DEBUG:
- 의미: 주로 개발 및 디버깅 목적의 상세한 정보를 기록합니다.
- 사용 예시: 변수 값, 함수 진입 및 종료, 조건문 통과 여부 등의 상세한 실행 정보를 기록할 때 사용됩니다.
INFO:
- 의미: 일반적인 정보 메시지를 기록합니다. 프로그램의 정상적인 흐름을 설명하는 데 사용됩니다.
- 사용 예시: 주요 작업의 시작과 종료, 설정 값, 상태 변경 등을 기록합니다.
WARNING:
- 의미: 경고 메시지를 기록합니다. 잠재적인 문제나 예상치 못한 상황을 나타내지만, 프로그램의 실행에는 영향을 미치지 않습니다.
- 사용 예시: 디스크 공간 부족, 비정상적인 입력 등 실행은 계속되지만 주의가 필요한 상황을 기록합니다.
ERROR:
- 의미: 오류 메시지를 기록합니다. 프로그램 실행 중 오류가 발생하여 일부 기능이 정상적으로 수행되지 않을 때 사용됩니다.
- 사용 예시: 파일을 열 수 없음, 네트워크 연결 실패 등의 오류 상황을 기록합니다.
CRITICAL:
- 의미: 매우 심각한 문제를 기록합니다. 프로그램이 더 이상 실행될 수 없거나, 치명적인 오류가 발생했을 때 사용됩니다.
- 사용 예시: 데이터 손실, 시스템 불안정 등의 심각한 오류를 기록합니다.
- 사용방법 :
logging.basicConfig에서level=logging.DEBUG를 설정하면, DEBUG 이상의 모든 로그 메시지가 기록됩니다. 즉,DEBUG,INFO,WARNING,ERROR,CRITICAL레벨의 메시지가 모두 기록됩니다. 레벨을 높이면, 그보다 낮은 중요도의 메시지는 기록되지 않습니다. 예를 들어, 레벨을ERROR로 설정하면ERROR와CRITICAL레벨의 메시지만 기록되고,WARNING,INFO,DEBUG메시지는 기록되지 않습니다.