로그는 서버의 블랙박스다

서버에서 벌어지는 모든 일은 로그에 기록된다. 누가 접속했는지, 어떤 요청이 들어왔는지, 어떤 에러가 발생했는지, 시스템 자원이 어떤 상태였는지까지 전부 로그에 남는다. 서버에 문제가 생겼을 때 원인을 추적하는 가장 기본적이면서도 확실한 수단이 로그 분석이다. 로그를 보지 않고 장애 원인을 파악하려는 것은 블랙박스 없이 사고 원인을 규명하려는 것과 같다.

리눅스 로그의 구조

리눅스 서버의 시스템 로그는 기본적으로 /var/log 디렉토리에 집중된다. syslog 또는 journald가 시스템 전반의 로그를 수집하며, 각 서비스는 자체 로그 파일을 별도로 생성한다. 핵심 로그 파일을 알아두면 장애 발생 시 어디부터 봐야 하는지 판단이 빨라진다. /var/log/syslog(또는 /var/log/messages)는 시스템 전반의 이벤트를 기록한다. /var/log/auth.log는 인증 관련 로그로 SSH 접속 시도, sudo 실행 이력이 남는다. /var/log/kern.log는 커널 메시지를 기록하며, 하드웨어 오류나 드라이버 문제를 추적할 때 참조한다.

애플리케이션 로그

시스템 로그 외에 각 애플리케이션이 생성하는 로그도 중요하다. Nginx의 접근 로그(access.log)에는 모든 HTTP 요청의 출발지 IP, 요청 경로, 상태 코드, 응답 시간이 기록된다. 에러 로그(error.log)에는 설정 오류, 업스트림 연결 실패, 타임아웃 같은 이상 상황이 남는다. MySQL의 슬로우 쿼리 로그(slow query log)는 설정한 임계값보다 실행 시간이 긴 쿼리를 기록하여 성능 병목을 찾는 데 활용된다.

로그 레벨의 이해

대부분의 로깅 프레임워크는 심각도에 따라 로그 레벨을 구분한다. 일반적으로 DEBUG, INFO, WARNING, ERROR, CRITICAL 5단계로 나뉜다. DEBUG는 개발 과정에서 상세한 흐름을 추적하기 위한 레벨이고, 프로덕션 환경에서는 보통 비활성화한다. INFO는 정상 동작 기록, WARNING은 잠재적 문제, ERROR는 기능 오류, CRITICAL은 시스템 중단 수준의 심각한 장애를 나타낸다. 프로덕션 서버에서는 INFO 이상만 기록하도록 설정하는 것이 일반적이다.

로그 로테이션

로그 파일은 관리하지 않으면 무한히 커진다. 수 GB에 달하는 단일 로그 파일은 열기도 어렵고, 디스크 용량까지 잡아먹는다. logrotate는 리눅스에서 로그 파일을 주기적으로 분할하고, 오래된 로그를 압축하거나 삭제하는 도구다. /etc/logrotate.d/ 디렉토리에 서비스별 설정 파일을 추가하면 일별, 주별, 크기 기준으로 로그를 자동 관리할 수 있다.

중앙화된 로그 관리

서버가 여러 대로 늘어나면 각 서버에 SSH로 접속해서 로그를 하나씩 확인하는 방식은 비현실적이다. ELK 스택(Elasticsearch + Logstash + Kibana)이나 Loki + Grafana 같은 중앙 집중형 로그 관리 시스템을 도입하면, 모든 서버의 로그를 한 곳에 수집하고 검색, 필터링, 시각화할 수 있다. 특정 에러 패턴이 발생하면 자동으로 알림을 보내는 설정도 가능하다. 장애 대응 시간을 획기적으로 줄여주는 인프라다.

서버로그 #로그분석 #logrotate #ELK #syslog #Nginx로그 #슬로우쿼리 #로그레벨 #장애대응 #서버모니터링