Red Hat Enterprise Linux 에서 로그 분석하기

소개

이 랩에서는 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의 대부분의 로그 파일은 읽으려면 root 권한이 필요하므로 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 시설 (Syslog Facilities): 이는 로그 메시지의 소스를 나타냅니다. 예시로는 kern (커널 메시지), user (사용자 수준 메시지), mail (메일 시스템 메시지), daemon (시스템 데몬 메시지), auth (인증 및 보안 메시지), cron (시계 데몬 메시지) 등이 있습니다.

Syslog 우선순위 (Syslog Priorities): 이는 메시지의 심각도를 정의하며, emerg (시스템 사용 불가) 에서 debug (디버깅 수준 메시지) 까지 다양합니다. 심각도의 순서는 가장 높은 것부터 가장 낮은 것 순으로 emerg, alert, crit, err, warning, notice, info, debug입니다.

로그 파일은 매우 커질 수 있으므로 특정 정보를 찾는 것이 어려워질 수 있습니다. 따라서 필터링이 필수적입니다. grep, awk, sed와 같은 명령어를 사용하여 로그 파일 내용을 필터링할 수 있습니다.

less를 사용하여 /var/log/messages의 전체 내용을 먼저 살펴보겠습니다. 이 명령어를 사용하면 파일을 스크롤할 수 있습니다. less를 종료하려면 q를 누르십시오. 로그 파일을 읽으려면 root 권한이 필요하므로 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

로그 파일 로테이션 (Log File Rotation):
로그 파일이 너무 많은 디스크 공간을 소비하는 것을 방지하기 위해 시스템은 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 우선순위 (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 메시지가 시설과 우선순위별로 분류된다는 것을 기억하십시오. 예를 들어, local7.notice는 메시지가 local7 시설과 notice 우선순위로 기록됨을 의미합니다. local7 시설은 종종 사용자 지정 애플리케이션 또는 부팅 메시지에 사용되며, 일반적으로 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

이는 시설과 우선순위를 지정하여 사용자 지정 메시지가 기록되는 위치를 제어하는 방법을 보여줍니다. 이 기능은 rsyslog 구성을 테스트하고 특정 이벤트를 시스템 로그에 삽입하는 데 매우 유용합니다.

journalctl 로 시스템 저널 항목 탐색 및 필터링

이 단계에서는 journalctl 명령어를 사용하여 시스템 저널 항목을 탐색하고 필터링하는 방법을 배우게 됩니다. 아시다시피, systemd-journald 서비스는 journal이라고 하는 구조화되고 인덱싱된 바이너리 파일에 로깅 데이터를 저장합니다. journalctl 명령어는 이 저널과 상호 작용하기 위한 주요 도구입니다.

먼저, 저널의 모든 메시지를 살펴보겠습니다. 옵션 없이 journalctl을 실행하면 가장 오래된 항목부터 시작하여 사용 가능한 모든 로그 항목이 표시됩니다. sudo 권한으로 labex로 로그인했으므로 저널에 대한 전체 액세스 권한을 갖게 됩니다.

journalctl

많은 양의 출력을 보게 됩니다. journalctl 뷰어를 종료하려면 q를 누르십시오. journalctl은 중요한 로그 메시지를 강조 표시합니다. notice 또는 warning 우선순위의 메시지는 굵은 텍스트로 표시되고, error 우선순위 이상의 메시지는 빨간색 텍스트로 표시됩니다.

이제 특정 항목을 필터링하고 보기 위한 몇 가지 일반적인 journalctl 옵션을 살펴보겠습니다.

1. 마지막 N 개의 로그 항목 보기 (-n 옵션):
기본적으로 journalctl -n은 마지막 10 개의 로그 항목을 표시합니다. 다른 숫자를 지정할 수 있습니다. 예를 들어, 마지막 5 개 항목을 표시합니다.

journalctl -n 5

가장 최근의 5 개 로그 항목을 볼 수 있습니다.

2. 새 저널 항목 따라가기 (-f 옵션):
tail -f 명령어와 유사하게, journalctl -f 옵션은 시스템 저널의 마지막 10 줄을 출력하고, 새 저널 항목이 추가될 때 계속 출력합니다. 이는 실시간 모니터링에 매우 유용합니다.

journalctl -f

이 연속 출력을 종료하려면 Ctrl+C를 누르십시오.

3. 우선순위별 필터링 (-p 옵션):
저널 항목의 우선순위 수준별로 출력을 필터링할 수 있습니다. journalctl -p 옵션은 지정된 우선순위 수준 (이름 또는 번호) 이상인 항목을 표시합니다. 우선순위 수준은 오름차순으로 debug, info, notice, warning, err, crit, alert, emerg입니다.

err 우선순위 이상의 저널 항목을 나열해 보겠습니다.

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

이제 지난 한 시간 동안의 항목을 살펴보겠습니다.

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을 사용할 수 없습니다. 대신, 컨테이너화되지 않은 환경에서 systemd-journald가 다시 시작될 때 수행하는 것처럼 /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로 업데이트된 것을 볼 수 있습니다.

set-time 옵션을 사용하여 시스템의 현재 시간을 수동으로 설정할 수도 있습니다. 형식은 "YYYY-MM-DD hh:mm:ss"이지만 날짜 또는 시간을 생략할 수 있습니다. 시간을 09:00:00으로 설정해 보겠습니다 (현재 날짜 기준).

sudo timedatectl set-time 09:00:00

시간 변경을 확인합니다.

timedatectl

마지막으로, set-ntp 옵션은 자동 시간 조정을 위해 NTP 동기화를 활성화하거나 비활성화합니다. 인수로 true 또는 false를 사용합니다. 잠시 NTP 동기화를 비활성화해 보겠습니다 (나중에 다시 활성화합니다).

sudo timedatectl set-ntp false

NTP 서비스 상태를 확인합니다.

timedatectl

NTP service: inactive가 표시됩니다.

2. chronyd 서비스 이해 및 구성:

chronyd 서비스는 시스템의 RTC(Real-Time Clock) 를 NTP(Network Time Protocol) 서버와 동기화하여 정확하게 유지하는 데몬입니다. Red Hat Enterprise Linux 의 기본 NTP 클라이언트입니다.

chronyd의 구성 파일은 /etc/chrony.conf입니다. 기본적으로 공용 NTP 서버를 사용합니다. 실제 시나리오에서는 내부 NTP 서버를 사용하도록 구성할 수 있습니다.

기본 chrony.conf 파일을 살펴보겠습니다.

cat /etc/chrony.conf

NTP 소스를 정의하는 server 또는 pool로 시작하는 줄을 볼 수 있습니다. iburst 옵션은 보다 정확한 초기 동기화를 위해 4 번의 측정을 빠르게 수행하므로 권장됩니다.

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(Source state) 필드의 별표 *는 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를 사용하여 정확한 시스템 시간을 유지하는 방법을 다루었습니다. 이 실습은 강력한 로그 관리를 통해 효과적인 시스템 분석 및 문제 해결을 위한 필수 기술을 제공했습니다.