Journalctl을 사용하여 시스템 로그를 보고 조작하는 방법

소개

systemd의 가장 강력한 장점 중 일부는 프로세스 및 시스템 로깅과 관련된 것입니다. 다른 도구를 사용하는 경우 로그는 일반적으로 시스템 전체에 분산되고 다른 데몬과 프로세스에서 처리되며 여러 애플리케이션에 걸쳐 있을 때 해석하기가 상당히 어려울 수 있습니다. systemd는 모든 커널 및 사용자 영역 프로세스를 기록하기 위한 중앙 집중식 관리 솔루션을 제공하여 이러한 문제를 해결하려고 시도합니다. 이러한 로그를 수집하고 관리하는 시스템을 저널이라고 합니다.

저널은 커널, initrd, 서비스 등에 의해 생성된 모든 메시지를 처리하는 journald 데몬으로 구현됩니다. 이 가이드에서는 journalctl 데몬을 사용하는 방법에 대해 설명합니다. 유틸리티는 저널 내에 보관된 데이터에 액세스하고 조작하는 데 사용할 수 있습니다.

일반적인 생각

systemd 저널의 원동력 중 하나는 메시지의 출처에 관계없이 로그 관리를 중앙 집중화하는 것입니다. 많은 부팅 프로세스와 서비스 관리가 systemd 프로세스에 의해 처리되기 때문에 로그 수집 및 액세스 방식을 표준화하는 것이 좋습니다. journald 데몬은 사용 가능한 모든 소스에서 데이터를 수집하고 쉽고 동적인 조작을 위해 바이너리 형식으로 저장합니다.

이것은 우리에게 많은 중요한 이점을 제공합니다. 단일 유틸리티를 사용하여 데이터와 상호 작용함으로써 관리자는 필요에 따라 로그 데이터를 동적으로 표시할 수 있습니다. 이는 세 번의 부팅 전 부팅 데이터를 보거나 두 관련 서비스의 로그 항목을 순차적으로 결합하여 통신 문제를 디버깅하는 것처럼 간단할 수 있습니다.

로그 데이터를 바이너리 형식으로 저장한다는 것은 데이터가 현재 필요한 것에 따라 임의의 출력 형식으로 표시될 수 있음을 의미합니다. 예를 들어 일일 로그 관리의 경우 표준 syslog 형식으로 로그를 보는 데 익숙할 수 있지만 나중에 서비스 중단을 그래프로 표시하기로 결정한 경우 각 항목을 JSON 개체로 출력하여 만들 수 있습니다. 그래프 서비스에 사용할 수 있습니다. 데이터가 일반 텍스트로 디스크에 기록되지 않기 때문에 다른 주문형 형식이 필요할 때 변환이 필요하지 않습니다.

systemd 저널은 기존 syslog 구현과 함께 사용하거나 필요에 따라 syslog 기능을 대체할 수 있습니다. systemd 저널은 대부분의 관리자 로깅 요구 사항을 처리하지만 기존 로깅 메커니즘을 보완할 수도 있습니다. 예를 들어, 여러 서버의 데이터를 컴파일하는 데 사용하는 중앙 집중식 syslog 서버가 있을 수 있지만 systemd 저널. 이러한 기술을 결합하여 이 두 가지를 모두 수행할 수 있습니다.

시스템 시간 설정

로깅에 이진 저널을 사용하는 이점 중 하나는 원하는 대로 UTC 또는 현지 시간으로 로그 레코드를 볼 수 있다는 것입니다. 기본적으로 systemd는 현지 시간으로 결과를 표시합니다.

이 때문에 저널을 시작하기 전에 시간대가 올바르게 설정되었는지 확인합니다. systemd 제품군에는 실제로 이를 도울 수 있는 timedatectl이라는 도구가 함께 제공됩니다.

먼저 list-timezones 옵션으로 사용할 수 있는 시간대를 확인합니다.

timedatectl list-timezones

그러면 시스템에서 사용 가능한 시간대가 나열됩니다. 서버 위치와 일치하는 것을 찾으면 set-timezone 옵션을 사용하여 설정할 수 있습니다.

sudo timedatectl set-timezone zone

시스템이 현재 정확한 시간을 사용하고 있는지 확인하려면 timedatectl 명령만 사용하거나 status 옵션과 함께 사용하십시오. 디스플레이는 동일합니다.

timedatectl status

Output               Local time: Fri 2021-07-09 14:44:30 EDT
           Universal time: Fri 2021-07-09 18:44:30 UTC
                 RTC time: Fri 2021-07-09 18:44:31
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

첫 번째 줄에는 정확한 시간이 표시되어야 합니다.

기본 로그 보기

journald 데몬이 수집한 로그를 보려면 journalctl 명령을 사용하십시오.

단독으로 사용할 경우 시스템에 있는 모든 저널 항목은 호출기(일반적으로 less) 내에 표시되어 찾아볼 수 있습니다. 가장 오래된 항목이 맨 위에 표시됩니다.

journalctl

Output-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

스크롤할 데이터 페이지가 있을 수 있으며 systemd가 오랫동안 시스템에 있었다면 수만 또는 수십만 줄이 될 수 있습니다. 이것은 저널 데이터베이스에서 얼마나 많은 데이터를 사용할 수 있는지 보여줍니다.

형식은 표준 syslog 로깅에 익숙한 사람들에게 익숙할 것입니다. 그러나 이것은 실제로 기존 syslog 구현이 할 수 있는 것보다 더 많은 소스에서 데이터를 수집합니다. 여기에는 초기 부팅 프로세스, 커널, initrd 및 응용 프로그램 표준 오류 및 출력의 로그가 포함됩니다. 이것들은 저널에서 모두 사용할 수 있습니다.

표시되는 모든 타임스탬프가 현지 시간임을 알 수 있습니다. 시스템에 현지 시간이 올바르게 설정되었으므로 이제 모든 로그 항목에 사용할 수 있습니다. 모든 로그는 이 새로운 정보를 사용하여 표시됩니다.

타임스탬프를 UTC로 표시하려면 --utc 플래그를 사용할 수 있습니다.

journalctl --utc

시간별 저널 필터링

이렇게 많은 양의 데이터에 액세스할 수 있다는 것은 분명 유용하지만, 이렇게 많은 양의 정보를 수동으로 검사하고 처리하는 것이 어렵거나 불가능할 수 있습니다. 이 때문에 journalctl의 가장 중요한 기능 중 하나는 필터링 옵션입니다.

현재 부팅에서 로그 표시

매일 사용할 수 있는 가장 기본적인 플래그는 -b 플래그입니다. 가장 최근 재부팅 이후 수집된 모든 저널 항목이 표시됩니다.

journalctl -b

이렇게 하면 현재 환경과 관련된 정보를 식별하고 관리하는 데 도움이 됩니다.

이 기능을 사용하지 않고 하루 이상의 부팅을 표시하는 경우 journalctl이 시스템이 다운될 때마다 다음과 같은 줄을 삽입한 것을 볼 수 있습니다.

Output. . .

-- Reboot --

. . .

정보를 부팅 세션으로 논리적으로 분리하는 데 도움이 될 수 있습니다.

과거 부츠

일반적으로 현재 부팅의 정보를 표시하고 싶지만 과거 부팅도 도움이 되는 경우가 분명히 있습니다. 저널은 많은 이전 부츠의 정보를 저장할 수 있으므로 정보를 쉽게 표시하도록 journalctl을 만들 수 있습니다.

일부 배포판은 기본적으로 이전 부팅 정보 저장을 활성화하고 다른 배포판은 이 기능을 비활성화합니다. 영구 부팅 정보를 활성화하려면 다음을 입력하여 저널을 저장할 디렉터리를 만들 수 있습니다.

sudo mkdir -p /var/log/journal

또는 저널 구성 파일을 편집할 수 있습니다.

sudo nano /etc/systemd/journald.conf

[Journal] 섹션에서 Storage= 옵션을 "persistent\로 설정하여 영구 로깅을 활성화합니다.

. . .
[Journal]
Storage=persistent

서버에서 이전 부츠 저장이 활성화된 경우 journalctl은 부츠를 분할 단위로 작업하는 데 도움이 되는 몇 가지 명령을 제공합니다. journald가 알고 있는 부츠를 보려면 journalctl과 함께 --list-boots 옵션을 사용하십시오.

journalctl --list-boots

Output-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

그러면 각 부팅에 대한 줄이 표시됩니다. 첫 번째 열은 journalctl로 부팅을 쉽게 참조하는 데 사용할 수 있는 부팅 오프셋입니다. 절대 참조가 필요한 경우 부팅 ID는 두 번째 열에 있습니다. 끝에 나열된 두 개의 시간 사양으로 부팅 세션이 참조하는 시간을 알 수 있습니다.

이러한 부츠의 정보를 표시하려면 첫 번째 또는 두 번째 열의 정보를 사용할 수 있습니다.

예를 들어, 이전 부팅에서 저널을 보려면 -b 플래그와 함께 -1 상대 포인터를 사용하십시오.

journalctl -b -1

부팅 ID를 사용하여 부팅에서 데이터를 콜백할 수도 있습니다.

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

시간 창

부팅별로 로그 항목을 보는 것은 매우 유용하지만 시스템 부팅과 잘 맞지 않는 시간 창을 요청하는 경우가 종종 있습니다. 가동 시간이 긴 장기 실행 서버를 처리할 때 특히 그렇습니다.

--since 및 --until 옵션을 사용하여 임의의 시간 제한으로 필터링할 수 있습니다. 이 옵션은 각각 지정된 시간 이후 또는 이전 항목으로 표시되는 항목을 제한합니다.

시간 값은 다양한 형식으로 올 수 있습니다. 절대 시간 값의 경우 다음 형식을 사용해야 합니다.

YYYY-MM-DD HH:MM:SS

예를 들어 다음을 입력하면 2015년 1월 10일 오후 5:15 이후의 모든 항목을 볼 수 있습니다.

journalctl --since "2015-01-10 17:15:00"

위 형식의 구성 요소를 생략하면 일부 기본값이 적용됩니다. 예를 들어 날짜를 생략하면 현재 날짜로 간주됩니다. 시간 구성 요소가 누락된 경우 "00:00:00\(자정)으로 대체됩니다. 초 필드는 생략할 수 있으며 기본값은 "00\입니다.

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

저널은 또한 일부 상대 값과 명명된 바로 가기를 이해합니다. 예를 들어 "어제\, "오늘\, "내일\ 또는 "지금\이라는 단어를 사용할 수 있습니다. 숫자 값 앞에 "-\ 또는 "+\를 추가하거나 문장 구성에서 "ago\와 같은 단어를 사용하여 상대 시간을 계산할 수 있습니다.

어제의 데이터를 가져오려면 다음을 입력할 수 있습니다.

journalctl --since yesterday

오전 9시에 시작하여 한 시간 전까지 계속된 서비스 중단 보고를 받은 경우 다음을 입력할 수 있습니다.

journalctl --since 09:00 --until "1 hour ago"

보시다시피 보려는 항목을 필터링하기 위해 유연한 시간 창을 정의하는 것은 비교적 간단합니다.

메시지 관심도를 기준으로 필터링

위에서 시간 제한을 사용하여 저널 데이터를 필터링할 수 있는 몇 가지 방법을 배웠습니다. 이 섹션에서는 관심 있는 서비스 또는 구성 요소를 기반으로 필터링하는 방법에 대해 설명합니다. systemd 저널은 이를 수행하는 다양한 방법을 제공합니다.

단위별

아마도 가장 유용한 필터링 방법은 관심 있는 단위별로 필터링하는 것입니다. -u 옵션을 사용하여 이러한 방식으로 필터링할 수 있습니다.

예를 들어 시스템에 있는 Nginx 장치의 모든 로그를 보려면 다음을 입력할 수 있습니다.

journalctl -u nginx.service

일반적으로 관심 있는 회선을 표시하기 위해 시간별로 필터링할 수도 있습니다. 예를 들어, 오늘 서비스가 어떻게 실행되고 있는지 확인하려면 다음을 입력할 수 있습니다.

journalctl -u nginx.service --since today

이러한 유형의 초점은 다양한 단위의 레코드를 인터리브하는 저널의 기능을 활용할 때 매우 유용합니다. 예를 들어 Nginx 프로세스가 PHP-FPM 장치에 연결되어 동적 콘텐츠를 처리하는 경우 두 장치를 모두 지정하여 시간순으로 항목을 병합할 수 있습니다.

journalctl -u nginx.service -u php-fpm.service --since today

이렇게 하면 개별 프로세스 대신 서로 다른 프로그램과 디버그 시스템 간의 상호 작용을 훨씬 쉽게 찾을 수 있습니다.

프로세스, 사용자 또는 그룹 ID별

일부 서비스는 작업을 수행하기 위해 다양한 하위 프로세스를 생성합니다. 관심 있는 프로세스의 정확한 PID를 찾아냈다면 이를 기준으로 필터링할 수도 있습니다.

이를 위해 _PID 필드를 지정하여 필터링할 수 있습니다. 예를 들어 관심 있는 PID가 8088인 경우 다음을 입력할 수 있습니다.

journalctl _PID=8088

다른 경우에는 특정 사용자 또는 그룹에서 기록된 모든 항목을 표시하고자 할 수 있습니다. 이는 _UID 또는 _GID 필터를 사용하여 수행할 수 있습니다. 예를 들어 웹 서버가 www-data 사용자로 실행되는 경우 다음을 입력하여 사용자 ID를 찾을 수 있습니다.

id -u www-data

Output33

그런 다음 반환된 ID를 사용하여 저널 결과를 필터링할 수 있습니다.

journalctl _UID=33 --since today

systemd 저널에는 필터링에 사용할 수 있는 많은 필드가 있습니다. 그 중 일부는 기록되는 프로세스에서 전달되고 일부는 기록 시 시스템에서 수집한 정보를 사용하여 journald에 의해 적용됩니다.

선행 밑줄은 _PID 필드가 후자 유형임을 나타냅니다. 저널은 나중에 필터링하기 위해 로깅하는 프로세스의 PID를 자동으로 기록하고 인덱싱합니다. 다음을 입력하여 사용 가능한 모든 저널 필드에 대해 알아볼 수 있습니다.

man systemd.journal-fields

이 가이드에서 이들 중 일부에 대해 논의할 것입니다. 하지만 지금은 이러한 필드를 기준으로 필터링하는 것과 관련된 유용한 옵션을 하나 더 살펴보겠습니다. -F 옵션을 사용하여 주어진 저널 필드에 사용 가능한 모든 값을 표시할 수 있습니다.

예를 들어 systemd 저널에 항목이 있는 그룹 ID를 보려면 다음을 입력할 수 있습니다.

journalctl -F _GID

이렇게 하면 저널이 그룹 ID 필드에 대해 저장한 모든 값이 표시됩니다. 이렇게 하면 필터를 구성하는 데 도움이 될 수 있습니다.

구성 요소 경로별

경로 위치를 제공하여 필터링할 수도 있습니다.

경로가 실행 파일로 이어지는 경우 journalctl은 해당 실행 파일과 관련된 모든 항목을 표시합니다. 예를 들어 bash 실행 파일과 관련된 항목을 찾으려면 다음을 입력하면 됩니다.

journalctl /usr/bin/bash

일반적으로 실행 파일에 대해 단위를 사용할 수 있는 경우 해당 방법이 더 깨끗하고 더 나은 정보(연결된 하위 프로세스의 항목 등)를 제공합니다. 그러나 때로는 이것이 불가능합니다.

커널 메시지 표시

일반적으로 dmesg 출력에서 발견되는 커널 메시지는 저널에서도 검색할 수 있습니다.

이러한 메시지만 표시하려면 명령에 -k 또는 --dmesg 플래그를 추가할 수 있습니다.

journalctl -k

기본적으로 현재 부팅의 커널 메시지가 표시됩니다. 앞에서 설명한 일반 부팅 선택 플래그를 사용하여 대체 부팅을 지정할 수 있습니다. 예를 들어, 5번의 부팅 전에 메시지를 받으려면 다음을 입력할 수 있습니다.

journalctl -k -b -5

우선 순위

시스템 관리자가 자주 관심을 갖는 한 가지 필터는 메시지 우선 순위입니다. 매우 장황한 수준에서 정보를 기록하는 것이 유용한 경우가 많지만 실제로 사용 가능한 정보를 요약할 때 우선 순위가 낮은 로그는 산만하고 혼란스러울 수 있습니다.

journalctl을 사용하여 -p 옵션을 사용하여 지정된 우선 순위 이상의 메시지만 표시할 수 있습니다. 이를 통해 우선 순위가 낮은 메시지를 필터링할 수 있습니다.

예를 들어 오류 수준 이상에서 기록된 항목만 표시하려면 다음을 입력합니다.

journalctl -p err -b

이렇게 하면 오류, 위험, 경고 또는 긴급으로 표시된 모든 메시지가 표시됩니다. 저널은 표준 syslog 메시지 수준을 구현합니다. 우선 순위 이름 또는 해당 숫자 값을 사용할 수 있습니다. 가장 높은 우선 순위에서 가장 낮은 우선 순위는 다음과 같습니다.

0: 비상
1: 경고
2: 크리티컬
3: 오류
4: 경고
5: 알림
6: 정보
7: 디버그

위의 숫자 또는 이름은 -p 옵션과 상호 교환하여 사용할 수 있습니다. 우선 순위를 선택하면 지정된 수준과 그 위에 표시된 메시지가 표시됩니다.

분개 표시 수정

위에서 필터링을 통한 항목 선택을 시연했습니다. 하지만 출력을 수정할 수 있는 다른 방법이 있습니다. 다양한 요구에 맞게 journalctl 표시를 조정할 수 있습니다.

출력 자르기 또는 확장

journalctl이 출력을 축소하거나 확장하도록 지시하여 데이터를 표시하는 방식을 조정할 수 있습니다.

기본적으로 journalctl은 호출기에 전체 항목을 표시하여 항목이 화면 오른쪽으로 이동하도록 합니다. 이 정보는 오른쪽 화살표 키를 눌러 액세스할 수 있습니다.

정보가 제거된 곳에 줄임표를 삽입하여 출력을 자르려면 --no-full 옵션을 사용할 수 있습니다.

journalctl --no-full

Output. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

이와 반대 방향으로 이동하여 journalctl에 인쇄할 수 없는 문자가 포함되어 있는지 여부에 관계없이 모든 정보를 표시하도록 지시할 수도 있습니다. -a 플래그를 사용하여 이를 수행할 수 있습니다.

journalctl -a

표준 출력으로 출력

기본적으로 journalctl은 쉽게 사용할 수 있도록 호출기에 출력을 표시합니다. 그러나 텍스트 조작 도구로 데이터를 처리할 계획이라면 표준 출력으로 출력할 수 있기를 원할 것입니다.

--no-pager 옵션을 사용하여 이 작업을 수행할 수 있습니다.

journalctl --no-pager

이것은 필요에 따라 처리 유틸리티로 즉시 연결되거나 디스크의 파일로 리디렉션될 수 있습니다.

출력 형식

위에서 언급한 바와 같이 저널 항목을 처리하는 경우 데이터가 보다 소비 가능한 형식인 경우 데이터 구문 분석이 더 쉬울 것입니다. 다행히 저널은 필요에 따라 다양한 형식으로 표시할 수 있습니다. 형식 지정자와 함께 -o 옵션을 사용하여 이 작업을 수행할 수 있습니다.

예를 들어 다음을 입력하여 저널 항목을 JSON으로 출력할 수 있습니다.

journalctl -b -u nginx -o json

Output{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

이는 유틸리티로 구문 분석하는 데 유용합니다. 데이터 구조를 JSON 소비자에게 전달하기 전에 json-pretty 형식을 사용하여 데이터 구조를 더 잘 처리할 수 있습니다.

journalctl -b -u nginx -o json-pretty

Output{
	"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
	"__REALTIME_TIMESTAMP" : "1422990364739502",
	"__MONOTONIC_TIMESTAMP" : "27200938",
	"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
	"PRIORITY" : "6",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
	"_HOSTNAME" : "desktop",
	"SYSLOG_FACILITY" : "3",
	"CODE_FILE" : "src/core/unit.c",
	"CODE_LINE" : "1402",
	"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
	"SYSLOG_IDENTIFIER" : "systemd",
	"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
	"_TRANSPORT" : "journal",
	"_PID" : "1",
	"_COMM" : "systemd",
	"_EXE" : "/usr/lib/systemd/systemd",
	"_CMDLINE" : "/usr/lib/systemd/systemd",
	"_SYSTEMD_CGROUP" : "/",
	"UNIT" : "nginx.service",
	"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
	"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

다음 형식을 표시에 사용할 수 있습니다.

cat: 메시지 필드 자체만 표시합니다.
내보내기: 전송 또는 백업에 적합한 바이너리 형식입니다.
json: 한 줄에 하나의 항목이 있는 표준 JSON
json-pretty: 사람이 더 쉽게 읽을 수 있도록 형식이 지정된 JSON
json-sse: 추가 서버 전송 이벤트가 호환되도록 래핑된 JSON 형식의 출력
짧은: 기본 syslog 스타일 출력
short-iso: ISO 8601 wallclock 타임스탬프를 표시하도록 확장된 기본 형식입니다.
short-monotonic: 단조로운 타임스탬프가 있는 기본 형식입니다.
짧은 정밀도: 마이크로초 정밀도의 기본 형식
verbose: 일반적으로 내부적으로 숨겨진 항목을 포함하여 항목에 사용할 수 있는 모든 저널 필드를 표시합니다.

이러한 옵션을 사용하면 현재 요구 사항에 가장 적합한 형식으로 저널 항목을 표시할 수 있습니다.

활성 프로세스 모니터링

journalctl 명령은 활성 또는 최근 활동을 모니터링하기 위해 얼마나 많은 관리자가 tail을 사용하는지 모방합니다. 이 기능은 journalctl에 내장되어 있으므로 다른 도구로 연결하지 않고도 이러한 기능에 액세스할 수 있습니다.

최근 로그 표시

정해진 양의 레코드를 표시하려면 tail -n과 똑같이 작동하는 -n 옵션을 사용할 수 있습니다.

기본적으로 가장 최근 10개 항목이 표시됩니다.

journalctl -n

-n 다음에 숫자를 사용하여 보고 싶은 항목 수를 지정할 수 있습니다.

journalctl -n 20

다음 로그

기록되는 로그를 능동적으로 따르려면 -f 플래그를 사용할 수 있습니다. 다시 말하지만, 이것은 tail -f를 사용해 본 경험이 있는 경우 예상할 수 있는 대로 작동합니다.

journalctl -f

이 명령을 종료하려면 CTRL+C를 입력하십시오.

저널 유지 관리

지금까지 본 모든 데이터를 저장하는 데 드는 비용이 궁금할 수 있습니다. 또한 일부 오래된 로그를 정리하고 공간을 확보하는 데 관심이 있을 수 있습니다.

현재 디스크 사용량 찾기

--disk-usage 플래그를 사용하여 저널이 디스크에서 현재 차지하는 공간을 확인할 수 있습니다.

journalctl --disk-usage

OutputArchived and active journals take up 8.0M in the file system.

오래된 로그 삭제

저널을 축소하려면 두 가지 방법으로 수행할 수 있습니다(systemd 버전 218 이상에서 사용 가능).

--vacuum-size 옵션을 사용하면 크기를 표시하여 저널을 축소할 수 있습니다. 이렇게 하면 디스크에서 차지하는 총 저널 공간이 요청된 크기가 될 때까지 이전 항목이 제거됩니다.

sudo journalctl --vacuum-size=1G

저널을 축소할 수 있는 또 다른 방법은 --vacuum-time 옵션으로 마감 시간을 제공하는 것입니다. 해당 시간 이후의 모든 항목은 삭제됩니다. 이렇게 하면 특정 시간 이후에 생성된 항목을 유지할 수 있습니다.

예를 들어 작년 항목을 유지하려면 다음을 입력할 수 있습니다.

sudo journalctl --vacuum-time=1years

저널 확장 제한

저널이 차지하는 공간을 제한하도록 서버를 구성할 수 있습니다. /etc/systemd/journald.conf 파일을 편집하면 됩니다.

다음 항목을 사용하여 저널 증가를 제한할 수 있습니다.

SystemMaxUse=: 영구 저장소에서 저널이 사용할 수 있는 최대 디스크 공간을 지정합니다.
SystemKeepFree=: 저널 항목을 영구 저장소에 추가할 때 저널이 비워두어야 하는 공간의 양을 지정합니다.
SystemMaxFileSize=: 개별 저널 파일이 순환되기 전에 영구 저장소에서 증가할 수 있는 크기를 제어합니다.
RuntimeMaxUse=: 휘발성 저장소(/run 파일 시스템 내)에서 사용할 수 있는 최대 디스크 공간을 지정합니다.
RuntimeKeepFree=: 휘발성 저장소(/run 파일 시스템 내)에 데이터를 쓸 때 다른 용도로 사용할 공간을 지정합니다.
RuntimeMaxFileSize=: 개별 저널 파일이 회전되기 전에 휘발성 저장소(/run 파일 시스템 내)에서 차지할 수 있는 공간의 양을 지정합니다.

이러한 값을 설정하여 journald가 서버의 공간을 사용하고 보존하는 방법을 제어할 수 있습니다. SystemMaxFileSize 및 RuntimeMaxFileSize는 명시된 제한에 도달하기 위해 아카이브된 파일을 대상으로 한다는 점에 유의하십시오. 데이터 제거 작업 후 파일 수를 해석할 때 기억해야 할 중요한 사항입니다.

결론

보시다시피 systemd 저널은 시스템 및 애플리케이션 데이터를 수집하고 관리하는 데 매우 유용합니다. 대부분의 유연성은 자동으로 기록되는 광범위한 메타데이터와 로그의 중앙 집중식 특성에서 비롯됩니다. journalctl 명령을 사용하면 저널의 고급 기능을 쉽게 활용하고 다양한 애플리케이션 구성 요소의 광범위한 분석 및 관계형 디버깅을 수행할 수 있습니다.