Journalctl을 사용하여 Systemd 로그 보기 및 조작하기

시스템 및 프로세스 로깅은 단지 가장 중추적인 장점 중 두 가지에 불과합니다. 바로 systemd의 장점입니다. 로그가 시스템 전체에 분산되어 있고, 여러 애플리케이션에 걸쳐 있으며, 서로 다른 프로세스와 데몬에 의해 처리될 때, 이를 해석하는 것은 어려울 수 있습니다. systemd는 저널(journal)로 알려진 컴파일 매체에서 모든 커널 및 사용자 공간 프로세스 로그를 관리하기 위한 중앙 집중식 솔루션을 제공합니다. systemd에 대한 자세한 내용은 systemctl을 사용하여 systemd 서비스 및 유닛을 관리하는 방법에 대한 자습서에서 확인할 수 있습니다. 저널의 서비스, initrd, 커널 등에 의해 생성된 모든 메시지는 저널 데몬에 의해 처리됩니다. 이 가이드의 목적은 journalctl을 사용하여 저널 데이터에 액세스하고 조작하는 방법을 설명하는 것입니다.

기본 전제

메시지가 어디서 시작되었는지에 관계없이, systemd의 주요 목표 중 하나는 메시지 관리를 중앙 집중화하는 것입니다. 많은 부팅 프로세스와 서비스 관리의 상당 부분이 systemd 프로세스에 의해 처리되므로, 로그가 컴파일되고 액세스되는 방식은 표준화되어야 합니다. 사용 가능한 모든 소스에서 데이터를 수집하여 하나의 포괄적인 도구로 통합하고, journald는 이를 바이너리 형식으로 저장합니다. 이를 통해 데이터를 동적이고 간단하게 조작할 수 있도록 쉽게 사용할 수 있습니다.

이러한 접근 방식에는 몇 가지 주요 장점이 있습니다. 모든 데이터를 수집하는 중앙 집중식 공간을 가짐으로써 관리자는 필요한 데이터만 필터링하여 표시할 수 있습니다. 예를 들어, 세 번 전의 시스템 부팅 시의 부팅 데이터를 볼 수 있습니다. 또한 관련 서비스의 항목을 순차적으로 로깅하여 서비스 간의 통신 문제를 더 효과적으로 추적할 수 있음을 의미할 수도 있습니다.

바이너리 저장 방식 덕분에 당시 사용자의 필요에 따라 다양한 출력 형식으로 데이터를 표시할 수 있습니다. 예를 들어, 일일 로그를 표준 syslog 형식으로 볼 수 있습니다. 하지만 서비스 중단 추세를 그래프 형태로 나타내야 하는 경우, 해당 항목을 JSON 객체로 출력하여 그래프 서비스와 연동할 수 있습니다. 상황에 따라 형식을 변경해야 할 때, 데이터가 바이너리 형식이고 디스크에 일반 텍스트로 기록되지 않으므로 별도의 변환이 필요하지 않습니다.

필요에 따라 systemd 저널을 기존 syslog와 함께 구현하거나 그 기능을 대체할 수 있습니다. systemd는 기존 로깅 메커니즘을 보완할 수도 있습니다. 예를 들어, 단일 시스템의 여러 서비스에서 컴파일된 데이터를 systemd 저널을 통해 단일 시스템에 결합할 수 있습니다.

시스템 시간 설정

systemd는 기본적으로 결과를 로컬 시간으로 표시하며, 이는 로그 기록을 보는 방식에서 바이너리 저널 로깅이 갖는 이점입니다. 또는 UTC로 볼 수도 있습니다. 따라서 저널 로깅을 시작하기 전에 시간대(timezone)가 올바르게 설정되어 있는지 확인하는 것이 중요합니다. 이를 위해 systemd에는 timedatectl이라는 도구가 제공됩니다. 먼저 list-timezones 옵션으로 목록을 표시하여 사용할 수 있는 시간대를 확인하는 것부터 시작합니다.

서버 위치에 맞는 시간대를 찾은 후, set-timezone 옵션을 사용하여 시간대를 설정할 수 있습니다.

시간대가 이제 올바르게 표시되는지 테스트하고 확인하려면 timedatectl 명령을 단독으로 사용하거나 'status'를 추가하여 사용할 수 있습니다.

첫 번째 줄은 로컬 시간을 나타냅니다. 이 줄에는 해당 지역의 올바른 시간이 포함되어야 합니다.

일반 로그 보기

journalctl 명령을 사용하면 journald 데몬이 수집한 로그를 볼 수 있습니다. journalctl을 사용하면 시스템의 모든 저널 항목이 화면 페이지 내에 표시되며, 가장 오래된 항목이 맨 위에 나열됩니다. 그러나 전체 데이터 목록은 수만 줄에 달할 것입니다.

표준 syslog 로깅을 사용해 본 사람이라면 이 형식이 익숙하겠지만, syslog 방식과 달리 이 데이터 컴파일은 여러 소스에서 포함된다는 점을 명심해야 합니다. 로그에는 초기 부팅 프로세스, initrd, 커널뿐만 아니라 애플리케이션 표준 에러도 포함됩니다.

이제 로컬 시간이 설정되었으므로 모든 항목은 로컬 시간으로 표시된 타임스탬프로 시작하며, 현재 시스템에 저장된 모든 로그에 적용되고 이 새로운 정보를 사용하여 모든 로직이 표시됩니다. 하지만 로컬 시간에만 국한되지는 않습니다. –utc 플래그를 사용하면 타임스탬프를 UTC로도 표시할 수 있습니다:

시간별 저널 필터링

이렇게 많은 데이터를 사용할 수 있다는 것은 매우 유용한 일이지만, 이를 샅샅이 뒤져서 이해하는 것은 물론 머릿속으로 처리하는 것조차 버거운 작업이 될 수 있습니다. 이를 염두에 두고, journalctl 기능의 가장 중요한 부분인 필터링에 도달하게 됩니다.

현재 부팅의 로그 표시

최근 재부팅 시점의 저널 데이터를 찾고 있다면 -b 플래그와 함께 journalctl 기능을 사용할 수 있습니다. 이렇게 하면 시스템의 가장 최근 재부팅에서 발생한 모든 관련 로그 정보가 표시됩니다. 이 명령을 사용하면 현재 작업 환경에 가장 관련성이 높은 정보를 찾고 관리할 수 있습니다:

사용자가 개별 항목을 일일이 평가하지 않기로 선택한 경우, journalctl은 편리한 ‘Reboot’ 구분 기호와 함께 하루 이상의 부팅 기록을 보여줍니다. 이는 검토를 위해 서로 다른 부팅 세션의 정보를 논리적으로 분리하는 데 도움이 됩니다:

이전 부팅 정보

현재 부팅 정보를 표시하는 것이 가장 유용한 경우가 많지만, 이전 부팅 정보가 도움이 되는 상황도 있습니다. 저널은 이전의 여러 부팅 정보를 저장하므로, journalctl을 사용하여 모든 기간의 정보를 쉽게 표시할 수 있습니다.

특정 배포판은 이전 부팅 정보 저장을 비활성화하는 반면, 다른 배포판은 기본적으로 활성화해 둡니다. 영구 부팅 정보 활성화는 다음과 같이 입력하여 저널 저장용 디렉터리를 생성함으로써 수행할 수 있습니다:

또는 다음과 같은 방법으로 저널 설정 파일을 편집할 수도 있습니다:

[Journal] 섹션 아래의 Storage= 옵션을 “persistent”로 설정하면 영구 로깅이 활성화됩니다:

이 기능이 활성화되면 journalctl은 이러한 부팅을 구분 단위로 지정하는 데 도움이 되는 특정 명령을 제공합니다. journald에 기록된 부팅을 보려면 journalctl을 통해 –list-boots 옵션을 사용할 수 있습니다:

그림과 같이 각 부팅은 한 줄에 하나씩 나열되며, 첫 번째 열은 가장 오래된 것부터 가장 최근 것 순으로 이전 부팅을 반영합니다. 더 절대적인 참조가 필요한 경우 두 번째 열에 부팅 식별자(ID)가 포함됩니다. 그 뒤에는 두 개의 시간 사양이 나열됩니다. 첫 번째 또는 두 번째 열의 정보를 사용하여 특정 부팅의 저널 정보를 표시할 수 있습니다. 예를 들어, 상대적 부팅 포인터인 -1과 함께 -b 플래그를 사용하여 가장 최근에서 두 번째로 이전의 재부팅 정보를 볼 수 있습니다:

마찬가지로 두 번째 열의 부팅 ID도 다음과 같은 방식으로 사용할 수 있습니다:

시간 범위

ID별로 부팅을 확인하는 것도 하나의 방법이지만, 특정 부팅과 반드시 일치하지는 않을 수 있는 과거의 시간 범위를 기준으로 이전 부팅을 참조하는 것이 더 유용한 경우가 많습니다. 예를 들어, 자주 재부팅되지 않고 오랫동안 실행되는 서버를 다루는 상황에서 이 방법이 유용합니다. 시간 제한 필터링은 임의의 시간 제한을 사용하여 수행할 수 있습니다. 이렇게 하면 특정 시간 범위 내에 발생하는 재부팅에 대한 정보만 표시됩니다. 이 시간 범위의 매개변수는 –since 및 –until 옵션으로 지정됩니다. 시간 옵션에는 여러 가지 형식을 사용할 수 있습니다. 절대 시간 값 형식은 다음과 같습니다:

따라서 2015년 1월 10일 오후 5시 15분 이후의 모든 부팅을 확인하려면 다음 명령을 입력하십시오:

구성 요소 중 일부가 생략되면 내장된 기본값이 적용됩니다. 또한 날짜를 생략하면 현재 날짜가 기본값으로 설정됩니다. 시간 구성 요소가 없으면 자정(00:00:00)이 기본값입니다. 시간 구성 요소에서 초를 생략하면 해당 분의 시작 시점(00)이 기본값으로 설정됩니다:

저널은 “today”(오늘), “tomorrow”(내일), “yesterday”(어제), “now”(지금)와 같은 시간 관련 단축어를 이해할 수 있습니다. 앞에 붙는 한정자 “-” 및 “+”와 함께 ago와 같은 단어를 사용하여 문장 형태의 명령을 구성할 수 있습니다:

오전 9시에 시작된 서비스 중단 알림을 받고 1시간 전까지의 저널 로그를 확인하려는 경우 다음과 같이 할 수 있습니다:

보시다시피, 원하는 항목을 보기 위해 유연한 시간 범위를 정의하는 것은 매우 간단합니다.

관심 메시지별 필터링

시간 제한으로 저널을 필터링하는 것 외에도, 관심 있는 서비스 구성 요소를 기준으로 데이터를 필터링할 수도 있습니다. Systemd는 이를 수행하는 몇 가지 방법을 제공합니다.

유닛별 필터링

가장 유용한 필터링 매개변수는 관심 있는 유닛별 필터링입니다. 유닛별로 필터링하려면 -u 옵션을 사용할 수 있습니다. 예를 들어 Nginx 유닛과 관련된 모든 로그를 보려면 다음 명령을 입력하십시오:

실제로는 관심 있는 줄을 표시하기 위해 이를 시간 필터와 결합하는 것이 좋습니다. 위의 서비스와 오늘 어떻게 작동했는지 확인하려면 다음과 같이 할 수 있습니다:

이는 여러 유닛, 특히 협력하는 유닛의 기록을 수집하는 저널의 기능을 활용할 때 특히 유용합니다. 동적 콘텐츠 처리를 위해 Nginx 프로세스가 PHP-FPN 유닛에 연결되어 있는 경우, 두 유닛을 모두 지정하여 항목을 시간순으로 병합할 수 있습니다:

이는 프로그램 간의 상호 작용을 파악하는 데 큰 도움이 되며, 개별 프로세스가 아닌 시스템 디버깅을 더 쉽게 만들어 줍니다.

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

많은 서비스가 특정 작업을 수행하기 위해 다수의 하위 프로세스(자식 프로세스)를 시작합니다. 특정 프로세스의 ID를 알고 있는 경우, _PID 필드를 지정하여 필터링할 수도 있습니다. 관심 있는 PID가 8088인 경우 다음과 같이 할 수 있습니다:

특정 그룹 또는 특정 사용자가 기록한 항목을 보고 싶을 수도 있습니다. 이는 _GID 및 _UID 필터를 사용하여 수행할 수 있습니다. 웹 서버가 www-data 사용자로 실행되는 경우, 다음 명령으로 필요한 ID를 찾을 수 있습니다:

해당 ID를 사용하여 조건에 맞는 저널 결과를 볼 수 있습니다:

Systemd는 필터링 목적으로 사용할 수 있는 많은 필드를 제공합니다. 일부 필드는 로그 기록 시점에 시스템에서 수집된 정보를 기반으로 journald에 의해 적용되며, 다른 필드는 현재 로그가 기록되고 있는 프로세스에서 전달됩니다.

_PID 접두사는 로그 기록 시점에 시스템에서 정보를 수집했음을 나타냅니다. 저널은 나중에 필터링 기능을 사용할 수 있도록 로그 기록 프로세스 중에 PID를 자동으로 기록하고 인덱싱합니다. 사용 가능한 저널 필드에 대해 알아보려면 다음과 같이 입력할 수 있습니다:

이 가이드의 뒷부분에서 이들 중 일부를 다루겠지만, 지금은 이러한 필드와 관련된 다른 유용한 옵션 몇 가지를 살펴보겠습니다. 특정 저널 필드에 대해 사용 가능한 모든 값을 보려면 -F 옵션을 사용할 수 있습니다. systemd 저널에 그룹 ID로 무엇이 있는지 확인하려면 다음과 같이 할 수 있습니다:

이것은 저널 그룹 ID 필드에 저장된 전체 값 목록을 제공하여 필터를 구성하는 데 도움이 될 수 있습니다.

구성 요소 경로별

경로 위치를 제공하여 필터링을 수행할 수도 있습니다. 경로가 실행 파일인 경우, 해당 실행 파일과 관련된 journalctl 항목이 표시됩니다. 관심 있는 실행 파일이 'bash'인 경우 다음과 같이 입력할 수 있습니다:

때로는 불가능할 수도 있지만, 실행 파일의 유닛을 사용할 수 있다면 필터링을 위한 더 명확하고 유용한 정보를 제공하는 방법을 생성할 수 있습니다.

커널 메시지 표시

일반적으로 dmesg 출력에서 볼 수 있는 커널 메시지도 저널에서 가져올 수 있습니다. 이 메시지만 표시되도록 하려면 명령의 일부로 -k 또는 -dmesg 플래그를 사용합니다:

기본적으로 현재 부팅의 메시지가 표시되지만, 앞서 언급한 선택 플래그를 사용하여 이전 부팅을 지정할 수 있습니다. 다섯 번 전 부팅의 메시지를 찾고 있다면 다음과 같이 입력하여 필요한 결과를 얻을 수 있습니다:

우선순위별

시스템 관리자는 종종 우선순위별로 필터링하는 것을 선호합니다. 낮은 우선순위 로그는 보기에는 유용할 수 있지만, 혼란스럽고 주의를 분산시키는 요소가 많아 분석 중에 이해하기 어려울 수 있습니다. journalctl에서 -p 옵션을 사용하면 지정된 우선순위의 메시지만 표시하고 다른 우선순위는 필터링하여 제외합니다. 에러 레벨 이상의 항목을 표시하려면 다음과 같이 입력하십시오:

이 명령은 표준 syslog 메시지 레벨을 사용하는 저널에서 error, alert, emergency 또는 critical로 표시된 모든 메시지를 반환합니다. 우선순위 레벨은 숫자 값에 따라 정의되며, 가장 높은 것부터 가장 낮은 것 순으로 정렬됩니다:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

위의 모든 항목은 -p 옵션과 혼용하여 사용할 수 있습니다. 위에서 설명한 우선순위 중 하나를 선택하면 해당 레벨 이상의 모든 우선순위가 필터링됩니다.

저널의 표시 방식 수정

항목 선택을 위해 필터링을 사용하는 것 외에도, 출력을 수정하여 journalctl의 표시 방식을 필요에 맞게 조정하는 다른 방법이 있습니다.

출력 잘라내기/확장

journalctl이 데이터를 축소할지 또는 확장할지 조정하여 출력 보기를 조정할 수 있습니다. journalctl의 기본값은 전체 항목을 표시하는 것이며, 긴 항목은 화면 오른쪽으로 벗어납니다. 오른쪽 화살표 키를 사용하여 스크롤하면 항목 전체를 볼 수 있습니다. 사용자는 대신 출력을 잘라내어 화면을 벗어나는 줄에 생략 부호(...)를 표시하고자 할 수 있습니다. 이를 위해 –no-full 옵션을 사용할 수 있습니다:

또는 -a 플래그를 사용하여 길이에 관계없이 또는 인쇄할 수 없는 문자의 포함 여부와 상관없이 모든 것을 표시하도록 허용할 수도 있습니다:

표준 출력으로 출력

Journalctl은 기본적으로 출력을 페이저로 표시하지만, 텍스트 편집 도구로 데이터를 조작하려는 경우 출력이 표준 출력 옵션으로 생성되도록 해야 할 수 있습니다. 이는 –no-pager 옵션으로 수행할 수 있습니다:

사용자의 필요에 따라 이를 디스크의 파일이나 처리 유틸리티로 리디렉션할 수 있습니다.

출력 형식

데이터는 더 사용하기 쉬운 형식으로 제공될 때 항상 파싱하기가 더 쉽습니다. 저널은 -o 한정자 뒤에 특정 형식을 지정하여 표시할 수 있는 여러 옵션을 제공합니다.

저널 항목을 JSON 형식으로 출력하려면 다음과 같은 방법으로 수행할 수 있습니다:

이 전략은 유틸리티를 파싱할 때 특히 유용합니다. json-pretty 형식은 JSON 컨슈머로 전달하기 전에 데이터 구조를 더 잘 보여줄 수 있습니다:

표시하는 데 사용할 수 있는 몇 가지 형식이 있습니다:

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

위의 옵션을 사용하면 저널을 원하는 형식으로 표시할 수 있습니다.

활성 프로세스 모니터링

저널을 사용하면 다른 도구를 사용하지 않고도 활성 또는 최근 활동 모니터링 기능에 액세스할 수 있습니다. 이는 ‘tail’ 기능이 있는 journalctl 명령으로 수행할 수 있습니다.

• 최근 로그 표시

-n 옵션을 표시하면(tail -n 명령과 동일하게 작동함) 특정 개수의 레코드를 표시할 수 있습니다:

표시하려는 항목의 수는 -n 한정자 뒤에 특정 숫자를 지정하여 설정할 수 있습니다:

• 로그 실시간 추적

-f 플래그를 사용하면 시스템에 기록되는 로그를 실시간으로 추적할 수도 있습니다. 이 또한 tail -f 명령과 동일한 방식으로 작동합니다:

저널 유지 관리

로그는 공간을 차지합니다. 공간을 확보하기 위해 오래된 로그 중 일부를 정리하는 방법을 알아볼 가치가 있습니다.

현재 디스크 사용량 확인

–disk-usage 플래그를 사용하면 현재 로깅이 디스크에서 차지하는 공간을 확인하는 데 도움이 될 수 있습니다:

오래된 로그 삭제

systemd 버전 218(및 이후 버전)에서는 두 가지 방법으로 저널 크기를 줄일 수 있습니다. 하나는 –vacuum-size 옵션입니다. 이는 크기를 지정하여 저널을 축소할 수 있습니다. 즉, 차지하는 공간이 요청된 매개변수에 도달할 때까지 오래된 항목이 로그에서 삭제됩니다:

–vacuum-time 옵션은 기준 시간을 지정하여 저널의 공간 점유를 줄일 수 있으며, 해당 시간 이전의 모든 항목은 삭제되고 지정된 시간 이후에 생성된 항목은 유지됩니다. 지난 1년 동안의 항목만 유지하려면 다음을 사용할 수 있습니다:

저널 확장 제한

저널이 차지할 공간의 양을 제한할 수도 있습니다. 이는 /etc/systemd.journald.conf 파일을 편집하여 수행할 수 있습니다. 저널 증가는 다음 방법 중 하나를 사용하여 제한할 수 있습니다:

• SystemMaxUse=: 저널이 영구 저장소에서 사용할 수 있도록 허용된 최대 디스크 공간을 나타냅니다.
• SystemKeepFree=: 저널 엔티티가 영구 저장소에 추가될 때 비워 두어야 하는 공간의 양을 나타냅니다.
• SystemMaxFileSize=: 영구 저장소에서 순환(rotation)되기 전까지 저널 파일이 커질 수 있는 최대 크기를 지정합니다.
• RuntimeMaxUse=: 휘발성 저장소(/run 파일 시스템 내)에서 사용할 수 있는 디스크 공간의 양을 지정합니다.
• RuntimeKeepFree=: 휘발성 저장소에 데이터를 쓸 때, 이 기능은 다른 용도로 남겨두어야 하는 공간의 양을 나타냅니다(/run 파일 시스템 내).
• RuntimeMaxFileSize=: 개별 로그 저널이 순환되기 전에 휘발성 저장소(/run 파일 시스템 내)에서 차지할 수 있는 공간의 양을 나타냅니다.

이 옵션들은 모두 저널의 저장소 소비를 제어하는 데 도움이 될 수 있습니다. 주의해야 할 중요한 사실은 SystemMaxFileSize 및 RuntimeMaxFileSize 옵션이 명시된 제한에 도달하기 위해 아카이브된 파일을 대상으로 한다는 점입니다. 이는 정리(vacuuming) 작업 후 파일 수를 해석할 때 염두에 두어야 할 중요한 사실입니다.

결론

systemd 저널은 활용하기에 매우 유용한 도구임이 분명하며, 그 이점의 대부분은 로그’의 중앙 집중식 특성과 기록된 메타데이터의 방대한 양에서 비롯됩니다. 저널의 광범위한 기능은 journalctl 명령어를 활용하여 이점을 얻을 수 있으며, 이를 통해 애플리케이션 구성 요소의 관계형 디버깅뿐만 아니라 광범위한 시스템 분석을 더 쉽게 수행할 수 있습니다.

즐거운 컴퓨팅 되세요!