서버를 운영하다 보면 수많은 로그가 쏟아집니다. 이 로그들은 시스템의 상태를 파악하고, 문제 발생 시 원인을 추적하며, 보안 위협을 감지하는 데 필수적인 정보 자산입니다. 하지만 기본 설정으로는 로그가 텍스트 파일 형태로 /var/log 디렉터리에 흩어져 저장되기 때문에, 특정 정보를 찾거나 통계를 내는 등 의미 있는 데이터로 활용하기가 어렵습니다. 이 문제를 해결하기 위해 등장한 것이 바로 '중앙화된 로그 관리 시스템'입니다.
오늘 우리는 Ubuntu에 기본적으로 설치되어 있는 강력한 로그 처리 시스템인 rsyslog를 활용하여, 단순히 로그를 파일에 저장하는 것을 넘어 원하는 로그만 선별(필터링)하고, 이를 관계형 데이터베이스(MySQL/MariaDB)에 체계적으로 저장하는 방법을 자세히 알아보겠습니다. 이 과정을 통해 여러분은 흩어져 있던 로그를 강력한 데이터 자산으로 바꾸는 첫걸음을 떼게 될 것입니다.
이 글을 끝까지 따라오시면, 여러분은 다음을 할 수 있게 됩니다:
- rsyslog의 모듈 시스템을 이해하고 DB 연동 모듈을 설치합니다.
- 로그 저장을 위한 데이터베이스와 사용자 계정을 설정합니다.
- rsyslog의 기본 및 고급 필터링 규칙(RainerScript)을 사용하여 원하는 로그만 정확히 골라냅니다.
- 필터링된 로그를 실시간으로 데이터베이스에 삽입하도록 rsyslog를 설정합니다.
- 설정이 올바르게 동작하는지 확인하고 기본적인 문제를 해결합니다.
이 과정은 단순히 로그를 DB에 넣는 기술적인 방법을 넘어, 대규모 시스템의 로그를 어떻게 효율적으로 관리하고 분석의 기반을 마련할 수 있는지에 대한 통찰을 제공할 것입니다. 이제, 텍스트 파일에 잠자고 있던 로그에 새로운 생명을 불어넣어 보겠습니다.
준비 단계: 필요한 것들 확인하기
본격적인 설정에 앞서, 원활한 진행을 위해 몇 가지 준비가 필요합니다. 아래 항목들이 준비되었는지 확인해주세요.
- Ubuntu 서버: Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS 또는 그 이상의 버전이 설치된 서버가 필요합니다. 이 가이드는 대부분의 Debian 계열 리눅스에서도 유사하게 적용될 수 있습니다.
- Sudo 권한: 패키지를 설치하고 시스템 설정 파일을 수정해야 하므로,
sudo명령을 실행할 수 있는 관리자 권한을 가진 계정이 필요합니다. - 데이터베이스 선택: 이 가이드에서는 가장 널리 사용되는 오픈소스 데이터베이스인 MariaDB를 기준으로 설명합니다. MySQL을 사용하셔도 과정은 거의 동일합니다. PostgreSQL을 사용하고 싶다면 관련 패키지 이름(
rsyslog-pgsql)만 바꾸면 됩니다. - 기본적인 리눅스 명령어 지식:
apt,systemctl,nano또는vim과 같은 텍스트 편집기 사용법 등 기본적인 리눅스 명령어에 익숙하다고 가정합니다.
모든 준비가 되셨다면, 이제 첫 번째 단계인 데이터베이스와 rsyslog 모듈 설치부터 시작하겠습니다.
1단계: 데이터베이스 및 rsyslog 모듈 설치
rsyslog가 로그를 데이터베이스에 보내려면, rsyslog가 데이터베이스와 '대화'할 수 있도록 해주는 '통역사' 역할의 모듈이 필요합니다. MariaDB/MySQL의 경우 rsyslog-mysql이라는 패키지가 이 역할을 합니다. 또한, 로그를 저장할 데이터베이스 서버 자체도 설치해야 합니다.
1.1. MariaDB 서버 설치
이미 데이터베이스 서버가 운영 중이라면 이 단계를 건너뛰셔도 좋습니다. 새로 설치하는 경우, 다음 명령어를 터미널에 입력하여 MariaDB 서버를 설치합니다.
sudo apt update
sudo apt install mariadb-server -y설치가 완료되면 MariaDB 서비스가 자동으로 시작됩니다. 다음 명령어로 서비스 상태를 확인하여 정상적으로 실행 중인지 확인합니다.
sudo systemctl status mariadb출력 결과에 active (running)이라는 문구가 보인다면 성공적으로 설치 및 실행된 것입니다.
1.2. rsyslog MySQL 모듈 설치
이제 rsyslog가 MariaDB와 통신할 수 있도록 rsyslog-mysql 패키지를 설치합니다. 이 패키지는 rsyslog의 출력 모듈(Output Module) 중 하나인 ommysql을 제공합니다.
sudo apt install rsyslog-mysql -y설치가 매우 간단하게 끝납니다. 이 작은 패키지 하나가 rsyslog의 능력을 파일 시스템 너머로 확장시켜주는 핵심 열쇠입니다.
2단계: 로그 저장을 위한 데이터베이스 설정
이제 로그를 저장할 '창고'를 만들어야 합니다. 보안을 위해 rsyslog 전용 데이터베이스와 사용자 계정을 생성하는 것이 좋습니다. 이렇게 하면 rsyslog 계정이 다른 데이터베이스에 영향을 미치는 것을 방지할 수 있습니다.
2.1. MariaDB 접속 및 보안 설정
먼저, root 사용자로 MariaDB에 접속합니다.
sudo mysql -u root만약 처음 설치했다면, 초기 보안 설정을 진행하는 것이 좋습니다. mysql_secure_installation 스크립트를 실행하여 root 비밀번호 설정, 익명 사용자 제거 등을 수행할 수 있습니다.
sudo mysql_secure_installation2.2. 데이터베이스 및 사용자 생성
MariaDB 프롬프트(MariaDB [(none)]>)에서 다음 SQL 쿼리를 차례대로 실행하여 rsyslog를 위한 데이터베이스와 사용자를 생성합니다.
1. 데이터베이스 생성: 로그를 저장할 `Syslog`라는 이름의 데이터베이스를 만듭니다.
CREATE DATABASE Syslog CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;2. 사용자 생성 및 권한 부여: `rsyslog_user`라는 사용자를 만들고, 이 사용자가 `Syslog` 데이터베이스에만 접근하여 모든 작업을 할 수 있도록 권한을 부여합니다. `'your-strong-password'` 부분은 반드시 강력한 비밀번호로 변경해주세요.
CREATE USER 'rsyslog_user'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT ALL PRIVILEGES ON Syslog.* TO 'rsyslog_user'@'localhost';3. 변경사항 적용: 변경된 권한을 시스템에 즉시 적용합니다.
FLUSH PRIVILEGES;4. 종료: MariaDB 프롬프트를 빠져나옵니다.
EXIT;2.3. 로그 테이블 스키마(Schema) 생성
rsyslog는 어떤 구조의 테이블에 로그를 저장해야 할지 미리 약속된 스키마를 가지고 있습니다. 다행히도 rsyslog-mysql 패키지를 설치할 때 이 스키마를 생성해주는 SQL 스크립트 파일이 함께 제공됩니다. 우리는 이 스크립트를 방금 만든 `Syslog` 데이터베이스에 실행하기만 하면 됩니다.
스크립트 파일은 보통 /usr/share/doc/rsyslog-mysql/ 디렉터리에 있습니다. 다음 명령어로 해당 스크립트를 `Syslog` 데이터베이스에 적용합니다.
sudo mysql -u rsyslog_user -p Syslog < /usr/share/doc/rsyslog-mysql/createDB.sql명령을 실행하면 위에서 설정한 rsyslog_user의 비밀번호를 입력하라는 메시지가 나옵니다. 비밀번호를 정확히 입력하면, 아무런 메시지 없이 명령이 종료됩니다. 이것이 정상입니다.
확인을 위해, `Syslog` 데이터베이스에 어떤 테이블이 생성되었는지 살펴볼 수 있습니다.
sudo mysql -u rsyslog_user -p -e "USE Syslog; SHOW TABLES;"실행 결과로 SystemEvents와 SystemEventsProperties 두 개의 테이블이 보인다면, 데이터베이스 준비는 완벽하게 끝난 것입니다. SystemEvents 테이블이 바로 우리의 로그가 차곡차곡 쌓일 곳입니다.
3단계: rsyslog 설정 - 필터링과 DB 연동
이제 가장 핵심적인 단계입니다. rsyslog의 설정 파일을 수정하여, 특정 조건에 맞는 로그만 골라내어 MariaDB로 보내도록 설정할 것입니다. rsyslog의 설정은 /etc/rsyslog.conf 파일과 /etc/rsyslog.d/ 디렉터리에 있는 .conf 파일들로 이루어집니다. 시스템의 기본 설정을 건드리지 않고 유지보수를 용이하게 하기 위해, 우리는 /etc/rsyslog.d/ 디렉터리 안에 새로운 설정 파일을 만드는 방식을 사용할 것입니다.
60-mysql.conf라는 이름으로 새 설정 파일을 생성합니다.
sudo nano /etc/rsyslog.d/60-mysql.conf이 파일 안에 rsyslog에게 무엇을, 어떻게, 어디로 보낼지 지시하는 내용을 작성할 것입니다.
3.1. 기본 개념: RainerScript
최신 rsyslog는 RainerScript라는 진보된 스크립트 기반의 설정 구문을 사용합니다. 예전의 facility.priority 방식보다 훨씬 더 유연하고 강력한 필터링과 제어가 가능합니다. 우리는 RainerScript를 사용하여 필터링 규칙을 만들 것입니다.
RainerScript의 필터링은 기본적으로 if ... then ... 구조를 따릅니다.
if <조건문> then {
<수행할 동작>
}여기서 '조건문'은 로그 메시지의 다양한 속성(프로그램 이름, 호스트 이름, 메시지 내용 등)을 기반으로 만들어지며, '수행할 동작'은 해당 로그를 특정 파일에 저장하거나, 다른 서버로 보내거나, 우리가 하려는 것처럼 데이터베이스에 삽입하는 등의 작업을 정의합니다.
3.2. 설정 파일 작성: 모든 로그를 DB로 보내기 (기본)
먼저 필터링 없이 모든 로그를 DB로 보내는 가장 간단한 설정부터 시작해보겠습니다. 이를 통해 DB 연결이 제대로 작동하는지 확인할 수 있습니다. 60-mysql.conf 파일에 아래 내용을 입력하세요.
# #####################################################################
# ## MySQL/MariaDB 로 로그를 보내기 위한 설정 ##
# #####################################################################
# 1. ommysql 모듈을 로드합니다.
# 이 줄은 rsyslog에게 MySQL 데이터베이스와 통신하는 방법을 알려줍니다.
module(load="ommysql")
# 2. 모든 로그(*)를 대상으로 데이터베이스에 보내는 동작(action)을 정의합니다.
# 형식: *.* action(type="ommysql" server="서버주소" db="데이터베이스이름"
# uid="사용자이름" pwd="비밀번호")
#
# 아래 'your-strong-password' 부분은 2단계에서 설정한 DB 비밀번호로 반드시 변경해야 합니다.
action(
type="ommysql"
server="127.0.0.1"
db="Syslog"
uid="rsyslog_user"
pwd="your-strong-password"
)
위 설정은 매우 직관적입니다.
module(load="ommysql"): MySQL 모듈을 활성화합니다.action(...): 모든 로그(*.*에 해당, 여기서는 필터가 없으므로 모든 로그)에 대해 지정된 동작을 수행하라고 지시합니다.type="ommysql": 동작의 종류가 MySQL DB에 쓰는 것임을 명시합니다.server,db,uid,pwd: 2단계에서 설정한 데이터베이스 연결 정보를 정확하게 입력합니다.
3.3. 설정 파일 작성: 필터링 적용하기 (핵심)
이제 이 가이드의 핵심 주제인 '필터링'을 적용해 보겠습니다. 모든 로그를 DB에 저장하는 것은 엄청난 양의 데이터를 생성하여 저장 공간을 낭비하고, 정작 중요한 정보를 찾기 어렵게 만듭니다. 우리는 특정 조건에 맞는 로그만 DB에 저장하도록 규칙을 추가할 것입니다.
예를 들어, "SSH(sshd) 관련 로그와 커널(kernel) 메시지 중에서 심각도(severity)가 'warning' 이상인 로그만 DB에 저장하고 싶다"는 요구사항이 있다고 가정해 봅시다.
기존 60-mysql.conf 파일의 내용을 아래와 같이 수정하거나 새로 작성합니다.
# #####################################################################
# ## 특정 로그를 필터링하여 MySQL/MariaDB 로 보내기 위한 설정 ##
# #####################################################################
# 1. ommysql 모듈 로드
module(load="ommysql")
# 2. 필터링 규칙 및 DB 저장 액션 정의
# RainerScript의 if-then 구문을 사용합니다.
if ( \
# 조건 1: 프로그램 이름(programname)이 'sshd' 이거나
$programname == 'sshd' \
or \
# 조건 2: 프로그램 이름(programname)이 'kernel' 이고
# 로그 심각도(syslogseverity)가 4('warning') 이하인 경우
# (심각도는 숫자가 작을수록 높음: 0=emerg, 1=alert, 2=crit, 3=err, 4=warning)
($programname == 'kernel' and $syslogseverity <= 4) \
) then {
# 위의 조건에 맞는 로그에 대해서만 아래의 action을 수행합니다.
action(
type="ommysql"
server="127.0.0.1"
db="Syslog"
uid="rsyslog_user"
pwd="your-strong-password"
)
# stop: 이 규칙에 매칭된 로그는 이후의 다른 규칙에서 처리되지 않도록 합니다.
# DB 저장 후 /var/log/syslog 등에도 중복 저장되는 것을 막고 싶을 때 유용하지만,
# 여기서는 기본 로그 파일에도 남겨두기 위해 주석 처리합니다.
# stop
}
이 설정의 핵심은 if (...) then { ... } 블록입니다.
$programname: 로그를 생성한 프로세스/프로그램의 이름을 담고 있는 rsyslog의 내장 변수(속성)입니다.$syslogseverity: 로그의 심각도를 숫자로 나타내는 변수입니다. (0: Emergency, 1: Alert, ..., 6: Informational, 7: Debug)==,or,and,<=: 일반적인 프로그래밍 언어와 유사한 비교 및 논리 연산자를 사용하여 복잡한 조건을 만들 수 있습니다.action(...): 이제 이action은if조건문을 통과한 로그에만 적용됩니다.
더 많은 필터링 예시:
- 특정 메시지가 포함된 로그만 저장하기 (예: 'Failed password'):
if $msg contains 'Failed password' then { ... } - 특정 호스트에서 온 로그만 저장하기:
if $hostname == 'web-server-01' then { ... } - CRON 작업 로그는 제외하고 저장하기:
if not ($programname == 'CRON') then { ... }
이처럼 RainerScript를 활용하면 거의 모든 종류의 로그 필터링 시나리오를 구현할 수 있습니다. 여러분의 시스템 환경과 모니터링 목적에 맞게 필터링 조건을 자유롭게 수정하고 조합해보세요.
4단계: 설정 적용 및 검증
설정 파일 작성을 마쳤다면, 이제 rsyslog가 이 새로운 설정을 읽어 들이고 제대로 동작하는지 확인할 차례입니다.
4.1. 설정 파일 문법 검사
설정을 다시 시작하기 전에, 작성한 설정 파일에 문법적인 오류가 없는지 확인하는 것이 좋습니다. 오류가 있는 상태로 서비스를 재시작하면 rsyslog가 비정상적으로 종료될 수 있습니다. 다음 명령어로 문법 검사를 수행합니다.
sudo rsyslogd -N1만약 "rsyslogd: version ..., config validation run (level 1), master config /etc/rsyslog.conf OK." 와 유사한 메시지가 출력되고 오류가 보이지 않는다면 문법적으로 이상이 없는 것입니다. 오류가 있다면, 오류 메시지가 가리키는 줄 번호와 파일을 확인하여 수정해주세요.
4.2. rsyslog 서비스 재시작
문법 검사를 통과했다면, 변경된 설정을 적용하기 위해 rsyslog 서비스를 재시작합니다.
sudo systemctl restart rsyslog재시작 후 서비스가 정상적으로 실행 중인지 상태를 확인합니다.
sudo systemctl status rsyslogactive (running) 상태를 확인하고, 혹시라도 에러 로그가 출력되지 않았는지 주의 깊게 살펴봅니다.
4.3. 데이터베이스 확인
가장 확실한 검증 방법은 데이터베이스에 로그가 실제로 쌓이고 있는지 직접 확인하는 것입니다.
필터링 규칙에 맞는 로그를 인위적으로 발생시켜 봅시다. 예를 들어, SSH 접속을 시도하거나(성공 또는 실패) 시스템을 재부팅하여 커널 메시지를 생성할 수 있습니다. 잠시 기다린 후, MariaDB에 접속하여 SystemEvents 테이블의 내용을 조회합니다.
sudo mysql -u rsyslog_user -pDB에 접속한 후, 다음 쿼리를 실행합니다.
USE Syslog;
SELECT ID, ReceivedAt, FromHost, SysLogTag, Message FROM SystemEvents ORDER BY ID DESC LIMIT 10;이 쿼리는 가장 최근에 저장된 로그 10개를 보여줍니다. 만약 SSH(sshd)나 커널(kernel) 관련 로그들이 테이블에 나타난다면, 여러분의 설정이 성공적으로 작동하고 있는 것입니다! 만약 데이터가 보이지 않는다면, 다음 문제 해결 단계를 참고하세요.
문제 해결 (Troubleshooting)
설정 후 로그가 DB에 들어오지 않는 경우, 다음 사항들을 점검해보세요.
- rsyslog 상태 및 로그 확인:
sudo systemctl status rsyslog또는sudo journalctl -u rsyslog명령을 실행하여 rsyslog 자체의 에러 메시지를 확인합니다. "cannot connect to mysql server"와 같은 DB 연결 오류 메시지가 있는지 확인하세요. - DB 접속 정보 확인:
60-mysql.conf파일에 입력한 데이터베이스 이름, 사용자 이름, 비밀번호, 서버 주소가 정확한지 다시 한 번 확인합니다. 특히 비밀번호 오타가 흔한 실수입니다. - 방화벽 확인: 만약 rsyslog와 데이터베이스가 다른 서버에 있다면, 방화벽(
ufw,iptables등)이 데이터베이스 포트(기본 3306)로의 연결을 허용하고 있는지 확인해야 합니다. - 필터링 조건 확인: 설정한 필터링 조건이 너무 엄격하여 현재 시스템에서 발생하는 로그가 없는 것은 아닌지 확인합니다. 테스트를 위해 잠시 필터링 조건을 제거하고 모든 로그(
*.*)를 보내는 설정으로 변경하여 DB 연결 자체에 문제가 없는지 먼저 확인하는 것이 좋은 방법입니다. - SELinux/AppArmor: 드물지만, SELinux나 AppArmor 같은 보안 모듈이 rsyslog의 네트워크 연결을 차단할 수도 있습니다. 관련 로그(
/var/log/audit/audit.log또는/var/log/syslog)를 확인하여 권한 거부(permission denied) 메시지가 있는지 찾아보세요.
결론 및 다음 단계
축하합니다! 여러분은 이제 Ubuntu 서버에서 발생하는 로그를 실시간으로 필터링하여 데이터베이스에 저장하는 시스템을 성공적으로 구축했습니다. 이로써 여러분은 단순히 텍스트 파일의 나열이었던 로그를, SQL 쿼리를 통해 검색, 정렬, 집계할 수 있는 구조화된 데이터로 변환했습니다. 이는 시스템 모니터링, 보안 분석, 장애 대응 능력을 한 차원 높은 수준으로 끌어올리는 중요한 기반이 됩니다.
여기서 멈추지 마세요. 다음 단계로 나아갈 수 있습니다:
- 로그 시각화: Grafana, Metabase와 같은 대시보드 도구를 데이터베이스에 연결하여 시간에 따른 에러 발생 추이, 로그인 시도 IP 분포 등 로그 데이터를 시각적으로 분석할 수 있습니다.
- 고급 템플릿 사용: rsyslog의 템플릿 기능을 사용하면 데이터베이스에 저장되는 로그의 형식을 완전히 커스터마이징할 수 있습니다. 특정 정보만 추출하여 별도의 컬럼에 저장하는 등 고급 활용이 가능합니다.
- 로그 중앙화 확장: 여러 대의 서버에서 발생하는 로그를 하나의 중앙 rsyslog 서버로 전송하고, 이 중앙 서버가 필터링 후 데이터베이스에 저장하도록 구성하여 전사적인 로그 관리 시스템을 구축할 수 있습니다.
오늘 배운 rsyslog의 필터링과 DB 연동 기능은 시작에 불과합니다. rsyslog는 매우 유연하고 강력한 도구이므로, 공식 문서를 참고하여 여러분의 환경에 맞는 더욱 정교한 로그 관리 파이프라인을 만들어 보시길 바랍니다.
