대상 OS: Rocky Linux 9

원격 로그 전송(중앙 수집)을 도입할 때 많은 팀이 “rsyslog를 어떻게 설정하지?”부터 시작합니다. 하지만 실패하는 이유는 대부분 기술이 아니라 운영 합의 부재입니다. 합의가 없으면 로그는 쌓이기만 하고, 사고 때 “찾지 못하는 데이터”가 됩니다. 아래 4가지는 최소한으로 합의해야 합니다.

도입 전에 최소로 합의해야 할 4가지

  1. 1) 무엇을 보낼지(범위): ‘전부’가 아니라 ‘우선순위’

    처음부터 모든 로그를 보내면 비용/잡음/저장소/검색성 문제로 금방 망가집니다. 먼저 다음처럼 “사고 대응에 바로 도움 되는 것”부터 합의합니다.

    • 인증/권한: sshd, sudo
    • 시스템: 커널, 재부팅, OOM, 디스크/파일시스템 에러
    • 핵심 서비스: nginx/httpd, DB, 애플리케이션 에러 로그(선별)

    Rocky 9는 systemd-journald 기반이므로, journald → rsyslog → 원격 전송(또는 journald 원격) 중 조직 표준을 정해야 합니다.


  2. 2) 어디로/어떤 보안으로 보낼지: TLS, 인증, 네트워크 분리

    원격 로그는 그 자체가 민감 정보 저장소가 됩니다. 전송 경로가 평문이면 중간 탈취 위험이 커집니다. 최소한 아래를 합의합니다.

    • 전송 프로토콜: TCP 권장(유실 줄이기), 가능하면 TLS
    • 망 분리: 내부 전용망/VPN 경로, 수집 서버 접근 제어
    • 상호 인증: 인증서 기반(가능하면 mTLS) 또는 최소한 서버 인증


  3. 3) 보관 정책(기간/용량)과 인덱싱/검색 기준

    로그는 쌓으면 끝이 아니라, 보관 비용과 검색 가능성이 핵심입니다.

    • 보관 기간: 예) 30일(핫), 90일(웜), 1년(콜드) 등
    • 필드 표준: hostname, app, env(prod/stg), ip, user 등
    • 시간 동기: 서버 시간(NTP/chrony) 통일은 필수
    # Rocky 9 시간 동기(chrony) 확인
sudo systemctl status chronyd --no-pager
chronyc tracking

# 타임존/시간 확인
timedatectl


  4. 4) “누가 언제 무엇을 확인할지” 운영 루틴(알람/대시보드/책임)

    로그는 운영 루틴이 없으면 방치됩니다. 다음을 최소로 합의하세요.

    • 경보 기준: SSH 실패 급증, sudo 실패, OOM, 디스크 90% 등
    • 담당자/온콜: 알람 수신자와 대응 시간
    • 사고 시 쿼리 템플릿: “어디서부터 볼지”가 문서화돼야 함


Rocky Linux 9에서 rsyslog로 ‘원격 전송’ 최소 구성 예시(기본)

아래는 “개념 확인용” 최소 예시입니다. 실제 운영에서는 TLS, 인증, 필터링을 추가하세요.

# rsyslog 설치/활성화
sudo dnf install -y rsyslog
sudo systemctl enable --now rsyslog

# 원격 전송 설정(예: TCP 514로 전송)
# /etc/rsyslog.d/60-remote.conf
sudo tee /etc/rsyslog.d/60-remote.conf >/dev/null