개념 사전 · 프로그램

rsyslog

알시스로그

는 시스템 로그를 입력받아 필터·템플릿·규칙과 출력 동작으로 처리하는 로그 데몬이다. 메시지 형식인 와 그 메시지를 수집·중계·저장하는 구현을 구분한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

로컬·네트워크 입력을 중앙 파이프라인에 연결한다.
과 조건으로 메시지를 저장·전달 대상에 분배한다.
출력 장애 때 큐와 재시도로 로그 흐름을 완충한다.

02어떤 순서로 동작하나

메시지 생성
애플리케이션 또는 장비가 facility·severity와 본문을 포함한 메시지를 만든다.
입력 모듈 수신
같은 모듈이 지정된 포트에서 메시지를 받아 연결된 으로 넘긴다.
규칙·템플릿 처리
이 조건과 action을 평가하고 이 저장 경로나 출력 표현을 결정한다.
큐와 전달
원격 전송 action은 큐에서 대기·재시도할 수 있다. 큐 한도와 영속성에 따라 장애 시 지연·손실이 달라진다.
최종 저장 확인
수집 파일과 파싱·검색 결과에서 같은 시험 식별자를 확인한다. 연결 성공이나 송신 성공만으로 최종 적재를 대신하지 않는다.

03먼저 알아둘 용어와 구성요소

: 파일·소켓·네트워크 등의 메시지 입력을 담당하는 모듈.
: 연결된 입력에 적용할 필터·동작 묶음.
: 출력 파일명이나 메시지 표현을 구성하는 규칙.
: 특정 출력 동작의 대기 메시지를 보관하는 큐.
: 기반 로그 입력을 제공하는 모듈.
: 로그를 원격 대상으로 전달하는 출력 모듈.
: 메시지 확인 응답을 사용하는 로그 전달 프로토콜.
: 송수신 상대 인증과 전송 보호를 제공하는 채널 기술.

LEARN THROUGH PRACTICE

TCP 수신 설정과 수집된 웹 로그를 한 경로로 읽기

수신 포트, 머리말, 웹 서버의 원래 메시지를 구분하여 전달 실패와 애플리케이션 오류를 가려낸다.

실습 구성과 전제

격리 실습망의 송신기와 수신기에서 시간대·호스트 이름·전송 포트를 기록한다.
이 실습의 514/ 예시는 평문 수신이다. 를 적용하려면 인증서와 스트림 드라이버 등 별도 설정이 필요하다.

수신 모듈과 소켓이 같은 조건인지 확인하기
- 모듈은 연결에서 메시지를 받는 입력 모듈이다. 모듈을 불러오는 행과 실제 514번 포트를 여는 input 행이 모두 있어야 의도한 수신 구성이 된다.
- 설정 파일이 존재하는 것, 문법 검사가 통과하는 것, 현재 가 포트를 열고 있는 것은 별개다. 문법 검사 뒤 실제 LISTEN 소켓과 방화벽 경로를 확인한다.
bash
```
rsyslogd -N1
ss -lntp
```
현재 설정의 문법과 수신 소켓을 조회한다. 설정 검사만으로 서비스가 재시작되지는 않는다.
원본 크기로 보기 ↗
- module(load="imtcp")와 input(type="imtcp" port="514")가 함께 보인다. 입력 모듈과 수신 포트가 각각 지정되어 있다.
- 이 부분에는 TLS 인증서나 암호화 모드 지정이 보이지 않는다. TCP라는 이유만으로 암호화 전송이라고 할 수 없다.
확인 기준
설정 검사 결과와 514/ LISTEN이 일치해야 수신 준비가 됐다고 판단한다.
고유 표식 한 건을 보내 저장 경로를 찾기
- 다른 이벤트와 구별되는 lab-event-001 같은 표식을 보내고, 송신 시각·수신 시각·저장 파일에서 같은 문자열을 찾는다. 재전송 시험에서는 같은 이벤트의 중복 저장 여부도 센다.
- 수신 파일의 머리말 뒤에는 원래 애플리케이션 메시지가 그대로 들어갈 수 있다. 외부 호스트명과 내부 시간 문자열은 서로 다른 필드이므로 하나의 으로 무리하게 합치지 않는다.
bash
```
logger --tcp --server 127.0.0.1 --port 514 --tag lab-source 'lab-event-001'
```
수신기 자체의 로컬 입력 확인 예. 원격 경로 시험은 자신이 관리하는 수신기 주소로 바꿔 별도로 진행한다.
원본 크기로 보기 ↗
- 각 행의 앞에는 Jun 9 시각, localhost, httpd-access가 있고 그 뒤에 대괄호로 감싼 Apache 요청 시각이 다시 나타난다.
- 같은 수집 파일에서 GET 요청의 상태 코드 500과 정적 파일 요청의 304가 함께 보인다. 수집 파일에 기록됐다는 사실과 웹 요청 성공 여부는 별도다.
확인 기준
표식이 없으면 송신→포트→→action→파일 권한 순으로 좁힌다. 웹 500을 전송 실패로 분류하지 않는다.
Severity와 웹 상태 코드의 의미를 분리하기
- severity는 0이 가장 긴급하고 7이 디버그인 메시지 분류다. HTTP 500의 숫자와 같은 척도가 아니며, 전달된 메시지 내용만 보고 severity를 임의로 바꾸면 안 된다.
- 필터가 severity 범위를 제한하면 전달은 됐어도 선택한 저장 action에는 남지 않을 수 있다. 수신 원본과 최종 파일에서 표식을 비교하여 필터에 의한 누락인지 판단한다.
원본 크기로 보기 ↗
- 표에는 emerg 0부터 debug 7까지 여덟 단계가 나온다. 숫자가 커질수록 더 긴급해지는 구조가 아니다.
- notice는 5, info는 6으로 별도 행이다. 정상 동작 중에도 주목할 사건과 일반 정보 메시지를 나누어 분류할 수 있다.
확인 기준
내용의 HTTP 상태 코드, severity, 최종 저장 action을 각각 기록하면 누락과 애플리케이션 장애를 혼동하지 않는다.