systemd 로그 마스터하기:Linux에서 Journalctl 사용에 대한 전체 가이드

systemd Journal 및 Journalctl Logging 소개

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

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

이 글에서는 journalctl을 사용하는 방법을 배웁니다. 시스템 저널의 로그 데이터에 액세스하고 필터링하는 명령줄 도구입니다. 특정 부팅 또는 시간 범위의 로그를 보고, 시스템 장치, 사용자 또는 우선 순위 수준별로 필터링하고, 다른 도구와의 통합을 위해 JSON과 같은 형식으로 로그를 출력하는 방법을 다룹니다. 또한 실시간 이벤트를 모니터링하고, 디스크 사용량을 관리하고, 영구 로깅을 구성하고, 로그 누락이나 권한 오류와 같은 일반적인 문제를 해결하는 방법도 알아봅니다. 실패한 서비스를 디버깅하든 중앙 집중식 로그 수집을 설정하든, Journalctl은 워크플로를 간소화할 수 있는 유연성과 정확성을 제공합니다.

주요 시사점

• systemd 저널은 커널, 서비스 및 사용자 애플리케이션의 메시지를 하나의 중앙 집중식 색인 로그에 캡처하는 통합 로깅 시스템을 제공합니다.
• journalctl 명령을 사용하면 부팅 세션, 시간 범위, 시스템 단위, 프로세스 ID, 사용자 ID, 그룹 ID 등을 기준으로 로그를 필터링하여 관련 이벤트를 쉽게 찾아낼 수 있습니다.
• --since와 같은 옵션을 사용하여 특정 기간의 로그를 검색할 수 있습니다. , --until , 또는 "1 hour ago"와 같은 상대 표현식 또는 "yesterday" .
• 로그는 일반 텍스트, JSON, 상세 모드 등 다양한 형식으로 표시될 수 있어 외부 도구와 통합하거나 분석을 위해 구문 분석하기가 더 쉽습니다.
• journalctl -f 사용 , tail -f와 유사하게 기록된 로그 메시지를 실시간으로 따라갈 수 있습니다. , 시스템 활동이나 서비스 동작을 실시간으로 모니터링하는 데 유용합니다.
• 기본적으로 로그는 메모리에 저장되었다가 재부팅 시 손실될 수 있습니다. /var/log/journal을 생성하여 영구 로깅을 활성화할 수 있습니다. journald.conf 구성 따라서.
• 저널의 저장 공간은 --disk-usage와 같은 명령으로 관리할 수 있습니다. , --vacuum-size 및 --vacuum-time , 최대 크기 및 보존을 제어하는 구성 옵션도 제공됩니다.
• journalctl 부팅 및 장치 전반에 걸쳐 로그를 집계하여 서비스 디버깅을 단순화하고 오류 식별, SSH 액세스 추적, 자세한 컨텍스트를 통해 문제 조사를 더 쉽게 만듭니다.

시스템 저널의 작동 방식과 중요한 이유

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

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

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

systemd 저널은 기존 syslog와 함께 사용할 수 있습니다. 구현하거나 syslog를 대체할 수 있습니다. 필요에 따라 기능을 선택할 수 있습니다. systemd 저널은 대부분의 관리자 로깅 요구 사항을 다루며 기존 로깅 메커니즘을 보완할 수도 있습니다. 예를 들어 중앙집중화된 syslog가 있을 수 있습니다. 여러 서버의 데이터를 컴파일하는 데 사용하는 서버이지만 systemd를 사용하여 단일 시스템에 있는 여러 서비스의 로그를 인터리브할 수도 있습니다. 저널. 이러한 기술을 결합하면 이 두 가지를 모두 수행할 수 있습니다.

timedatectl로 올바른 시스템 시간을 설정하는 방법

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

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

먼저 list-timezones에서 사용 가능한 시간대를 확인하세요. 옵션:

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

현재 컴퓨터가 올바른 시간을 사용하고 있는지 확인하려면 timedatectl를 사용하세요. 명령 단독으로 또는 status를 사용하여 옵션. 표시 내용은 동일합니다:

 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

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

journalctl로 로그를 보는 방법

journald의 로그를 보려면 데몬이 수집한 경우 journalctl를 사용하세요. 명령을 내리세요.

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

-- 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를 사용하여 시간별로 시스템 로그를 필터링하는 방법

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

journalctl를 사용하여 현재 부팅 세션의 로그 표시

매일 사용할 수 있는 가장 기본적인 것은 -b입니다. 깃발. 가장 최근 재부팅 이후 수집된 모든 일지 항목이 표시됩니다.

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

이 기능을 사용하지 않고 하루 이상의 부츠를 표시하는 경우 journalctl이 표시됩니다. 시스템이 다운될 때마다 다음과 같은 줄을 삽입했습니다:

. . .
-- Reboot --
. . .

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

journalctl를 사용하여 이전 부팅에서 로그에 액세스하는 방법

일반적으로 현재 부팅의 정보를 표시하고 싶지만 과거 부팅도 도움이 될 때가 있습니다. 저널에는 이전의 여러 부팅 정보를 저장할 수 있으므로 journalctl 정보를 쉽게 표시할 수 있습니다.

일부 배포판에서는 기본적으로 이전 부팅 정보 저장을 활성화하는 반면 다른 배포판에서는 이 기능을 비활성화합니다. 지속적인 부팅 정보를 활성화하려면 다음을 입력하여 저널을 저장할 디렉터리를 생성할 수 있습니다:

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

[Journal] 아래 섹션에서 Storage=를 설정하세요. 지속적인 로깅을 활성화하려면 "영구" 옵션을 선택하세요:

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

서버에서 이전 부팅 저장이 활성화되면 journalctl 분할 단위로 부트 작업을 수행하는 데 도움이 되는 몇 가지 명령을 제공합니다. journald의 부츠를 보려면 알고 계시다면 --list-boots을 사용하세요 journalctl 옵션 :

-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는 두 번째 열에 있습니다. 부팅 세션이 참조하는 시간은 끝 부분에 나열된 두 가지 시간 지정으로 알 수 있습니다.

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

예를 들어, 이전 부팅의 저널을 보려면 -1를 사용하세요. -b를 사용한 상대 포인터 플래그:

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

맞춤 날짜 및 시간 범위를 기준으로 Journalctl 로그 필터링

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

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

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

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

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

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

어제의 데이터를 얻으려면 다음을 입력하세요:

오전 9시부터 한 시간 전까지 지속되는 서비스 중단에 대한 보고를 받은 경우 다음을 입력할 수 있습니다.

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

서비스, PID 또는 사용자별로 시스템 저널 로그를 필터링하는 방법

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

시스템 서비스 단위별 로그 보기

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

예를 들어, 시스템에 있는 Nginx 장치의 모든 로그를 보려면 다음을 입력하면 됩니다:

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

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

이를 통해 개별 프로세스 대신 다양한 프로그램과 디버그 시스템 간의 상호 작용을 훨씬 쉽게 찾아낼 수 있습니다.

PID, UID 또는 GID를 기준으로 시스템 로그 필터링

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

이를 위해 _PID를 지정하여 필터링할 수 있습니다. 필드. 예를 들어 우리가 관심 있는 PID가 8088이라면 다음과 같이 입력할 수 있습니다:

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

33

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

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

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

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

예를 들어 systemd가 어떤 그룹 ID인지 확인하려면 저널에 다음 항목이 있습니다. 다음을 입력하세요:

32
99
102
133
81
84
100
0
124
87

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

실행 경로별 로그 보기

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

경로가 실행 파일로 연결되는 경우 journalctl 문제의 실행 파일과 관련된 모든 항목이 표시됩니다. 예를 들어 bash가 포함된 항목을 찾으려면 실행 파일이 있으면 다음을 입력할 수 있습니다:

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

journalctl -k을 사용하여 커널 로그를 보는 방법

커널 메시지(일반적으로 dmesg에 있음) 출력물은 저널에서도 검색할 수 있습니다.

이러한 메시지만 표시하려면 -k을 추가하면 됩니다. 또는 --dmesg 우리 명령에 플래그를 지정합니다:

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

journalctl -p을 사용하여 심각도 수준별로 로그 필터링

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

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

예를 들어 오류 수준 이상으로 기록된 항목만 표시하려면 다음을 입력하세요.

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

• 0 :등장
• 1 :경고
• 2 :치명타
• 3 :오류
• 4 :경고
• 5 :공지
• 6 :정보
• 7 :디버그

위의 숫자나 이름은 -p과 같은 의미로 사용될 수 있습니다. 옵션. 우선순위를 선택하면 지정된 수준과 그 위의 메시지가 표시됩니다.

journalctl 맞춤설정 로그 출력 표시

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

journalctl에서 출력 길이 및 형식을 제어하는 방법

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

기본적으로 journalctl 호출기에 전체 항목이 표시되어 항목이 화면 오른쪽으로 표시됩니다. 이 정보는 오른쪽 화살표 키를 눌러 확인할 수 있습니다.

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

. . .
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에서 호출기를 비활성화하는 방법 출력

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

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

필요에 따라 처리 유틸리티로 즉시 파이프라인을 보내거나 디스크의 파일로 리디렉션할 수 있습니다.

journalctl의 다양한 출력 형식

위에서 언급한 것처럼 저널 항목을 처리하는 경우 데이터가 더 많이 사용 가능한 형식이면 데이터를 구문 분석하는 것이 더 쉬울 가능성이 높습니다. 다행히도 저널은 필요에 따라 다양한 형식으로 표시될 수 있습니다. -o를 사용하여 이 작업을 수행할 수 있습니다. 형식 지정자가 있는 옵션입니다.

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

{ "__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-pretty을 사용할 수 있습니다. 데이터 구조를 JSON 소비자에게 전달하기 전에 데이터 구조를 더 잘 처리하기 위한 형식:

{
 "__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
• json-pretty :더 나은 가독성을 위해 JSON 형식으로
• json-sse :추가 서버에서 보낸 이벤트를 호환 가능하게 만들기 위해 JSON 형식의 출력이 래핑되었습니다.
• 짧음 :기본값 syslog 스타일 출력
• 짧은 ISO :ISO 8601 벽시계 타임스탬프를 표시하기 위해 기본 형식이 강화되었습니다.
• 단단조 :단조로운 타임스탬프가 포함된 기본 형식입니다.
• 짧은 정확성 :마이크로초 정밀도의 기본 형식
• 상세 :일반적으로 내부에 숨겨진 항목을 포함하여 항목에 사용할 수 있는 모든 저널 필드를 표시합니다.

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

journalctl로 실시간 시스템 로그 모니터링

journalctl 명령은 tail를 사용하는 관리자 수를 모방합니다. 활성 또는 최근 활동을 모니터링합니다. 이 기능은 journalctl에 내장되어 있습니다. , 다른 도구로 연결할 필요 없이 이러한 기능에 액세스할 수 있습니다.

journalctl -n으로 최근 로그 항목 표시

설정된 양의 레코드를 표시하려면 -n을 사용할 수 있습니다. tail -n와 정확히 작동하는 옵션 .

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

-n 뒤의 숫자로 보고 싶은 항목 수를 지정할 수 있습니다. :

journalctl -f로 실시간 로그 추적

로그가 작성되는 동안 이를 적극적으로 따르려면 -f을 사용할 수 있습니다. 깃발. 다시 말하지만, tail -f을 사용한 경험이 있다면 예상대로 작동합니다. :

이 명령을 종료하려면 CTRL+C를 입력하세요. .

시스템 저널 로그를 관리하고 정리하는 방법

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

journalctl --disk-usage로 시스템 로그의 디스크 사용량 확인

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

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

journalctl --vacuum-size이 포함된 오래된 로그 삭제 및 --vacuum-time

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

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

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

예를 들어, 작년의 항목을 유지하려면 다음을 입력하세요:

저널링 로그에 대한 디스크 공간 제한 구성

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

일지 증가를 제한하기 위해 다음 항목을 사용할 수 있습니다:

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

이러한 값을 설정하면 journald의 방식을 제어할 수 있습니다. 서버의 공간을 소비하고 보존합니다. SystemMaxFileSize에 유의하세요. 및 RuntimeMaxFileSize 명시된 제한에 도달하도록 아카이브된 파일을 목표로 합니다. 이는 진공 청소 작업 후 파일 수를 해석할 때 기억하는 것이 중요합니다.

공통 journalctl 문제 해결 및 체계화된 저널 이슈

1. 왜 journalctl인가요? 로그가 표시되지 않습니까?

어떤 경우에는 journalctl을 실행할 수도 있습니다. 로그 출력을 기대하는 명령이지만 빈 화면만 나타나거나 의미 있는 결과가 없습니다. 특히 문제를 해결하거나 최근 시스템 활동을 찾는 경우 이러한 상황은 혼란스러울 수 있습니다. 다행히도 journalctl 이유를 이해하는 데 도움이 되는 몇 가지 일반적인 설명이 있습니다. 로그가 표시되지 않습니다.

저널 데이터베이스가 비어 있거나 누락되었습니다

출력이 표시되지 않는 가장 직접적인 이유 중 하나는 저널이 비어 있기 때문입니다. 이는 새로 설치된 시스템, 최소 컨테이너 환경 또는 시스템 로깅이 아직 항목을 생성하지 않은 서버에서 발생할 수 있습니다. 시스템이 메모리(휘발성 저장소)에만 로그를 저장하도록 구성되었을 수도 있습니다. 즉, 재부팅 시 모든 로그가 지워집니다. 영구 로깅이 활성화되어 있는지 확인하려면 journal가 있는지 찾아보세요. 디렉토리:

ls /var/log/journal

이 디렉터리가 존재하지 않거나 비어 있으면 부팅 간에 로그가 저장되지 않는다는 의미입니다. 디렉터리를 생성하고 journald을 다시 시작하면 이 문제를 해결할 수 있습니다. 서비스:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

영구 로깅이 활성화되면 향후 로그가 디스크에 기록되고 재부팅 후에도 유지됩니다.

로깅 서비스가 실행되고 있지 않을 수 있습니다

또 다른 가능성은 로깅 서비스 자체에 오류가 발생했거나 시작하지 못한 것입니다. systemd-journald 서비스는 로그 데이터를 수집하고 관리하는 역할을 담당합니다. 실행되고 있지 않으면 저널은 자연스럽게 비어 있게 됩니다. 다음을 통해 상태를 확인할 수 있습니다:

systemctl status systemd-journald

서비스가 비활성화되었거나 실패한 경우 서비스를 다시 시작하면 로그 수집 기능이 복원됩니다.

필터가 너무 좁을 수 있음

때로는 로그 자체에 문제가 있는 것이 아니라 로그에 액세스하려는 방법에 문제가 있는 경우도 있습니다. 존재하지 않는 단위 이름, 지나치게 구체적인 시간 범위 등 좁은 필터를 사용하면 관련 데이터가 있어도 결과가 반환되지 않을 수 있습니다. journalctl을 실행하는 것이 도움이 되는 경우가 많습니다. 로그가 수집되고 있음을 확인하는 플래그 없이 필요에 따라 점진적으로 필터를 적용합니다.

로그가 회전되었거나 삭제되었을 수 있습니다

마지막으로 저널 로그에는 크기 및 시간 기반 보존 정책이 적용된다는 점을 명심하세요. systemd-journald에 의해 오래된 로그가 정리된 경우 , 더 이상 액세스할 수 없습니다. 다음을 통해 저널이 현재 얼마나 많은 공간을 사용하고 있는지 확인할 수 있습니다:

journalctl --disk-usage

저널 크기를 적극적으로 제한하도록 시스템을 구성했거나 최근에 Vacuum 명령을 수동으로 실행한 경우 로그가 데이터베이스에서 제거되었을 수 있습니다.

2. journalctl 사용 시 권한이 거부되었습니다.

journalctl을 실행하려고 하면 일반 사용자로서 "권한이 거부되었습니다"라는 메시지를 받는 것은 혼자가 아닙니다. 기본적으로 시스템 로그에 대한 액세스는 root로 제한됩니다. systemd-journal의 사용자 및 구성원 그룹. 이 제한은 사용자 활동, 시스템 프로세스 및 서비스 오류에 대한 정보를 포함할 수 있는 잠재적으로 민감한 로그 데이터를 보호하기 위해 고안되었습니다.

journalctl 실행 중 높은 권한으로

가장 간단하고 일반적인 해결책은 sudo로 명령을 실행하는 것입니다. . 이렇게 하면 명령이 실행되는 동안 권한이 상승하고 모든 시스템 로그를 볼 수 있습니다:

sudo journalctl

스크립트를 작성하거나 로그를 자주 검사하는 경우 sudo를 입력하세요. 매번 지루해질 수 있습니다. 그러한 경우에는 사용자에게 저널에 대한 액세스 권한을 영구적으로 부여하는 것이 더 실용적일 수 있습니다.

그룹 멤버십을 통해 사용자 액세스 권한 부여

sudo이 필요하지 않도록 하려면 , systemd-journal에 사용자를 추가할 수 있습니다. 그룹. 이 그룹은 루트가 아닌 사용자가 저널 로그를 읽을 수 있도록 특별히 설계되었습니다. 다음 명령을 사용하여 사용자를 그룹에 추가할 수 있습니다:

sudo usermod -aG systemd-journal yourusername

yourusername를 교체하세요. 실제 로그인 이름으로. 사용자를 그룹에 추가한 후에는 로그아웃했다가 다시 로그인해야 합니다. 변경사항이 적용되려면 완료되면 journalctl을 실행할 수 있습니다. 높은 권한이 필요하지 않습니다.

저널 권한 확인

그룹 구성원 자격으로 문제가 해결되지 않으면 파일 또는 디렉터리 권한에 문제가 있을 수 있습니다. /var/log/journal 디렉토리는 root의 소유여야 합니다. systemd-journal 아래에 그룹화되어 있습니다. . 그룹 읽기 권한을 올바르게 설정해야 합니다. 그렇지 않으면 올바른 그룹에 속하더라도 액세스가 계속 거부됩니다. 다음을 사용하여 이 문제를 해결할 수 있습니다:

sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

이러한 권한과 적절한 그룹 멤버십이 있으면 루트가 아닌 사용자도 로그에 안전하게 액세스할 수 있습니다.

3. 재부팅 후 로그가 지속되지 않음

서버를 재부팅할 때마다 로그가 사라지는 경우 시스템이 휘발성 메모리에만 로그를 저장하도록 구성되었을 가능성이 높습니다. , 기기 전원이 꺼지면 손실됩니다. 이는 많은 Linux 배포판 및 컨테이너 환경, 특히 낮은 디스크 사용량에 최적화된 환경에서 일반적인 기본값입니다.

지속적 로깅 활성화

재부팅 후에도 로그를 유지하려면 영구 저장소를 사용하도록 저널을 구성해야 합니다. 이를 위해서는 저널이 디스크에 로그를 쓸 수 있는 적절한 디렉터리를 생성해야 합니다. 경로 /var/log/journal 이러한 목적으로 사용됩니다. 존재하지 않는 경우 생성하고 로깅 데몬을 다시 시작하세요:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

이 작업이 완료되면 향후 모든 로그가 디스크에 기록되며 시스템 재부팅 후에도 유지됩니다.

저널링된 구성 확인

디렉터리가 존재하지만 로그가 여전히 유지되지 않으면 journald를 검사해 볼 가치가 있습니다. 구성 파일:

sudo nano /etc/systemd/journald.conf

이 파일에서 Storage=을 찾으세요. [Journal] 아래의 지시문 섹션. volatile로 설정된 경우 , persistent로 변경하세요. :

[Journal]
Storage=persistent

파일을 저장하고 서비스를 다시 시작하여 변경 사항을 적용합니다. 이렇게 하면 시스템이 이제부터 RAM 대신 디스크에 로그를 기록하게 됩니다.

4. 실패한 시스템 서비스 디버깅

시스템 관리 서비스가 시작되지 않거나 예기치 않게 충돌하는 경우 journalctl 근본 원인을 파악하는 데 필수적인 도구가 됩니다. Instead of searching through multiple log files, the journal collects all messages related to a service in one place, complete with metadata, timestamps, and priority levels.

Reviewing the Service Status

The first step when troubleshooting is to examine the service status. The systemctl status command provides a snapshot of the service’s current state, including the most recent log entries. 예:

systemctl status nginx.service

This output often reveals immediate issues such as misconfigured paths, permission problems, or exit codes. The exit code and signal information, if present, can be especially helpful for determining whether the service failed on its own or was killed by the system.

Viewing the Full Log History

To see all logs related to the failed service, use journalctl with the -u flag:

journalctl -u nginx.service

This provides a chronological view of messages generated by the service. If you’re trying to diagnose a failure that happened during the last system boot, it’s helpful to limit the output to just that session:

journalctl -u nginx.service -b

Investigating Failure Context

You can often get to the heart of the issue by reading the log entries from a few minutes before and after the failure. Use time-based filters to narrow your focus:

journalctl -u nginx.service --since "10 minutes ago"

This can help identify whether the problem was isolated or part of a larger system issue.

For deeper analysis, you can enable verbose output or view extended error messages using:

journalctl -xe

This command highlights priority messages and recent failures, which can be useful when a service doesn’t leave obvious clues in the standard output.

5. Monitoring SSH Login Attempts

SSH is a primary access method for most Linux servers, which also makes it a common vector for brute-force attacks, unauthorized access attempts, or general auditing. Fortunately, journalctl allows you to monitor all SSH-related activity with ease.

Viewing SSH Logs

Systemd tracks SSH activity under the sshd or ssh unit, depending on your distribution. To see all entries related to SSH:

journalctl -u ssh.service

or, on some systems:

journalctl -u sshd.service

These logs include login attempts, authentication failures, session closures, and key negotiation messages. It’s an excellent first step when verifying who accessed the server and when.

Following SSH Activity in Real Time

For real-time monitoring, you can use journalctl in follow mode. This is especially useful if you suspect an intrusion or want to keep an eye on active login attempts:

journalctl -f -u ssh.service

Each new login event will be printed live as it happens, making it easier to spot failed logins or rapid connection attempts that may indicate malicious behavior.

Filtering by Login Events

If you’re looking for specific login messages, such as failed passwords or accepted connections, you can filter the journal output using keyword matches:

journalctl -u ssh.service | grep "Failed password"
journalctl -u ssh.service | grep "Accepted password"

These messages indicate whether a login was successful and which user attempted it. You can combine these with time filters to narrow the search to a specific window:

journalctl -u ssh.service --since "1 hour ago"

This can be extremely helpful during security audits or forensic investigations.

Frequently Asked Questions (FAQs)

1. Why does journalctl require root access?

By default, journalctl requires root access because it can expose sensitive information collected from system services, kernel messages, user sessions, and background daemons. These logs may include usernames, environment variables, error traces, authentication attempts, and other details that could pose a security risk if accessed by unauthorized users.

To safeguard this data, systemd restricts access to the system journal. However, you don’t always need to use sudo . Non-root users can read logs if they are part of the systemd-journal group. You can add your user to this group with:

sudo usermod -aG systemd-journal yourusername

After logging out and back in, you should be able to access logs without elevated privileges, as long as file permissions on the journal directories are properly configured.

2. How do I make logs persistent across reboots?

To preserve logs after a reboot, you need to configure systemd-journald to use persistent storage rather than volatile memory. By default, some distributions store logs in /run/log/journal , a temporary directory cleared at shutdown. To enable persistent logging:

1. Create the persistent journal directory:

   sudo mkdir -p /var/log/journal
   

2. Set permissions if needed:

   sudo systemd-tmpfiles --create --prefix /var/log/journal
   

3. Restart the journal daemon:

   sudo systemctl restart systemd-journald
   

4. Optional:Verify or edit configuration:

   Open /etc/systemd/journald.conf and ensure the following line is set:

   Storage=persistent
   

This configuration ensures your system retains log data across reboots, making it easier to audit and debug historical issues.

3. Can I clear journalctl logs?

Yes, journalctl allows you to clear logs using the --vacuum-* options provided by systemd-journald . These commands help reduce disk usage by deleting old or excess log data.

Here are common methods to clear or shrink journal logs:

• Remove logs older than a specific time:

  sudo journalctl --vacuum-time=2weeks
  

• Limit total disk usage for all logs:

  sudo journalctl --vacuum-size=500M
  

• Restrict the number of journal files kept:

  sudo journalctl --vacuum-files=10
  

These commands do not erase current or recent logs unless they exceed the defined threshold. To fully remove all logs, you can manually delete the journal files from /var/log/journal , but this is rarely necessary and not generally recommended for production systems.

4. How do I access systemd logs?

You can access systemd logs using the journalctl command, which interfaces directly with the systemd journal. All logs related to services managed by systemd, such as boot messages, unit failures, and runtime errors, are stored in the journal.

For general access:

journalctl

To see logs for a specific systemd service, such as nginx , use:

journalctl -u nginx.service

You can also filter by boot session, priority level, time range, or combine multiple services to gain deeper insight. Unlike traditional log files, journalctl provides a unified, indexed view of log messages from multiple sources.

5. Which command is used to view systemd logs?

The primary command used to view systemd logs is:

journalctl

This tool is included with systemd and provides access to all logs collected by the systemd-journald service, including kernel messages, early boot logs, system services, and user sessions.

You can tailor the command with various options:

• View logs for a specific service:

  journalctl -u ssh.service
  

• Filter logs by priority:

  journalctl -p err
  

• Display logs in real time:

  journalctl -f
  

This makes journalctl the most versatile and comprehensive utility for viewing systemd-related logs.

6. How to see kernel logs through journalctl ?

Kernel messages, such as those traditionally viewed using dmesg , are also available through the systemd journal. To display only kernel messages using journalctl , use the -k flag:

journalctl -k

This command filters the output to include only messages originating from the kernel. It is especially useful for diagnosing hardware issues, kernel module problems, or boot-time errors. You can also use the -b option to show messages from the current or previous boot:

journalctl -k -b -1

This gives you consistent access to kernel logs, integrated with logs from other services for better contextual understanding.

7. What is the difference between dmesg and journalctl ?

While both dmesg and journalctl can show kernel logs, they serve different purposes and operate under different mechanisms.

In short, dmesg is limited to low-level kernel logs in real time, while journalctl offers a more complete, structured, and persistent logging interface that encompasses the entire system.

결론

As you can see, the systemd journal is incredibly useful for collecting and managing your system and application data. Most of the flexibility comes from the extensive metadata automatically recorded and the centralized nature of the log.

In this guide, we covered basic log viewing, time-based and field-based filtering, monitoring kernel and service logs, output formatting, and real-time log tracking. We also discussed journal maintenance, storage limits, and troubleshooting common issues like missing logs or permission errors.

The journalctl command makes it easy to take advantage of the advanced features of the journal and to do extensive analysis and relational debugging of different application components. By mastering journalctl, you gain a versatile, unified logging interface for debugging, monitoring, and auditing across your entire system.

For more detailed insight into logging and troubleshooting on Linux systems, explore the following related tutorials:

• How To Troubleshoot Common Apache Errors
• How To Centralize Logs With Journald on Debian 10
• How To Centralize Logs With Journald on Ubuntu 20.04

This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International License.