전체 시스템 저널을 수정하는 방법

11분 소요 - 2026년 5월 20일

hero section cover
목차
  • 가득 찬 systemd 저널을 해결하는 방법
  • 문제 진단
  • 로그를 안전하게 삭제하기
  • Journald 크기 제한 구성
  • 로그 관리 자동화
  • 결론
공유

진공 명령, journald.conf 크기 제한, 자동 정리 타이머, 로그 포워딩을 통해 전체 시스템 저널을 진단하고 수정하세요.

가득 찬 systemd 저널을 해결하는 방법

systemd 저널은 서버에서 생성되는 모든 로그 메시지를 저장하며, 루트 파티션 용량이 작은 VPS의 경우 사용 가능한 디스크 공간을 서서히 소모할 수 있습니다. 이 경우 서비스가 시작되지 않고, 쓰기 작업이 중단되며, 문제 원인을 파악하는 데 필요한 진단 정보마저 잃게 됩니다. 이 가이드에서는 문제를 진단하고, 즉시 공간을 확보하며, 재발 방지를 위해 journald를 구성하는 방법을 다룹니다.


 

문제 진단

먼저 저널이 얼마나 많은 공간을 차지하고 있는지 확인하십시오:

journalctl --disk-usage

이 값은 활성 및 보관된 모든 저널 파일의 합계 크기를 나타냅니다. 이를 사용 가능한 디스크 공간과 비교하십시오. df -h. 20GB 루트 파티션의 경우, 로그가 2GB만 되어도 전체 디스크 용량의 10% 이상을 차지하게 되며, 이는 문제를 일으키기에 충분한 양입니다.

다음으로, 가장 많은 로그를 생성하는 서비스가 무엇인지 확인하십시오. 다음 한 줄 명령어는 지난 24시간 동안의 상위 10개 로그 소스를 순위별로 나열합니다:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

다음 명령어를 사용하여 오류 로그를 구체적으로 필터링해 보세요: journalctl -p err -b 를 사용하여 오류를 구체적으로 필터링하면, 특정 서비스가 크래시 루프에 갇혀 저널을 과부하시키고 있는지 확인할 수 있습니다. 또한 journald가 특정 서비스에 대해 속도 제한을 적용하고 있는지 확인할 수도 있습니다:

journalctl -u systemd-journald | grep -i "suppressed"

메시지가 억제되었다는 것은 해당 서비스가 30초 이내에 기본 임계값인 10,000건을 초과했음을 의미합니다. 바로 이것이 문제의 원인입니다.

VPS 인스턴스에서는 몇 가지 문제가 특히 자주 발생합니다. 만약 Storage=auto 가 설정되어 있고 /var/log/journal/ 파일이 존재하면, journald는 기본적으로 약 4GB로 제한된 영구 저장소를 사용합니다. 작은 루트 파티션에서는 이 공간이 금방 꽉 찹니다. 비정상적인 종료 시에도 .journal~ 확장자를 가진 손상된 저널 파일을 남길 수 있습니다. 이러한 파일은 정상적으로 회전되지 않고 계속 공간을 차지합니다.

로그를 안전하게 삭제하기

어떤 것도 삭제하기 전에, 활성 저널 파일을 교체하여 현재 로그가 보존되도록 하십시오:

journalctl --rotate

그런 다음 보관된 로그를 정리하십시오. 기간, 크기 또는 파일 수를 기준으로 선택할 수 있습니다:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

첫 번째 명령은 24시간이 지난 로그를 삭제합니다. 두 번째 명령은 전체 저널 크기를 100MB로 줄입니다. 세 번째 명령은 가장 최근의 아카이브 파일 5개만 남깁니다. 상황에 맞는 명령을 선택하십시오.

디스크가 완전히 꽉 차서 journalctl 명령어가 응답하지 않는 경우, 저널 파일을 수동으로 삭제해야 할 수 있습니다:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

이는 최후의 수단입니다. 이 작업은 저장된 모든 로그를 삭제하고 올바른 권한으로 디렉터리를 다시 생성합니다. 정리 작업 후에는 데몬을 재시작하고 상태를 확인하십시오:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Journald 크기 제한 구성

기본 journald 설정은 여유분이 넉넉합니다. VPS 환경에서는 오히려 너무 넉넉할 수 있습니다. 로그 저장소에 대한 상한선을 설정하려면 구성을 수정하십시오. 패키지 업데이트 후에도 변경 사항이 유지되도록 메인 구성 파일을 직접 수정하는 대신 오버라이드 파일을 생성하십시오:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

주요 지시어:

매개변수VPS (20-40 GB 디스크)전용 서버기능
SystemMaxUse500M ~ 1G2G ~ 5G전체 저널 크기에 대한 하드 캡
SystemKeepFree1G디스크 용량의 10%OS를 위해 예약된 여유 공간
최대 보존 기간(초)7일 ~ 14일30일 ~ 90일이 기간보다 오래된 로그를 자동으로 삭제
SystemMaxFileSize20M ~ 50M100M저널 파일당 최대 크기

둘 다 설정 SystemMaxUseSystemKeepFree 를 모두 설정하면 이중 안전 장치를 마련하는 것과 같습니다. 즉, 로그 크기가 고정된 크기로 제한되며, 디스크에 다른 무엇이 있든 상관없이 시스템에는 항상 여유 공간이 확보됩니다.

영구 저장소 대 휘발성 저장소

` Storage= 지시어는 로그가 저장될 위치를 제어합니다. Storage=persistent 를 설정하면 로그가 /var/log/journal/ 디스크에 저장하도록 설정합니다. 이는 로그가 재부팅 후에도 유지되며, 사후에 시스템 충돌을 조사할 수 있기 때문에 프로덕션 서버에 적합합니다. 디렉터리가 존재하지 않으면 생성하십시오:

sudo mkdir -p /var/log/journal

대안인 Storage=volatile는 로그를 /run/log/journal/. 재부팅 시 로그가 사라집니다. 이는 일시적인 컨테이너나 모든 로그를 외부 시스템으로 전달하는 서버에 적합합니다.

트래픽이 많은 서버에서 압축 비활성화

Journald는 기본적으로 512바이트보다 큰 데이터 객체를 압축합니다. 로그 처리량이 많은 서버에서는 이로 인해 CPU 오버헤드가 발생합니다. Compress=no 로 설정하십시오. 또한 ForwardToConsole=no 을 설정하십시오. 콘솔 전달은 동기식이며, 가상 시리얼 콘솔이 멈출 경우 journald 데몬이 완전히 차단될 수 있습니다.

구성을 변경한 후에는 서비스를 재시작하십시오:

sudo systemctl restart systemd-journald

로그 관리 자동화

수동 정리 작업은 확장성이 떨어집니다. 일정대로 로그를 정리할 수 있도록 systemd 타이머를 생성하십시오. 다음 위치에 서비스 유닛을 설정하십시오. /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

그런 다음 /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

다음 명령어로 활성화하십시오 sudo systemctl enable --now journal-vacuum.timer로 활성화하십시오. 이 타이머는 매주 일요일 오전 2시에 실행되며, 한 번의 처리로 시간 기반 및 크기 기반 보존 정책을 모두 적용합니다.

타이머가 처리하지 못하는 한 가지: 손상된 저널 파일입니다. 비정상적인 시스템 종료 후, journald는 파일 이름 끝에 ~ 파일 이름 끝에 를 추가하여 격리합니다. 이러한 .journal~ 파일은 여전히 디스크 사용량에 포함되지만 자동으로 정리되지는 않습니다. 주기적으로 오래된 파일을 확인하고 제거하십시오:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

로그를 외부로 전달하기

로컬 스토리지 용량을 늘리지 않으면서 장기 보관이 필요한 서버의 경우, 로그를 중앙 집중식 시스템으로 전달하십시오. 가장 간단한 방법은 journald.conf:

ForwardToSyslog=yes

전체 메타데이터(PID, UID, 유닛 이름)가 포함된 구조화된 로그의 경우, systemd-journal-remote 를 사용하여 JSON 형식의 항목을 로그 관리 플랫폼으로 전송하십시오. 또한 외부 로그 저장은 로컬 디스크에 장애가 발생하거나 서버가 침해된 경우 감사 추적을 보호해 줍니다.

결론

시스템드(systemd) 저널이 가득 차는 문제는 해결이 간단하며 예방하기도 쉽습니다. 주요 단계는 다음과 같습니다:

  • 다음 명령어로 사용량을 확인하고 journalctl --disk-usage 명령어로 사용량을 확인하고, 과도한 리소스를 사용하는 서비스를 파악합니다.
  • 다음 명령어로 즉시 공간을 확보합니다. journalctl --rotate 명령어를 실행한 후 --vacuum-size 또는 --vacuum-time.
  • journald.conf 오버라이드 파일에서 명시적인 크기 제한을 설정하십시오.
  • systemd 타이머를 사용하여 정리를 자동화하십시오.
  • 장기 보관을 위해 로그를 외부로 전달하십시오.

FDC의 VPS전용 서버 요금제는 프로덕션 로그 워크로드에 필요한 디스크 I/O 및 스토리지를 제공합니다.

블로그

이번 주 추천

더 많은 기사
Linux의 좀비 프로세스: 찾기, 제거, 방지

Linux의 좀비 프로세스: 찾기, 제거, 방지

Linux에서 좀비 프로세스를 식별, 제거 및 방지하는 방법에 대해 알아보세요. 서버 관리자를 위한 명령어, 코드 수정 및 모니터링 팁.

15분 소요 - 2026년 5월 19일

Linux 서버 강화 체크리스트

15분 소요 - 2026년 5월 8일

더 많은 기사
background image

질문이 있거나 맞춤형 솔루션이 필요하신가요?

icon

유연한 옵션

icon

글로벌 도달 범위

icon

즉시 배포

icon

유연한 옵션

icon

글로벌 도달 범위

icon

즉시 배포