안녕하세요. 오픈소스컨설팅에서 리눅스 엔지니어로 근무하고 있는 정광근 프로 입니다.

리눅스 서버를 구축/운영하는 엔지니어 분들의 경우 시스템 로그를 봐야 하는 일이 많습니다. 이런 시스템 로그를 맞춤형으로 설정하여 관리할 수 있다면 업무를 하시는데 훨씬 수월해지겠죠.

이처럼 시스템 로그를 효율적으로 관리하기 위해 1편에서는 시스템 로그를 설정하는 방법에 대해, 2편에서는 다양하게 관리할 수 있는 방안에 대해 이야기를 나누어 볼까 합니다.

시스템 로그란

커널, 데몬, 인증, 보안 등 의한 메시지 등 시스템이 동작하며 발생하는 다양한 종류의 커널 메시지나 응용프로그램 로그를 통틀어 시스템 로그라고 합니다.

rsyslog란 무엇인가

이렇게 커널 메시지나 응용프로그램 등에서 발생된 다양한 로그들은 rsyslogd라는 로그데몬을 통해 로그파일이나 콘솔, 또는 외부 서버로 로그를 저장하게 됩니다.

레드햇 계열(Redhat, CentOS, Oracle Linux 등)에서는 systemd 프로세스를 통해 rsyslog.service 서비스로 구현하여 이러한 역할을 수행하도록 하고 있습니다.

rsyslog는 설치할 필요가 없다?

rsyslog는 OS설치 단계 중 최소설치(minimal)기준으로도 설치되어 있으며 부팅 시 자동으로 동작하게 설정이 되어 있어 그동안 사용자들은 추가적으로 작업할 일이 없었습니다.

그렇다면 저는 왜 이 글을 적게 되었을까요?

저는 주로 구축보다는 운영 위주로 업무를 수행해왔습니다.
시스템을 운영하다 보면 문제점은 보이는데 이를 해결하기가 쉽지 않는 상황들을 겪게 됩니다.

중요하지는 않지만 그렇다고 않하면 안되는 그런…. 목에 걸린 잔가시 같은 느낌이라고나 할까요?

그 중 하나가 시스템 로그 및 주요 서비스 로그를 보관할 수 있는 로그 서버를 구축하는 것과 로그 보관 정책에 준하는 아카이빙 로그 보관 업무였습니다.

IDC나 공공기관에서는 최소 1년에서 3년까지 시스템과 주요 서비스의 로그를 보관하도록 정책이 수립되어 있지만, 대부분의 시스템 구축 사업에서는 이런 로그 시스템을 구축하지 않기 때문에 보관되어 있지 않는 경우가 허다 합니다.

막상 운영업무를 위임 받아 수행하다 보면 지난 아카이빙 로그를 찾아야 하거나 보관하고 있어야 하는 상황이 생기는데요. 먼저 장기간에 걸친 부하로 발생한 이슈를 확인하려면 과거의 데이터를 찾아야 하는 상황이 종종 발생합니다.

또한 보안 감사 같은 내부 정책을 증빙해야 하는 과정에서 로그 데이터를 보관하고 있어야 합니다.

시스템 로그 및 주요 서비스 로그를 기관의 정책에 맞게 보관을 해야 업무에 누수 없이, 잘 수행하고 있다고 말할 수 있겠죠.

이런 고민을 하게 되는 시점에서 시스템 로그 서버를 신규로 구축하려면 일단 예산부터 할당 받아야 합니다.

남는 서버를 잘 활용해서 이를 해결했다 하더라도 1년에서 3년 동안 다수의 시스템 로그를 보관할 수 있는 스토리지를 할당 받아야 합니다. 그리고 기존 시스템의 로그를 로그서버로 옮기는 작업을 해야 하죠.

예산이 필요할 수도 있고 서비스 운영 중인 시스템의 변경 작업도 필요하게 되는데, 이런 프로세스를 진행하는 일이 운영 조직에서는 여간 쉽지 않습니다.

이런 업무들은 서비스 운영 전에 이루어 져야 이슈가 발생해도 리스트가 적으며, 시스템 변경이 필요한 경우에도 좀 더 자유롭게 변경 및 테스트가 가능하기 때문에 운영 단계로 넘어오기 전에 구성하는 것이 여러모로 적절해 보입니다.

그래서 가장 좋은 방법은 시스템 구축 사업의 상세설계나 ISP, RFP같은 사전 설계 단계에서 부터 해당 기관의 정책에 부합하는 로그 시스템도 함께 구성되어야 한다고 생각하구요.

그럼에도 불구하고 운영 단계에서 시스템 로그 설정을 변경해야 하거나, 보관해야 하는 상황이 생겼을 때, 리스크 없이 손쉽게 작업할 수 있다면 좋겠다는 생각을 하여 이 글을 적게 되었습니다.

rsyslog 설치 방법

본문을 기재하는데 사용된 테스트 환경은 centos 7.9 버전을 사용하였습니다.

rsyslog가 설치되어 있지 않은 상태의 시스템이나 업데이트가 필요할 경우 yum install 명령어로 수행합니다.

[root@test21 ~]# yum install rsyslog
Dependencies Resolved
========================================================================================
 Package          Arch             Version              Repository           Size
=========================================================================================
Updating:
 rsyslog          x86_64       8.24.0-57.el7_9.3         updates              622 k
Transaction Summary
=========================================================================================
Upgrade  1 Package

테스트 서버의 상태값은 설치는 되어 있지만 실행이 되고 있지 않습니다.

[root@test21 ~]# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

     Docs: man:rsyslogd(8)

부팅시 자동으로 시작될 수 있도록 설정을 해줍니다.

[root@test21 ~]# systemctl enable rsyslog

Created symlink from /etc/systemd/system/multi-user.target.wants/rsyslog.service to /usr/lib/systemd/system/rsyslog.service.

rsyslog 서비스를 시작합니다. 

[root@test23 ~]# systemctl start rsyslog

부팅 시 자동으로 동작도 하게 되어 있구요. 서비스도 잘 실행되어 있는지 확인하였습니다.

[root@test21 ~]# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-06-30 01:41:47 EDT; 6s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 1001 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           └─1001 /usr/sbin/rsyslogd -n

Jun 30 01:41:47 test21 systemd[1]: Starting System Logging Service...
Jun 30 01:41:47 test21 rsyslogd[1001]:  [origin software="rsyslogd" swVersion="8.24.0-55.el7" x-pid="1001" x-info="http... start
Jun 30 01:41:47 test21 systemd[1]: Started System Logging Service.

위 작업을 한번에 수행하는 명령어는 아래와 같으니 참고하시면 좋을 것 같습니다. 

[root@test21 ~]# systemctl enable rsyslog --now

Created symlink from /etc/systemd/system/multi-user.target.wants/rsyslog.service to /usr/lib/systemd/system/rsyslog.service.

서비스 기동 후 프로세스 동작 유무와 포트가 활성화 되었는지 확인합니다.

[root@test21 ~]# ps -ef | grep rsyslog

root     11267     1  0 00:45 ?        00:00:00 /usr/sbin/rsyslogd -n

[root@test21 ~]# netstat -anp | grep rsyslog

unix  2      [ ]         DGRAM                    26342    11267/rsyslogd

[root@test21 sudoers.d]# lsof -i tcp:514
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

systemd   1 root   41u  IPv6  15106      0t0  TCP *:shell (LISTEN)

rsyslog 설정 방법

• 설정파일

rsyslog의 설정파일은 /etc/rsyslog.conf 이며 기본 설정값은 레드햇 계열에서는 아래와 같이 버전에 영향을 받지 않고 7,8버전 모두 동일 하게 구성되어 있습니다. 

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 :omusrmsg:*
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

• 설정값

Rsyslog에서 로그를 설정하는 인자값은 크게 Selector와 Action 구성되어 있으며, Selector는 세부적으로 Facility와 Priority로 나뉘어 집니다.

이제 각각의 인자값에 대해 알아볼 시간입니다.

• Facility

Selector 앞단에 위치한 Facility는 메시지를 발생 시키는 서비스 종류를 뜻합니다.

커널메시지, 데몬이 발생시키는 메시지, 사용자 인증 메시지 같은 다양한 종류가 있습니다.

Facility	설명
*	모든 서비스
kern	kernel 메시지
user	사용자에 의해 생성된 프로세스 메시지
mail	mail 시스템에 의해 발생되는 메시지
daemon	daemon에 의해 발생된 메시지
auth	login 같은 사용자 인증 관련 메시지
syslog	syslogd에 의해 발생되는 메시지
lpr	lpd에 의해 발생되는 메시지
news	유즈넷 뉴스시스템에 의해 발생되는 메시지
uucp	uucp시스템이 발생 시킨 메시지
authpriv	보안 및 승인에 관한 메시지
cron	cron같은 스케줄링 프로그램에 의해 발생되는 메시지
local0 ~ local7	시스템 부팅 메시지 기록, 기타 여분 서비스에 사용하기 위함.

• Priority

 각각의 Facility마다 구현할 수준의 Priority라는 로그 레벨을 설정하게 됩니다.

Priority는 emerg 부터 debug까지 총 8단계의 레벨중에 선택하면 되는데, 상황에 따라서 모든 레벨을 포함하거나 지정하지 않기도 합니다.

높은 단계로 설정 할 수록 중요 정보만 남기 때문에 이슈에 대한 빠른 파악이 가능하지만, 사전 대비가 어려울 수 있습니다.

반대로 너무 낮은 레벨로 설정할 경우 메시지가 많아 가독성이 떨어져 정확한 원인 파악을 위해 많은 로그를 살펴보는 지체될 수 있으므로 서비스 형태에 맞추어 적정 수준을 선택하는 것이 바람직 해 보입니다.

Priority	설명
emerg	패닉 상황으로 모든 담당자들에게 연락해야 하는 경우.여러 앱, 서버, 사이트에 영향력 끼치는 메시지
alert	즉각적인 조치가 필요한 상황의 메시지
crit	하드웨어 등의 치명적인 오류에 관한 메시지
err	일반적인 에러/오류에 관한 메시지
warning	긴급 장애는 아니지만 경고에 준하는 메시지
notice	에러는 아니지만 관리자의 확인이 필요한 메시지
info	단순 정보 및 통계성 메시지
debug	개발 수준의 디버깅 관련 메시지
none	어떠한 경우라도 메시지를 저장하지 않음
*	발생하는 모든 상황에 대한 메시지

• Action

마지막으로 Action은 로그의 End Point를 지정하는 역할을 합니다.

로그가 저장될 파일 위치를 지정하거나 콘솔, 원격 로그 서버, 특정 사용자 등에 로그를 남길 수도 있습니다.

Action	설명
로그 파일	로그 저장위치를 풀경로로 지정
콘솔	/dev/console로 지정 시 콘솔 출력
원격 로그 서버	로그서버 IP설정을 통해 지정한 호스트로 로그를 보냄
user	지정된 사용자의 스크린으로 메시지를 보냄
*	현재 로그인 되어있는 모든 사용자의 스크린으로 메시지를 보냄

•  적용 방안

rsyslog에서 설정값을 적용 시키는 방법은 서비스와 원하는 로그 서비스(Facility)와 로그 레벨(Priority)을 선택한 후 저장 방식(Action)을 작성하는 형태로 이루어 집니다.

facility.priority;  action

예시로 default 값인 messages 설정을 한번 보겠습니다.

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

위 설정값이 의미하는 내용은 모든 시스템 내 동작 되는 모든 info 레벨의 메시지를 저장하고 싶은데 그중에 mail, authpriv, cron은 제외한다는 내용입니다.

개인적인 소견으로 제외된 서비스들은 secure나 cron, maillog등 로그 파일에 남기도록 default로 설정 되어 있기 때문에 제외한 것으로 보입니다.

Selector의 개수는 특별히 제한이 있지 않고 두개 이상일 경우에도 앞뒤 순서는 동작과 무관합니다.

다수의 엔지니어가 함께 사용하는 시스템은 기본 설정을 변경하기 어려운 경우가 있을 수도 있습니다.

그런 상황에서는 아래처럼 원하는 형태의 로그 파일을 추가하여 따로 관리하는 것도 좋을 듯 합니다.

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

daemon.err;mail.none;authpriv.none;cron.none                /var/log/daemon-error

kern.warn;mail.none;authpriv.none;cron.none                /var/log/kernel-warning

rsyslog 테스트 – 첫번째

rsyslog를 어떻게 다루어야 하는지 알아봤으니 이제 입맛에 맞게 시스템 로그를 쌓아 보겠습니다.

먼저 시스템 하드웨어 자원 변화에 따른 Priority 별 로그 메시지를 확인해 보겠습니다.

이 테스트를 통해 필요한 정보가 어느 레벨에 구현되어 있는지를 간단하게 확인 해 볼 수 있습니다.

• (인증) 신규로 SSH 접속하여 login session을 추가해 보겠습니다.

ssh login의 경우 secure에서 확인이 가능하기 때문에 daemon, auth서비스 항목의 info 레벨에서만 간단한 로그를 생성하는 수준이었습니다.

test서버로 접속

[root@test23 ~]# ssh test21
root@test21's password:
Last login: Thu Jun 30 03:09:19 2022 from test23
[root@test21 ~]#

info 레벨 로그 확인

Jun 28 04:21:44 test21 systemd: Started Session 4 of user root.

Jun 28 04:21:44 test21 systemd-logind: New session 4 of user root.

notice레벨  로그 확인  

없음

warning 레벨 로그 확인

없음

• (디바이스)mount/umount 명령어를 통한 디바이스 변경사항에 대해서도 각 레벨별로 더 자세한 로그로 남기는 것을 확인 할 수 있었습니다.

테스트 볼륨 마운트/언마운트

[root@test21 ~]# mount /dev/mapper/vol1-test1 /data1
[root@test21 ~]# mount /dev/mapper/vol1-test2 /data2
[root@test21 ~]# umount /data1
[root@test21 ~]# umount /data2

info 레벨

Jun 28 04:21:49 test21 kernel: XFS (dm-3): Mounting V5 Filesystem
Jun 28 04:21:49 test21 kernel: XFS (dm-3): Ending clean mount
Jun 28 04:22:00 test21 kernel: XFS (dm-4): Mounting V5 Filesystem
Jun 28 04:22:00 test21 kernel: XFS (dm-4): Ending clean mount
Jun 28 04:43:46 test21 kernel: XFS (dm-3): Unmounting Filesystem

Jun 28 04:43:47 test21 kernel: XFS (dm-4): Unmounting Filesystem

 notice레벨

Jun 28 04:32:36 test21 kernel: XFS (dm-3): Mounting V5 Filesystem
Jun 28 04:32:38 test21 kernel: XFS (dm-4): Mounting V5 Filesystem
Jun 28 04:32:31 test21 kernel: XFS (dm-3): Unmounting Filesystem

Jun 28 04:32:32 test21 kernel: XFS (dm-4): Unmounting Filesystem

warning 레벨

없음

• (네트워크)인터페이스 down/up에 의한 상태 변경에 대한 로그는 레벨에 따른 차이가 있어 보입니다.

테스트용 인터페이스 다운/업

[root@test21 ~]# ifdown eth1
Device 'eth1' successfully disconnected.
[root@test21 ~]# ifup eth1
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

[root@test21 ~]#

info레벨

Jun 28 04:22:20 test21 NetworkManager[686]: <info>  [1656404540.1023] device (eth1): state change: activated -> deactivating (reason 'user-requested', sys-iface-state: 'managed')
Jun 28 04:22:20 test21 NetworkManager[686]: <info>  [1656404540.1066] audit: op="device-disconnect" interface="eth1" ifindex=3 pid=2476 uid=0 result="success"
Jun 28 04:22:20 test21 systemd: Starting Network Manager Script Dispatcher Service...
Jun 28 04:22:20 test21 NetworkManager[686]: <info>  [1656404540.1066] device (eth1): state change: deactivating -> disconnected (reason 'user-requested', sys-iface-state: 'managed')
Jun 28 04:22:20 test21 dbus[678]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jun 28 04:22:20 test21 dbus[678]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun 28 04:22:20 test21 systemd: Started Network Manager Script Dispatcher Service.
Jun 28 04:22:20 test21 nm-dispatcher: req:1 'down' [eth1]: new request (3 scripts)
Jun 28 04:22:20 test21 nm-dispatcher: req:1 'down' [eth1]: start running ordered scripts...
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0476] agent-manager: req[0x55d6a2595d50, :1.68/nmcli-connect/0]: agent registered
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0489] device (eth1): Activation: starting connection 'eth1' (9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04)
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0490] audit: op="connection-activate" uuid="9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04" name="eth1" pid=2519 uid=0 result="success"
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0490] device (eth1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0492] device (eth1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0495] device (eth1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0502] device (eth1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0505] device (eth1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0506] device (eth1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jun 28 04:22:28 test21 NetworkManager[686]: <info>  [1656404548.0576] device (eth1): Activation: successful, device activated.
Jun 28 04:22:28 test21 nm-dispatcher: req:2 'up' [eth1]: new request (3 scripts)

Jun 28 04:22:28 test21 nm-dispatcher: req:2 'up' [eth1]: start running ordered scripts...

notice레벨

Jun 28 04:41:06 test21 dbus[678]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'

Jun 28 04:41:06 test21 dbus[678]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

warning 레벨

없음

• (응용프로그램)httpd 데몬을 정상적인 형태로 시작/중지 해보았을 때 다음과 같이 로그가 발생하였습니다.

http데몬 시작/중지

[root@test21 ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2022-06-30 03:14:33 EDT; 5s ago
Docs: man:httpd(8)
man:apachectl(8)
Main PID: 6246 (httpd)
Status: "Processing requests..."
CGroup: /system.slice/httpd.service
├─6246 /usr/sbin/httpd -DFOREGROUND
├─6247 /usr/sbin/httpd -DFOREGROUND
├─6248 /usr/sbin/httpd -DFOREGROUND
├─6249 /usr/sbin/httpd -DFOREGROUND
├─6250 /usr/sbin/httpd -DFOREGROUND
└─6251 /usr/sbin/httpd -DFOREGROUND

Jun 30 03:14:33 test21 systemd[1]: Starting The Apache HTTP Server...
Jun 30 03:14:33 test21 httpd[6246]: AH00558: httpd: Could not reliably determine the server's fully qualified domain n...message
Jun 30 03:14:33 test21 systemd[1]: Started The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

[root@test21 ~]# systemctl stop httpd

info레벨

Jun 28 04:49:10 test21 systemd: Starting The Apache HTTP Server...
Jun 28 04:49:10 test21 httpd: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::8fc1:5d44:e85a:1b0c. Set the 'ServerName' directive globally to suppress this message
Jun 28 04:49:10 test21 systemd: Started The Apache HTTP Server.
Jun 28 04:49:16 test21 systemd: Stopping The Apache HTTP Server...

Jun 28 04:49:17 test21 systemd: Stopped The Apache HTTP Server.

notice레벨

없음

warning 레벨

없음

정상적인 절차로 이루어진 상황이라 info정보만 나타난 것으로 보이며, 비정상적인 상황이 발생하였다면 상위 레벨에서 에러 메시지가 발생되었을 것으로 예상됩니다.

• (응용프로그램)tomcat 역시 info 레벨에서만 시작/중지에 대한 로그를 확인할 수 있었습니다.

tomcat 데몬 시작/중지

[root@test21 ~]# systemctl start tomcat
[root@test21 ~]# systemctl status tomcat
● tomcat.service - Apache Tomcat Web Application Container
Loaded: loaded (/usr/lib/systemd/system/tomcat.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2022-06-30 03:12:39 EDT; 5s ago
Main PID: 6083 (java)
CGroup: /system.slice/tomcat.service
└─6083 /usr/lib/jvm/jre/bin/java -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -cl...

Jun 30 03:12:40 test21 server[6083]: Jun 30, 2022 3:12:40 AM org.apache.catalina.core.StandardService startInternal
Jun 30 03:12:40 test21 server[6083]: INFO: Starting service Catalina
Jun 30 03:12:40 test21 server[6083]: Jun 30, 2022 3:12:40 AM org.apache.catalina.core.StandardEngine startInternal
Jun 30 03:12:40 test21 server[6083]: INFO: Starting Servlet Engine: Apache Tomcat/7.0.76
Jun 30 03:12:40 test21 server[6083]: Jun 30, 2022 3:12:40 AM org.apache.coyote.AbstractProtocol start
Jun 30 03:12:40 test21 server[6083]: INFO: Starting ProtocolHandler ["http-bio-8080"]
Jun 30 03:12:40 test21 server[6083]: Jun 30, 2022 3:12:40 AM org.apache.coyote.AbstractProtocol start
Jun 30 03:12:40 test21 server[6083]: INFO: Starting ProtocolHandler ["ajp-bio-8009"]
Jun 30 03:12:40 test21 server[6083]: Jun 30, 2022 3:12:40 AM org.apache.catalina.startup.Catalina start
Jun 30 03:12:40 test21 server[6083]: INFO: Server startup in 47 ms

[root@test21 ~]# systemctl stop tomcat

info레벨

Jun 28 04:54:29 test21 systemd: Started Apache Tomcat Web Application Container.
Jun 28 04:54:29 test21 server: Java virtual machine used: /usr/lib/jvm/jre/bin/java
⁞
Jun 28 04:54:30 test21 server: INFO: Starting Servlet Engine: Apache Tomcat/7.0.76
Jun 28 04:54:30 test21 server: Jun 28, 2022 4:54:30 AM org.apache.coyote.AbstractProtocol start
Jun 28 04:54:30 test21 server: INFO: Starting ProtocolHandler ["http-bio-8080"]
Jun 28 04:54:30 test21 server: Jun 28, 2022 4:54:30 AM org.apache.coyote.AbstractProtocol start
Jun 28 04:54:30 test21 server: INFO: Starting ProtocolHandler ["ajp-bio-8009"]
Jun 28 04:54:30 test21 server: Jun 28, 2022 4:54:30 AM org.apache.catalina.startup.Catalina start
Jun 28 04:54:30 test21 server: INFO: Server startup in 53 ms
 
Jun 28 04:54:40 test21 systemd: Stopping Apache Tomcat Web Application Container...
Jun 28 04:54:40 test21 server: Jun 28, 2022 4:54:40 AM org.apache.coyote.AbstractProtocol pause
⁞
Jun 28 04:54:40 test21 server: Jun 28, 2022 4:54:40 AM org.apache.coyote.AbstractProtocol destroy
Jun 28 04:54:40 test21 server: INFO: Destroying ProtocolHandler ["http-bio-8080"]
Jun 28 04:54:40 test21 server: Jun 28, 2022 4:54:40 AM org.apache.coyote.AbstractProtocol destroy
Jun 28 04:54:40 test21 server: INFO: Destroying ProtocolHandler ["ajp-bio-8009"]

Jun 28 04:54:40 test21 systemd: Stopped Apache Tomcat Web Application Container

notice레벨

없음

warning 레벨

없음

rsyslog 테스트 – 두번째

설정값 변경 후 적용이 잘 되었는지 어떻게 알 수 있을까요?

원하는 메시지가 발생하거나 또는 발생하지 않는지 메시지 파일을 계속 열어봐야 할까요?

그럴 때 우리는 logger를 통해서 발생한 메시지를 통해 변경된 설정값이 잘 적용되었는지 확인해 볼 수 있습니다.

• Priority 변경에 따른 로그 메시지 확인 (logger)

메시지 파일에 대한 로그레벨을 info 등급으로 설정합니다.

[root@test21 ~]# grep /var/log/messages /etc/rsyslog.conf

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

각 로그 단계별로 메시지를 발생 시킵니다.

[root@test21 ~]# logger -p daemon.info -t osci-tool.info "daemon이 정상적으로 동작하였습니다."
[root@test21 ~]# logger -p daemon.notice -t osci-tool.notice "클러스터간 이중화 체크가 정상적으로 확인되었습니다."
[root@test21 ~]# logger -p daemon.warn -t osci-tool.warn "클러스터간 통신상태가 원활하지 않습니다."

로그를 확인해 보니 info 이상 등급의 메시지가 잘 나타나는 것을 볼 수 있습니다.

[root@test21 ~]# tailf /var/log/messages
Jun 28 21:09:48 test21 osci-tool.info: daemon이 정상적으로 동작하였습니다.
Jun 28 21:10:29 test21 osci-tool.notice: 클러스터간 이중화 체크가 정상적으로 확인되었습니다.

Jun 28 21:11:07 test21 osci-tool.warn: 클러스터간 통신상태가 원활하지 않습니다.

메시지 파일에 대한 로그레벨을 warning 등급으로 설정합니다.

[root@test21 ~]# grep /var/log/messages /etc/rsyslog.conf

*.warn;mail.none;authpriv.none;cron.none                /var/log/messages

각 로그 단계별로 메시지를 발생 시킵니다.

[root@test21 ~]# logger -p daemon.info -t osci-tool.info "daemon이 정상적으로 동작하였습니다."
[root@test21 ~]# logger -p daemon.notice -t osci-tool.notice "클러스터간 이중화 체크가 정상적으로 확인되었습니다.
"
[root@test21 ~]# logger -p daemon.warn -t osci-tool.warn "클러스터간 통신상태가 원활하지 않습니다."

로그를 확인해 보니 info/notice 등급의 메시지가 발생하지 않았다는 것을 볼 수 있습니다.

[root@test21 ~]# tailf /var/log/messages

Jun 28 21:12:38 test21 osci-tool.warn: 클러스터간 통신상태가 원활하지 않습니다.

※ 참고로 테스트 중에 Facility를 kernel로 설정한 경우 log가 제대로 출력되지 않는 현상이 있었습니다.
kernel Facility는 로컬 커널에 의해 생성되는 메시지를 위해 예약되어 있어 logger를 통해 해당 Facility로 메시지를 생성할 경우 자동으로 user Facility 로 변경된다고 합니다.

이럴 때에는 Facility값을 단독으로 설정한 경우가 아닐 경우(*처럼 모두를 포함하는 경우) 다른 Facility값을 기준으로 삼아서 확인해야 하는 점 참고 하시면 좋을 것 같습니다.

마치며…

이렇게 시스템 로그를 관리해 주는 rsyslog의 기본 구성을 파악하고, 설정값을 이해하게 되었습니다.

그리고 로그 레벨에 따라 어떤 메시지가 발생하는지, 로그 레벨 변경 후 잘 적용되었는지 확인하는 방법까지 알게 되었습니다.

2편에서는 시스템 로그를 다양하게 관리할 수 있는 방안에 대해 이야기를 나누어 볼 건데요.

먼저 로그 서버를 구축하고 연동하여 시스템 로그를 통합 관리하는 방안과, 시스템 로그를 DB에 저장하여 관리하는 방법, 그리고 마지막으로 이벤트 발생 시 사용자에게 알릴 수 있는 다양한 방법에 대해 알아보는 시간을 갖도록 하겠습니다.

참고 사이트

• https://www.rsyslog.com/
• https://dosunny.tistory.com/114
• https://tragramming.tistory.com/86
• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=carmine1025&logNo=220569972707
• https://success.trendmicro.com/dcx/s/solution/TP000086250?language=en_US
• http://wiki.pchero21.com/wiki/Syslog