소개
이 실습에서는 journalctl과 rsyslog를 사용하여 Red Hat Enterprise Linux 9에서 시스템 로그를 분석하고 저장하는 실무 경험을 쌓습니다. 먼저 systemd-journald와 rsyslog의 역할을 포함한 시스템 로깅의 핵심 아키텍처를 이해하고 주요 로그 파일을 식별합니다. 이후 일반적인 명령어를 사용하여 syslog 파일을 검토 및 필터링하고, 사용자 지정 syslog 메시지를 수동으로 전송하며, journalctl을 통해 시스템 저널 항목을 탐색하고 필터링하는 방법을 배웁니다. 또한 영구적인 시스템 저널 저장소 구성과 timedatectl 및 chronyd를 사용한 정확한 시스템 시간 유지 방법을 다루며, 시스템 분석 및 문제 해결에 필요한 필수 기술을 습득합니다.
시스템 로그 아키텍처 및 주요 파일 이해
이 단계에서는 Red Hat Enterprise Linux 9의 시스템 로깅 구성 요소인 systemd-journald 및 rsyslog 서비스와 이들이 관리하는 주요 로그 파일에 대해 알아봅니다. 이 아키텍처를 이해하는 것은 효과적인 시스템 분석과 문제 해결을 위해 매우 중요합니다.
먼저 systemd-journald 서비스를 살펴보겠습니다. 이 서비스는 운영 체제 이벤트 로깅의 핵심입니다. 시스템 커널, 초기 부팅 프로세스, 데몬의 표준 출력/오류, syslog 이벤트 등 다양한 소스에서 이벤트 메시지를 수집합니다. systemd-journald 서비스는 이러한 로그를 journal이라는 구조화되고 인덱싱된 바이너리 파일에 저장합니다.
다음으로 rsyslog 서비스를 살펴보겠습니다. systemd-journald가 로그를 수집하는 동안, rsyslog는 저널에서 syslog 메시지가 들어오는 즉시 이를 읽어 들입니다. 그런 다음 이 메시지를 처리하여 /var/log 디렉터리의 전통적인 로그 파일에 기록하거나 구성에 따라 다른 서비스로 전달합니다. 이러한 rsyslog 파일은 재부팅 후에도 유지됩니다.
/var/log 디렉터리에서 rsyslog가 관리하는 중요한 로그 파일들을 살펴보겠습니다. ls 명령어를 사용하여 이 디렉터리의 내용을 나열할 수 있습니다.
ls /var/log
다양한 로그 파일 목록이 표시됩니다. 시스템에 따라 anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure 등의 파일을 볼 수 있습니다. 가장 일반적인 파일은 다음과 같습니다.
/var/log/messages: 인증, 이메일 처리, 예약된 작업 실행 및 디버깅 관련 메시지를 제외한 대부분의 일반적인 syslog 메시지가 포함되어 있습니다./var/log/secure: 보안 및 인증 이벤트와 관련된 syslog 메시지를 저장합니다./var/log/maillog: 메일 서버에 대한 syslog 메시지가 포함되어 있습니다./var/log/cron: 예약된 작업 실행에 대한 syslog 메시지를 기록합니다./var/log/boot.log: 시스템 시작에 대한 비-syslog 콘솔 메시지가 포함되어 있습니다.
이 파일들의 내용을 보려면 cat, less, tail과 같은 명령어를 사용할 수 있습니다. /var/log의 대부분의 로그 파일은 읽기 위해 루트 권한이 필요하므로 sudo를 사용해야 합니다. 예를 들어, tail을 사용하여 /var/log/messages 파일의 마지막 몇 줄을 확인해 보겠습니다.
sudo tail /var/log/messages
보안 감사를 위해 중요한 /var/log/secure 파일의 내용도 확인할 수 있습니다.
sudo tail /var/log/secure
이 파일들의 목적을 이해하면 시스템 문제를 해결할 때 관련 정보를 빠르게 찾는 데 도움이 됩니다.
일반 명령어를 사용한 Syslog 파일 검토 및 필터링
이 단계에서는 일반적인 Linux 명령어를 사용하여 syslog 파일을 효과적으로 검토하고 필터링하는 방법을 배웁니다. Syslog 메시지는 facility(메시지를 생성하는 하위 시스템)와 priority(메시지의 심각도)로 분류됩니다. 이러한 범주를 이해하는 것은 효율적인 로그 분석에 필수적입니다.
먼저 Syslog Facility와 Priority의 개념을 검토해 보겠습니다.
Syslog Facilities: 로그 메시지의 출처를 나타냅니다. 예로는 kern(커널 메시지), user(사용자 수준 메시지), mail(메일 시스템 메시지), daemon(시스템 데몬 메시지), auth(인증 및 보안 메시지), cron(클록 데몬 메시지) 등이 있습니다.
Syslog Priorities: 메시지의 심각도를 정의하며 emerg(시스템 사용 불가)에서 debug(디버깅 수준 메시지)까지 다양합니다. 심각도가 높은 순서대로 나열하면 emerg, alert, crit, err, warning, notice, info, debug입니다.
로그 파일은 매우 커질 수 있어 특정 정보를 찾기 어려울 수 있습니다. 따라서 필터링이 필수적입니다. grep, awk, sed와 같은 명령어를 사용하여 로그 파일 내용을 필터링할 수 있습니다.
먼저 less를 사용하여 /var/log/messages의 전체 내용을 확인해 보겠습니다. 이 명령어를 사용하면 파일을 스크롤할 수 있습니다. q를 눌러 less를 종료합니다. 로그 파일을 읽으려면 루트 권한이 필요하므로 sudo를 사용하는 것을 잊지 마세요.
sudo less /var/log/messages
이제 메시지를 필터링해 보겠습니다. 인증(authentication) 관련 메시지에 관심이 있다고 가정해 봅시다. 이러한 메시지는 일반적으로 /var/log/secure에 있습니다. grep을 사용하여 /var/log/secure에서 "authentication"이라는 단어가 포함된 줄을 검색합니다. 로그 파일에 액세스하려면 sudo를 사용하세요.
sudo grep "authentication" /var/log/secure
최근 인증 메시지가 없으면 출력이 표시되지 않을 수 있습니다. SSH 데몬과 관련된 "sshd"와 같은 더 일반적인 검색어를 시도해 보겠습니다.
sudo grep "sshd" /var/log/secure
SSH 데몬 활동, 인증 시도 또는 기타 보안 관련 이벤트가 표시될 것입니다. 정확한 출력은 현재 시스템 활동에 따라 다르며 다음과 같은 항목이 포함될 수 있습니다.
Dec 16 10:15:30 host sshd[1234]: Accepted publickey for labex from 172.25.0.10 port 12345 ssh2
Dec 16 10:15:30 host sshd[1234]: pam_unix(sshd:session): session opened for user labex(uid=1000) by (uid=0)
...output omitted...
로그 메시지에는 타임스탬프도 포함되어 있습니다. 날짜와 시간별로 메시지를 필터링할 수 있습니다. 예를 들어 특정 날짜의 메시지를 보려면 grep과 날짜를 결합할 수 있습니다. /var/log/messages에서 오늘 날짜의 메시지를 찾아보겠습니다. 시스템 로그에 나타나는 현재 날짜 형식을 사용하세요.
sudo grep "$(date '+%b %d')" /var/log/messages
로그 파일 로테이션:
로그 파일이 너무 많은 디스크 공간을 차지하지 않도록 시스템은 logrotate를 사용합니다. 이 유틸리티는 로그 파일을 회전시켜 이전 파일을 이름 변경하고(예: /var/log/messages가 /var/log/messages-20220320이 됨) 새 빈 파일을 만듭니다. 일정 기간(보통 4주)이 지나면 가장 오래된 회전된 로그 파일은 삭제됩니다. 예약된 작업이 매일 logrotate를 실행하여 이 프로세스를 관리합니다.
/var/log의 내용을 다시 나열하여 회전된 로그 파일을 관찰할 수 있습니다. 날짜 확장자나 .gz 확장자(압축된 경우)가 있는 파일을 볼 수 있습니다.
ls -l /var/log/messages*
예시 출력:
-rw-------. 1 root root 123456 Mar 20 23:59 /var/log/messages
-rw-------. 1 root root 78901 Mar 13 23:59 /var/log/messages-20220320
-rw-------. 1 root root 54321 Mar 06 23:59 /var/log/messages-20220313.gz
...output omitted...
이는 logrotate가 이전 로그 파일을 어떻게 관리하는지 보여줍니다.
마지막으로 syslog 항목의 구조를 분석해 보겠습니다. /var/log/secure의 일반적인 로그 메시지는 다음과 같습니다.
Dec 16 10:11:48 host sshd[1433]: Failed password for student from 172.25.0.10 port 59344 ssh2
Dec 16 10:11:48: 로그 항목의 타임스탬프.host: 로그 메시지를 보낸 호스트.sshd[1433]: 로그 메시지를 보낸 프로그램 또는 프로세스 이름(sshd)과 PID(1433).Failed password for …: 실제 메시지 내용.
이 형식을 이해하면 로그 항목을 더 효과적으로 구문 분석하고 해석하는 데 도움이 됩니다.
수동으로 사용자 지정 Syslog 메시지 전송
이 단계에서는 logger 명령어를 사용하여 사용자 지정 syslog 메시지를 수동으로 전송하는 방법을 배웁니다. 이는 rsyslog 서비스 구성을 테스트하거나 디버깅 또는 모니터링 목적으로 시스템 로그에 사용자 지정 메시지를 삽입하는 데 유용한 기술입니다.
logger 명령어는 rsyslog 서비스로 메시지를 보냅니다. 기본적으로 -p 옵션으로 다르게 지정하지 않는 한 user facility와 notice priority(user.notice)로 메시지를 보냅니다.
먼저 일반적으로 /var/log/messages인 기본 로그 위치로 간단한 테스트 메시지를 보내 보겠습니다.
logger "This is a test message from labex."
명령어를 실행한 후 /var/log/messages 파일을 확인하여 메시지가 기록되었는지 확인할 수 있습니다. tail을 사용하여 파일의 마지막 몇 줄을 확인하세요. 로그 파일에 액세스하려면 sudo를 사용하세요.
sudo tail /var/log/messages
출력 끝에 다음과 같이 사용자 지정 메시지가 표시되어야 합니다.
...
Dec 16 10:30:00 host labex: This is a test message from labex.
이제 특정 facility와 priority로 메시지를 보내 보겠습니다. 이전 단계에서 syslog 메시지가 facility와 priority별로 분류된다는 점을 기억하세요. 예를 들어 local7.notice는 메시지가 local7 facility와 notice priority로 기록됨을 의미합니다. local7 facility는 종종 사용자 지정 애플리케이션이나 부팅 메시지에 사용되며, 일반적으로 rsyslog 구성에 의해 /var/log/boot.log로 전달됩니다.
/var/log/boot.log 로그 파일에 기록되도록 rsyslog 서비스에 메시지를 보내려면 다음 logger 명령어를 실행하세요.
logger -p local7.notice "Log entry created by labex for boot.log"
이제 이 메시지가 /var/log/boot.log에 기록되었는지 확인하세요. 로그 파일에 액세스하려면 sudo를 사용하세요.
sudo tail /var/log/boot.log
출력에서 사용자 지정 메시지를 볼 수 있습니다.
...
Dec 16 10:31:00 host labex: Log entry created by labex for boot.log
이는 facility와 priority를 지정하여 사용자 지정 메시지가 기록되는 위치를 제어하는 방법을 보여줍니다. 이 기능은 rsyslog 구성을 테스트하고 시스템 로그에 특정 이벤트를 삽입하는 데 매우 유용합니다.
journalctl을 사용하여 시스템 저널 항목 탐색 및 필터링
이 단계에서는 journalctl 명령어를 사용하여 시스템 저널 항목을 탐색하고 필터링하는 방법을 배웁니다. 배운 바와 같이 systemd-journald 서비스는 로깅 데이터를 journal이라는 구조화되고 인덱싱된 바이너리 파일에 저장합니다. journalctl 명령어는 이 저널과 상호 작용하는 기본 도구입니다.
먼저 저널의 모든 메시지를 확인해 보겠습니다. 옵션 없이 journalctl을 실행하면 가장 오래된 항목부터 모든 사용 가능한 로그 항목이 표시됩니다. sudo 권한이 있는 labex로 로그인되어 있으므로 저널에 대한 전체 액세스 권한을 갖게 됩니다.
journalctl
많은 양의 출력이 표시됩니다. q를 눌러 journalctl 뷰어를 종료합니다. journalctl이 중요한 로그 메시지를 강조 표시한다는 점에 주목하세요. notice 또는 warning priority의 메시지는 굵은 텍스트로, error priority 이상의 메시지는 빨간색 텍스트로 표시됩니다.
이제 필터링 및 특정 항목 보기를 위한 몇 가지 일반적인 journalctl 옵션을 살펴보겠습니다.
1. 마지막 N개의 로그 항목 보기 (-n 옵션):
기본적으로 journalctl -n은 마지막 10개의 로그 항목을 보여줍니다. 다른 숫자를 지정할 수 있습니다(예: 마지막 5개 항목).
journalctl -n 5
가장 최근의 로그 항목 5개가 표시됩니다.
2. 새 저널 항목 팔로우 (-f 옵션):
tail -f 명령어와 유사하게 journalctl -f 옵션은 시스템 저널의 마지막 10줄을 출력하고 새로운 저널 항목이 추가될 때마다 계속 출력합니다. 이는 실시간 모니터링에 매우 유용합니다.
journalctl -f
이 연속 출력을 종료하려면 Ctrl+C를 누르세요.
3. Priority별 필터링 (-p 옵션):
저널 항목의 priority 수준별로 출력을 필터링할 수 있습니다. journalctl -p 옵션은 지정된 priority 수준(이름 또는 번호) 이상의 항목을 보여줍니다. 오름차순으로 priority 수준은 debug, info, notice, warning, err, crit, alert, emerg입니다.
err priority 이상의 저널 항목을 나열해 보겠습니다.
journalctl -p err
다양한 시스템 구성 요소와 관련된 오류 메시지가 표시될 수 있습니다.
4. systemd 유닛별 필터링 (-u 옵션):
journalctl -u 옵션과 유닛 이름을 사용하여 지정된 systemd 유닛에 대한 메시지를 표시할 수 있습니다. 예를 들어 sshd 서비스에 대한 로그를 구체적으로 보려면 다음과 같이 합니다.
journalctl -u sshd.service
SSH 데몬과 관련된 모든 로그 항목이 표시됩니다.
5. 시간 범위별 필터링 (--since 및 --until 옵션):
특정 이벤트를 찾을 때 출력을 특정 시간 프레임으로 제한할 수 있습니다. --since 및 --until 옵션은 모두 "YYYY-MM-DD hh:mm:ss" 형식의 시간 인수를 취합니다. 인수에 공백이 있는 경우 큰따옴표가 필요합니다. yesterday, today, tomorrow와 같은 상대적인 용어나 "-1 hour"와 같은 시간 지속 시간을 사용할 수도 있습니다.
오늘 시작부터의 모든 저널 항목을 확인해 보겠습니다.
journalctl --since today
이제 지난 1시간 동안의 항목을 확인해 보겠습니다.
journalctl --since "-1 hour"
6. 자세한 출력 보기 (-o verbose 옵션):
내부 저널 필드를 포함하여 각 로그 항목에 대한 추가 세부 정보를 보려면 -o verbose 옵션을 사용할 수 있습니다. 이는 고급 문제 해결에 도움이 될 수 있습니다.
journalctl -n 1 -o verbose
마지막 로그 항목과 모든 자세한 세부 정보가 표시됩니다. _COMM(명령 이름), _EXE(실행 파일 경로), _PID(프로세스 ID), _UID(사용자 ID), _SYSTEMD_UNIT(systemd 유닛)과 같은 필드에 주목하세요. 이러한 필드는 더 정밀한 필터링에 사용할 수 있습니다.
예를 들어, 알려진 PID를 가진 특정 sshd 프로세스의 항목을 찾으려면(이전 journalctl -u sshd.service 출력에서 PID를 얻을 수 있음):
journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>
<PID_NUMBER>를 sshd 항목에서 관찰한 실제 PID로 바꿉니다. 예를 들어 sshd[1433]을 보았다면 _PID=1433을 사용합니다.
journalctl _SYSTEMD_UNIT=sshd.service _PID=1433
이 명령어는 여러 필터를 결합하여 저널 검색 범위를 좁히는 방법을 보여줍니다.
영구적인 시스템 저널 저장소 구성
이 단계에서는 재부팅 후에도 시스템 저널이 유지되도록 구성하는 방법을 배웁니다. 기본적으로 Red Hat Enterprise Linux 9는 시스템 저널을 임시 파일 시스템인 /run/log 디렉터리에 저장합니다. 즉, 시스템을 재부팅하면 모든 저널 항목이 지워집니다. 기록 로그 데이터를 보존하려면 영구 저장을 위해 systemd-journald 서비스를 구성해야 합니다.
systemd-journald 구성은 /etc/systemd/journald.conf 파일에 있습니다. 이 파일 내의 Storage 매개변수는 저널이 휘발성 방식으로 저장되는지 아니면 영구적으로 저장되는지를 결정합니다.
Storage 매개변수는 다음 값 중 하나로 설정할 수 있습니다.
persistent: 재부팅 후에도 유지되는/var/log/journal디렉터리에 저널을 저장합니다. 이 디렉터리가 없으면systemd-journald가 생성합니다.volatile: 임시/run/log/journal디렉터리에 저널을 저장합니다./run의 데이터는 재부팅 후에도 유지되지 않습니다.Storage가 명시적으로 설정되지 않고/var/log/journal이 존재하지 않는 경우의 기본 동작입니다.auto:/var/log/journal디렉터리가 존재하면systemd-journald는 영구 저장소를 사용하고, 그렇지 않으면 휘발성 저장소를 사용합니다.Storage매개변수를 설정하지 않을 경우의 기본값입니다.none: 저장소를 사용하지 않습니다. 모든 로그는 삭제되지만 전달은 가능합니다.
/etc/systemd/journald.conf 파일을 수정하여 영구 저널 저장을 활성화해 보겠습니다. sudo nano를 사용하여 이 파일을 편집합니다.
sudo nano /etc/systemd/journald.conf
nano 편집기 내에서 [Journal] 섹션을 찾습니다. Storage 줄의 주석을 해제하고(앞의 # 제거) 값을 persistent로 설정합니다.
파일은 다음과 비슷해야 합니다(관련 줄만 표시).
[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#Audit=no
#FlushIntervalSec=
#SyncIntervalSec=
#ReadKMsg=yes
#Audit=yes
변경 후 Ctrl+X를 누르고 Y를 눌러 저장 확인, Enter를 눌러 파일 이름을 확인하여 파일을 저장합니다.
변경 사항을 적용하려면 systemd-journald 서비스를 다시 시작해야 합니다. 이 환경은 Docker 컨테이너이므로 systemctl을 사용할 수 없습니다. 대신 비컨테이너 환경에서 서비스가 다시 시작될 때 수행할 작업인 /var/log/journal 디렉터리가 생성되고 올바른 권한을 갖도록 하여 서비스 재시작 효과를 시뮬레이션합니다.
먼저 디렉터리가 없으면 생성하고 적절한 권한을 설정합니다.
sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal
이제 영구 저장소가 구성되고 활성화되었는지 확인하려면 /var/log/journal 디렉터리에 16진수 이름의 하위 디렉터리와 .journal 파일이 포함되어 있는지 확인하면 됩니다. 이 파일들은 구조화되고 인덱싱된 저널 항목을 저장합니다.
ls -l /var/log/journal
긴 16진수 이름(예: 4ec03abd2f7b40118b1b357f479b3112)의 하위 디렉터리가 표시되어야 합니다. 이 디렉터리 안에서 .journal 파일을 찾을 수 있습니다.
ls -l /var/log/journal/ <YOUR_HEX_ID> /
<YOUR_HEX_ID>를 이전 ls 명령어 출력에서 찾은 실제 16진수 ID로 바꿉니다. 예를 들어:
ls -l /var/log/journal/4ec03abd2f7b40118b1b357f479b3112/
system.journal 및 아마도 user-1000.journal과 같은 파일이 표시되어야 합니다.
영구 저널을 사용하더라도 시스템은 모든 데이터를 영원히 보관하지 않습니다. 저널에는 내장된 로그 회전 메커니즘이 있습니다. /etc/systemd/journald.conf 파일에서 SystemMaxUse, SystemKeepFree, SystemMaxFileSize, MaxRetentionSec와 같은 매개변수를 사용하여 크기 제한 및 보존 기간을 구성할 수 있습니다.
마지막으로 영구 저널이 활성화되면 journalctl 출력에 현재 시스템 부팅 항목과 이전 시스템 부팅 항목이 포함됩니다. 출력을 특정 시스템 부팅으로 제한하려면 journalctl -b 옵션을 사용하세요.
인식된 모든 시스템 부팅 이벤트를 나열하려면:
journalctl --list-boots
부팅 ID와 해당 시간 범위 목록이 표시됩니다. 현재 부팅은 보통 0입니다. 이전 부팅은 음수(-1, -2 등)입니다.
현재 시스템 부팅 항목만 보려면:
journalctl -b
이전 부팅(예: 현재 부팅 이전, 보통 -1)의 항목을 보려면:
journalctl -b -1
이것으로 영구 저널 저장소 구성을 마칩니다.
timedatectl 및 chronyd를 사용한 정확한 시스템 시간 유지
이 단계에서는 timedatectl 명령어를 사용하여 정확한 시스템 시간을 유지하는 방법을 배우고 chronyd 서비스의 역할을 이해합니다. 정확한 시간 유지는 로깅, 보안 및 많은 네트워크 서비스에 매우 중요합니다.
1. timedatectl을 사용하여 시스템 시간 및 시간대 관리:
timedatectl 명령어는 현지 시간, 세계 표준시(UTC), RTC 시간, 시간대 및 NTP 동기화 상태를 포함하여 현재 시간 관련 시스템 설정에 대한 개요를 제공합니다.
시스템의 현재 시간 설정을 확인해 보겠습니다.
timedatectl
다음과 비슷한 출력이 표시되어야 합니다(정확한 시간과 날짜는 현재 시스템 시간을 반영함).
Local time: Sun 2025-06-15 21:46:11 EDT
Universal time: Mon 2025-06-16 01:46:11 UTC
RTC time: Mon 2025-06-16 01:46:10
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
list-timezones 옵션을 사용하여 사용 가능한 모든 시간대를 나열할 수 있습니다.
timedatectl list-timezones | less
q를 눌러 less를 종료합니다. 시간대는 IANA(Internet Assigned Numbers Authority) 시간대 데이터베이스를 기반으로 명명되며, 일반적으로 대륙/해양 다음으로 가장 큰 도시 이름으로 지정됩니다.
시스템의 시간대를 변경하려면 set-timezone 옵션을 사용합니다. 예를 들어 시간대를 America/Phoenix로 변경해 보겠습니다. 이를 위해서는 sudo 권한이 필요합니다.
sudo timedatectl set-timezone America/Phoenix
이제 변경 사항을 확인합니다.
timedatectl
시간대가 America/Phoenix로 업데이트된 것을 볼 수 있습니다.
시스템 시간을 수동으로 변경하기 전에 NTP 동기화를 일시적으로 비활성화해야 합니다. set-ntp 옵션은 자동 시간 조정을 위한 NTP 동기화를 활성화하거나 비활성화합니다. 인수로 true 또는 false를 취합니다. 잠시 NTP 동기화를 비활성화해 보겠습니다(나중에 다시 활성화할 것입니다).
sudo timedatectl set-ntp false
NTP 서비스 상태를 확인합니다.
timedatectl
NTP service: inactive가 표시되어야 합니다.
이제 set-time 옵션을 사용하여 시스템의 현재 시간을 수동으로 설정할 수 있습니다. 형식은 "YYYY-MM-DD hh:mm:ss"이지만 날짜나 시간은 생략할 수 있습니다. 시간을 09:00:00(현재 날짜 기준)으로 설정해 보겠습니다.
sudo timedatectl set-time 09:00:00
시간 변경을 확인합니다.
timedatectl
2. chronyd 서비스 이해 및 구성:
chronyd 서비스는 NTP(Network Time Protocol) 서버와 동기화하여 시스템의 RTC(Real-Time Clock)를 정확하게 유지하는 데몬입니다. Red Hat Enterprise Linux의 기본 NTP 클라이언트입니다.
chronyd의 구성 파일은 /etc/chrony.conf입니다. 기본적으로 공용 NTP 서버를 사용합니다. 실제 시나리오에서는 내부 NTP 서버를 사용하도록 구성할 수 있습니다.
기본 chrony.conf 파일을 확인해 보겠습니다.
cat /etc/chrony.conf
NTP 소스를 정의하는 server 또는 pool로 시작하는 줄이 표시됩니다. 더 정확한 초기 동기화를 위해 4번의 측정을 빠르게 수행하는 iburst 옵션이 권장됩니다.
NTP 시간 소스의 stratum은 품질을 나타냅니다. stratum 0은 참조 클록이고, stratum 1은 참조 클록에 직접 연결되며, stratum 2는 stratum 1 서버에서 동기화됩니다.
이 컨테이너 환경에서는 systemctl을 사용할 수 없으므로 구성 변경 사항을 적용하기 위해 chronyd를 직접 다시 시작할 수 없습니다. 그러나 파일을 수정하여 구성 변경을 시뮬레이션할 수 있습니다.
timedatectl을 사용하여 NTP 동기화를 다시 활성화해 보겠습니다.
sudo timedatectl set-ntp true
NTP 서비스 상태를 다시 확인합니다.
timedatectl
NTP service: active가 표시되어야 합니다.
chronyc 명령어는 chronyd 서비스의 클라이언트 역할을 합니다. 이를 사용하여 동기화 상태를 모니터링할 수 있습니다. chronyc sources 명령어는 현재 시간 소스와 동기화 상태를 보여줍니다.
chronyc sources -v
출력에는 NTP 소스에 대한 세부 정보가 표시됩니다. S(소스 상태) 필드의 별표 *는 chronyd가 현재 동기화 중인 소스를 나타냅니다.
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current best, '+' = combined, '-' = not combined,
| / 'x' = may be in error, '~' = too variable, '?' = unusable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 100.100.61.88 1 5 377 16 +1824us[+2180us] +/- 85ms
...output omitted...
이 출력은 시스템이 NTP 서버와 시간을 활발하게 동기화하고 있음을 확인해 줍니다.
요약
이 실습에서는 systemd-journald와 rsyslog 간의 상호 작용에 중점을 두고 Red Hat Enterprise Linux 9의 시스템 로그 아키텍처에 대한 포괄적인 이해를 얻었습니다. systemd-journald는 구조화되고 인덱싱된 바이너리 로그를 저널에 수집 및 저장하고, rsyslog는 이러한 메시지를 처리하여 /var/log의 전통적인 로그 파일에 기록한다는 것을 배웠습니다. /var/log/messages, /var/log/secure 등과 같은 주요 로그 파일을 탐색하고 일반적인 명령어를 사용하여 syslog 파일을 검토 및 필터링하는 연습을 했습니다. 또한 사용자 지정 syslog 메시지를 수동으로 전송하는 방법도 배웠습니다.
또한 journalctl을 사용하여 시스템 저널 항목을 탐색하고 필터링하여 상세한 시스템 이벤트에 액세스하는 기능을 이해했습니다. 그런 다음 재부팅 후에도 로그 데이터가 유지되도록 영구적인 시스템 저널 저장소를 구성했습니다. 마지막으로 timedatectl과 chronyd를 사용하여 정확한 시스템 시간을 유지하는 방법을 다루었으며, 이는 정확한 로그 타임스탬프와 전반적인 시스템 무결성에 중요함을 확인했습니다. 이 실습은 강력한 로그 관리를 통해 효과적인 시스템 분석 및 문제 해결을 위한 필수 기술을 제공했습니다.
