재배포 없이 운영 로그 레벨 조정하기
평소 로그만으로 원인을 찾기 어려운 문제가 있습니다. 그렇다고 상세 로그를 항상 남기면 양이 많아져 필요한 기록을 찾기 어렵고, 저장·처리 비용도 늘어납니다.
당시 운영 자료에는 log4jAdmin.jsp라는 유틸이 있었습니다. 브라우저에서 logger의 레벨을 바꿀 수 있어, 서비스를 다시 배포하지 않고 필요한 구간의 로그를 더 볼 수 있었습니다. 이 글에서는 그 도구의 역할과 운영 중 확인할 항목을 정리합니다.
필요한 logger 선택
문제가 있는 패키지나 클래스의 logger를 좁혀 레벨을 바꾸면 관련 로그를 추가로 확인할 수 있습니다. 전역 DEBUG를 켜는 것보다 조사 범위를 한정하기 쉽습니다.
다만 레벨을 높인다고 없는 로그가 새로 생기지는 않습니다. 해당 코드가 그 레벨로 기록하고 있어야 하고, appender의 필터 등 실제 출력 경로에서도 허용해야 합니다. logger 이름과 로그가 나오는 위치를 함께 알아야 도구를 제대로 사용할 수 있습니다.
적용 시간과 원래 설정 복원
로그 레벨을 바꾸기 전에는 원래 설정을 남깁니다. 조사 후에는 원래 상태로 되돌리고, 로그량이 정상 범위로 돌아왔는지 확인합니다.
여기서 원래 설정이 명시적인 INFO였는지, 상위 logger를 상속하는 상태였는지도 구분할 필요가 있습니다. 모두 INFO로 바꾸는 방식은 원래의 상속 관계를 복원하는 것과 다를 수 있습니다.
자동 만료 기능이 있다면 방치할 가능성을 줄일 수 있습니다. 자동으로 복원되지 않는 도구라면 운영 절차에서 누가 언제 되돌릴지 정해야 합니다.
여러 인스턴스의 설정
런타임에서 바꾼 레벨이 어느 프로세스에 적용되는지도 중요합니다. 요청이 여러 인스턴스로 분산되면 관리 화면에 접속한 인스턴스와 문제 요청을 처리한 인스턴스가 다를 수 있습니다.
한 프로세스의 설정 변경을 서비스 전체 변경으로 생각하면, 로그가 추가되지 않은 이유를 잘못 짚을 수 있습니다. 대상 인스턴스와 설정 유지 범위, 재시작 뒤의 동작은 사용하는 도구에 맞춰 확인해야 합니다.
관리 기능의 접근 제어
로그 레벨 변경은 운영 중인 프로세스의 동작과 출력량에 영향을 줍니다. 관리 화면에는 접근 권한이 필요하고, 변경 대상과 시각·이전 설정을 남길 수 있어야 합니다. 요청·응답을 자세히 출력하는 코드에서는 개인정보나 인증 정보가 추가로 노출되지 않는지도 봐야 합니다.
당시의 JSP 도구를 새로운 서비스에 그대로 넣을 필요는 없습니다. 현재 서비스가 사용하는 로그 프레임워크와 관리 기능에 맞춰 구현하되, 필요한 범위만 잠시 바꾸고 원래 상태로 되돌리는 흐름을 유지하면 됩니다.
다음 시리즈에서는 Nike The Draw 운영 구조를 살펴보겠습니다.