Linux Log?

출처: https://www.howtogeek.com/linux-apps-i-install-on-every-new-pc/

리눅스에서 "로그"는 커널이나 프로세스가 발생시킨 이벤트 기록을 의미한다.
이벤트가 발생하는 영역에 따라 다음과 같이 커널 로그와 프로세스 로그로 구분된다.

  • 커널로그 by 커널 공간(Kernel Space)
    • 커널은 자체적으로 메시지를 출력하며, 이는 메모리 상의 커널 링 버퍼에 저장된다.
    • dmesg 명령어를 통해 직접 확인 가능하며, systemd 기반 시스템에서는 journald가 /dev/kmsg를 통해 커널 로그도 함께 수집한다.
    • CPU, 메모리, 네트워크, 스토리지 같은 하드웨어와 커널 내부 동작 로그를 의미한다.
      • ex. 장치 드라이버 로드, 메모리 부족(OOM Killer), 디스크 I/O 오류
cf. 로그 예시
[ 10.332019] eth0: link up [ 15.732221] EXT4-fs error (device sda1): ext4_find_entry:1463: inode #12: comm ls: reading directory lblock 0
  • 프로세스 로그 by 사용자 공간(User Space)
    • 서비스나 애플리케이션이 syslog API 또는 stdout/stderr를 통해 로그를 출력한다.
    • systemd 기반 시스템에서는 journald가 먼저 수집하고, 설정(ForwardToSyslog=yes)에 따라 rsyslog로 전달하여 /var/log 아래의 다양한 파일로 저장한다.
    • systemd 기반이 아닌 시스템에서는 rsyslog가 커널 로그와 프로세스 로그를 직접 수집·저장한다.
    • 시스템 서비스(데몬), 애플리케이션에서 발생한 로그들이 포함된다.
      • ex. Apache 요청 기록, SSH 로그인 성공/실패, DB 오류
cf. 로그 예시
Aug 15 14:42:11 server01 sshd[1423]: Accepted password for user1 from 192.168.0.5 port 52641 ssh2 Aug 15 14:43:00 server01 httpd[1550]: [error] File not found: /var/www/html/missing.html

 

1차 로그 수집 및 저장 [ systemd-journald ]

리눅스에서는 커널과 프로세스에서 로그가 생성되고, 이 로그들을 1차적으로 systemd-journald가 수집하여 바이너리 형태로 저장하게 된다.

  • journald 저장 위치
    • /run/log/journal/: 휘발성 저장소 (RAM). 시스템 재부팅 시 사라짐
    • /var/log/journal/: 영속적 저장소 (디스크). 해당 디렉토리가 존재해야 활성화됨

journald가 저장한 바이너리 로그는 일반적인 cat, grep, tail 등의 명령어들을 사용하여 분석하지 못하므로, journalctl 명령어로 분석해야하는 불편함이 존재한다. 주요 journalctl 명령어는 다음과 같다.

  • journald 분석 명령어
    • journalctl: journald 로그 전체 조회
    • journalctl -k: 커널 로그만 조회
    • journalctl -u sshd: 특정 서비스 로그 조회
    • journalctl -xe: 최근 에러 중심 로그 조회

 

2차 로그 수집 및 저장 [ rsyslog ]

journald는 기본적으로 로그를 자체적으로 관리하지만, 설정에 따라 rsyslog 등 외부 로깅 시스템에 로그를 전달할 수 있다. 보통 현업에서는 journald에서 수집한 로그를 rsyslog에 전달하여 텍스트 파일로 /var/log/ 경로 아래에 저장한다.

왜냐하면 위에서도 언급했듯이, journald가 수집한 바이너리 로그 파일들은 로그 백업, 외부 전송, 보안 서버 연동 등이 불편하기 때문이다.

 

따라서, rsyslog를 활용해 평문 텍스트 로그를 수집한다. journald는 /etc/systemd/journald.conf 파일에서 다음 설정을 통해 rsyslog로 로그 전달이 가능하다.

ForwardToSyslog=yes

 

rsyslog의 주요 로그 저장 경로는 다음과 같다.

파일 경로  로그 내용
/var/log/messages 시스템 일반 로그
/var/log/secure 인증 관련 로그 (SSH, sudo 등)
/var/log/cron 크론 잡 실행 기록
/var/log/httpd/access_log Apache 웹 서버 접근 로그
/var/log/httpd/error_log Apache 웹 서버 에러 로그

 

cf. systemd가 없는 시스템일 경우 (CentOS 6, Ubuntu 14.04, Debian 7 등)

systemd가 없는 전통적인 리눅스 시스템(예: CentOS 6, Ubuntu 14.04, Debian 7 등)에서는 journald가 존재하지 않기 때문에, rsyslog 또는 syslog-ng가 모든 로그를 직접 수집한다.

이 경우 로그 흐름은 다음과 같다

  1. 커널은 /proc/kmsg 또는 /dev/kmsg를 통해 로그 출력
  2. 프로세스는 /dev/log 소켓으로 로그 전달
  3. rsyslog가 이를 수신하여 바로 /var/log/ 경로에 저장

즉, 로그 수집과 저장을 rsyslog가 전부 맡는다. journalctl은 사용할 수 없고, 로그는 오직 텍스트 파일로만 존재한다.

cf. rsyslog만 활성화 해도 되지 않나?
journald에 의해 수집된 로그는 바이너리 파일들이기 때문에, 그러면 어차피 사람이 읽지도 못하는거 rsyslog만 활성화 하는게 더 좋은거 아닌가라는 생각이 들 수 있다. 
하지만, journald는 systemd에 깊게 통합돼 있어서, 단순히 로그 내용을 기록하는 것뿐만 아니라, 로그와 관련된 메타데이터
까지 같이 붙여서 저장하게 된다. 즉, rsyslog보다 더 상세한 로그 수집이 가능하다.
따라서 journald를 통해 상세 로그들을 수집하고, rsyslog를 통해 사람이 읽기 쉬운 평문 파일로 2차 가공을 하는 것이다.

 

로그 분석

journald 로그 분석 (journalctl 활용)

journald는 바이너리 형태로 로그를 저장하므로, 분석 시에는 journalctl 명령어를 사용한다.

명령어 설명
journalctl 모든 로그 출력
journalctl -n 100 최근 100줄 로그 확인
journalctl -f 실시간 로그 모니터링 (tail -f와 유사)
journalctl -k 커널 로그만 보기 (dmesg 대체)
journalctl -u sshd 특정 서비스 로그 확인
journalctl -u nginx --since "2025-08-10 14:00" --until "2025-08-10 15:00" 시간 범위 지정
journalctl -p err 오류 수준 이상의 로그만 출력 (emerg, alert, crit, err)
journalctl -o json-pretty JSON 형태로 출력하여 가공/필터링 가능

 

또한 journalctl은 PID, UID, GID, 부팅 ID 등 메타데이터 필터링이 가능하므로 “누가, 언제, 어떤 실행 파일로” 로그를 남겼는지까지 다음과 같이 추적 가능하다.

journalctl _PID=1234
journalctl _UID=0
journalctl _SYSTEMD_UNIT=nginx.service

 

rsyslog 로그 분석 (텍스트 로그 파일 활용)

rsyslog가 저장한 로그는 /var/log/ 아래 텍스트 파일로 존재하므로 cat, grep, awk, sed 등을 사용한다.

 

1) 특정 키워드 검색

grep "error" /var/log/messages
grep -i "failed" /var/log/secure

 

2) 날짜/시간 기반 검색

grep "Aug 15" /var/log/cron

 

3) 최근 로그 실시간 보기

tail -f /var/log/messages
tail -f /var/log/secure

 

4) 특정 서비스 로그만 보기

grep "sshd" /var/log/secure
grep "httpd" /var/log/httpd/error_log

 

로그 분석 케이스

디스크 I/O 오류

서버 응답 지연이 발생하거나, 파일 접근 오류가 발생하는 경우 다음과 같이 로그를 확인한다.

dmesg | grep -i "error"
journalctl -k | grep -i "I/O error"
grep -i "error" /var/log/messages
  • 특정 디바이스명(sda,nvme0n1 등) 반복 발생 여부를 확인한다.
  • SMART 상태를 확인한다.(smartctl -a /dev/sda)

로그 분석 결과에 따라 데이터 백업 후 디스크를 교체해주거나 RAID 복구를 해준다.

 

메모리 부족(OOM Killer 확인)

프로세스가 갑자기 종료 되는 경우 다음과 같이 로그를 확인한다.

dmesg | grep -i "out of memory"
journalctl -k | grep -i "oom"
  • 어떤 프로세스가 메모리를 과다 사용했는지 확인한다.
  • 발생 시각, 부팅 이후 몇 시간 경과 후 발생했는지 확인한다.

로그 분석 결과에 따라 메모리 증설 또는 애플리케이션 메모리 제한(Tuning)을 활성화 한다. 또는 스왑 설정을 조정해준다.

 

서비스 비정상 종료

nginx, apache, DB 등 서비스가 다운 되는 경우 다음과 같이 로그를 확인한다.

journalctl -u nginx --since "1 hour ago"
grep "error" /var/log/httpd/error_log
  • 특정 요청 패턴에서만 에러가 발생하는지 확인한다.
  • 설정 변경 직후 문제가 발생하는지 확인한다.

로그 분석 결과에 따라 설정 파일을 롤백하거나 장애 패턴 재현 테스트도 진행해본다.

 

Cron 작업 실패

예약된 cron 작업이 실행되지 않을 때 다음과 같이 로그를 확인한다.

grep CRON /var/log/cron
journalctl -u cron

 

  • 실행 시간, 실행 계정을 확인한다.
  • STDERR 출력이 /var/mail/<user>에 남아있는지 확인한다.
    • 크론은 표준 출력(stdout)과 표준 에러(stderr)을 별도로 처리하지 않으면 로그에 남지 않는다. 따라서 크론 실행 라인 끝에 >> /var/log/cron.log 2>&1를 붙여서, 실행 결과와 에러 메시지가 모두 /var/log/cron.log에 기록되도록 설정해주는 것이 좋다.
      • ex. * * * * * /usr/bin/python3 /home/user/script.py >> /var/log/cron.log 2>&1

로그 분석 결과에 따라 PATH, 권한 문제를 수정해준다. 특히 위와 같이 로그 리다이렉션도 설정하여 로그를 확인할 수 있도록 설정해준다.

 

네트워크 연결 불안정

SSH가 끊기거나 서비스 응답 지연이 발생할 때 다음과 같이 로그를 확인한다.

dmesg | grep eth
journalctl -k | grep -i "link"
grep -i "Network" /var/log/messages

 

 

  • NIC(네트워크 카드) 링크 다운/업 반복 여부를 확인한다.
  • 특정 시간대에 집중 발생하는지 확인한다.

로그 분석 결과에 따라 케이블/스위치를 점검하거나 NIC 드라이버를 업데이트 해준다.

 

보안 관련 경고

sudo, su 명령어 관련 오남용이 의심되는 경우 다음과 같이 로그를 확인한다.

grep "sudo" /var/log/secure
grep "su:" /var/log/secure

 

 

  • root 계정 직접 로그인 시도 여부를 확인한다.
  • 권한 상승 요청의 빈도를 확인한다.

로그 분석 결과에 따라 불필요한 계정을 비활성화 하고, sudoers 정책을 강화한다.

 

티스토리툴바