서버 운영
서버 로그가 로테이션된 후 확인할 것
배포 직후 로그가 자동 삭제되면 문제 추적이 불가능해진다. 로그 보관 정책을 미리 확인해두자.
서버에서 로그가 급증하면, 로테이션 정책에 따라 오래된 로그가 삭제된다. 배포 직후 문제가 생겼는데 로그가 없으면, 원인 추적이 거의 불가능해진다.
현재 로그 상태 확인
운영 서버의 로그를 확인한다. journalctl은 systemd 시스템에서 서비스 로그를 보는 표준 방법이다.
sudo journalctl -n 80
sudo journalctl -u service-name -n 100
-n 옵션은 마지막 N줄을 본다. 배포 직후의 로그가 남아 있는가?
디스크 공간 확인
journal 로그는 디스크에 저장된다. 디스크가 가득 차면 로그 저장이 멈춘다.
df -h
du -sh /var/log/journal/
journal 로그의 총 크기가 얼마인가? 디스크 여유 공간은 충분한가?
로그 로테이션 정책 확인
systemd journal의 로그 보관 정책을 본다.
sudo journalctl --disk-usage
또는 설정 파일을 직접 본다.
sudo cat /etc/systemd/journald.conf
주요 설정:
SystemMaxUse: 전체 journal이 최대 몇 MB까지 유지될 것인가RuntimeMaxUse: 램에 저장할 로그 크기MaxRetentionSec: 로그 보관 기간 (초 단위)
로그 필터링으로 특정 서비스만 보기
전체 시스템 로그는 너무 많으면, 서비스를 특정해서 본다.
sudo journalctl -u docker -n 200 # Docker 관련 로그만
sudo journalctl -u nginx -n 200 # Nginx 관련 로그만
배포 후 서비스가 재시작됐는가? 에러 메시지가 있는가?
특정 시간 범위의 로그 조회
배포 시각이 언제인지 알면, 그 시간대 로그만 보면 된다.
sudo journalctl --since "2024-06-29 14:00:00" --until "2024-06-29 14:30:00"
로그 파일 수동으로 보관하기
중요한 배포 후에는, 현재 로그를 백업해둬야 한다.
sudo journalctl -u service-name > ~/deploy-2024-06-29.log
wc -l ~/deploy-2024-06-29.log # 라인 수 확인
이 파일을 남겨두면, 나중에라도 당시 상황을 재현할 수 있다.
프로세스 실행 상태 확인
로그가 없다면, 최소한 프로세스가 제대로 실행되고 있는지 확인해야 한다.
sudo ss -lntp # 모든 listening 포트 보기
df -h # 디스크 공간
free -h # 메모리
서비스가 정말 실행 중인가? 포트가 열려 있는가?
로그 정책 개선
배포 후 로그 로테이션 시간을 고려해서, 로그 보관 기간을 더 늘려보자. 최소 7일 이상은 보관하는 것을 권장한다.
모니터링 시스템 연결
Datadog, New Relic 같은 서비스는 로그를 중앙에서 수집한다. 로컬 로그가 삭제돼도 클라우드에는 남아 있다.