5일 전에 마지막으로 다시 시작했는데 왜 Journaltcl 로깅이 오늘만 시작됩니까?

5일 전에 마지막으로 다시 시작했는데 왜 Journaltcl 로깅이 오늘만 시작됩니까?

journaltcl5일 전에 마지막 재부팅이 완료되었는데 오늘만 로그가 시작되는 이유는 무엇입니까 ? :

$ journalctl -e | grep Logs.begin
-- Logs begin at Tue 2022-09-06 09:42:37 CEST, end at Tue 2022-09-06 11:04:27 CEST. --
$ last reboot | head -1
reboot   system boot  3.10.0-1160.62.1 Thu Sep  1 23:46 - 11:04 (4+11:18)
$ journalctl -u scality-sfused
-- No entries --
$ egrep -v "^$|^#" /etc/systemd/journald.conf
[Journal]
RateLimitInterval=2s
RateLimitBurst=5000
ForwardToSyslog=yes
$ systemctl status scality-sfused | grep Warning
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
$ ls /etc/logrotate.d/scality-sfused
ls: cannot access /etc/logrotate.d/scality-sfused: No such file or directory
$

/var/lib/logrotate/logrotate.statusEDIT0: 오늘부터 입니다 .

$ cat /var/lib/logrotate/logrotate.status | grep $(date +%Y-%-m-%-d)
"/var/log/scality/node/node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-11.log" 2022-9-6-3:11:1
"/var/log/scality-biziod.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.err" 2022-9-6-3:11:1
"/var/log/scality/node/node-11.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.out" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-srebuildd.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-sagentd.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-11.log" 2022-9-6-3:11:1
$

편집 1: /etc/anacrontab파일은 다음과 같습니다.

$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

답변1

상태 출력을 보면 logrotateScalar 애플리케이션의 로그가 회전되었음을 확인할 수 있습니다. 그러나 여기에는 약간의 혼란이 있습니다.고려해야 할 로그 세트logrotate반환된 내용에는 영향을 주지 않으며 journalctl, 저널드 자체 파일은 관리되지 않습니다 logrotate.

일기장

man systemd-journald.serviceJournald에서 저장하고 보고하는 로그 소스 5개를 나열합니다.

  1. 커널 로그 메시지

    이는 애플리케이션의 동작에 의해 영향을 받을 수 있지만 애플리케이션의 출력은 아닙니다. 이름으로는 커널의 메시지입니다. 이는 귀하가 볼 수 있는 것과 동일한 내용입니다 dmesg.

  2. libc syslog(3)를 통해 호출되는 간단한 syslog 메시지

    이는 지속성 서비스를 포함한 애플리케이션이 사용할 수 있는 전통적인 로깅 방법입니다. systemd-journald(함께 잘 작동함) 대신 또는 함께 기존 syslog 구현을 실행하는 경우 /var/logmessages. syslog그렇지 않은 경우에도 로그에 캡처되어 서비스 계층 구조에 표시됩니다. 로거 자체가 그렇게 하도록 설정되지 않은 한, 이는 애플리케이션의 제어 범위를 벗어나는 애플리케이션별 파일의 사용을 허용하지 않는다는 점에 유의하십시오. syslog로 전송된 콘텐츠는 일반적으로 애플리케이션 이름으로 태그가 지정되지만 모두 함께 묶여 있습니다. 이는 커널 메시지도 일반적으로 syslog에 의해 캡처되므로 syslog는 실시간 시스템 이벤트의 인터리브된 기록이기 때문에 유용합니다.

    그러나 많은 응용 프로그램에서는 이를 전혀 사용하지 않으며, 내가 아는 한 이에 대해 찬성하거나 반대하는 강력한 규칙이 없습니다. systemd 자체는 syslog에 기록됩니다.저널드를 통해 syslog는 저널드가 제공할 수 있는 것입니다.

  3. 기본 Journal API를 통해 구조화된 syslog 메시지 작성

    이는 명령의 저널 버전일 수 있습니다 syslog. 즉, 애플리케이션 소스 코드에서 명시적으로 사용해야 함을 의미합니다. 이것이 얼마나 흔한지는 모르겠지만 데스크탑 환경, 패키지 관리자 등과 같은 핵심 Linux 중심 기능 외에는 큰 영향을 미치지 않을 것입니다.

  4. 서비스 단위의 표준 출력 및 표준 오류.

    이를 캡처하는 것은 systemd-journald의 기본 동작이지만 서비스 파일을 통해 다양한 위치로 리디렉션될 수도 있습니다.

    내 경험에 따르면 대부분의 복잡한 서비스 애플리케이션에서는 이를 많이 사용하지 않습니다.

  5. 커널 감사 하위 시스템에서 파생된 감사 기록

    맥락상 이는 실제로 #1의 하위 카테고리입니다.

  6. 이는 맨페이지에 명시적으로 표시되어 있지 않지만 장치별 Journalctl 출력에는 문제의 장치와 관련된 systemd의 메시지가 포함되어 있는 것으로 보입니다(예: Starting XXXXX...).

이들 중 어느 것도 에 많은 콘텐츠를 포함하지 않습니다 /var/log/scality. 즉, 이러한 파일은 로그나 syslog와 관련이 없습니다.

애플리케이션 로그

저는 Scality 사용자는 아니지만 거기에 있는 콘텐츠는 /var/log/scality확실히 외부에서 캡처한 콘텐츠가 아니라 애플리케이션에서 직접 생성한 콘텐츠입니다.

systemd 또는 Journald가 이러한 기능을 사용하지 않는 한 가지 분명한 이유는 프로그램이 다양한 파일에 데이터를 기록하고 해당 프로세스를 안내하는 일부 구성 프로토콜이 없으면 저널링과 같은 외부 엔터티가 레코드 데이터가 무엇인지, 레코드가 무엇인지 알 수 있는 방법이 없기 때문입니다. 데이터. 아니요. 위에서 언급한 것처럼 애플리케이션이 syslog 등을 사용하는 메커니즘이 이미 있기 때문에 그러한 프로토콜을 사용할 이유가 많지 않습니다.

자체 로그 파일을 많이 작성하는 작업은 일반적으로 logrotate작업을 깔끔하게 유지하도록 배열됩니다. Logrotate는 systemd보다 이전 버전이며 Journald와는 아무런 관련이 없습니다. Journald는 자체 영구 저장소(있는 경우)를 유지 관리합니다.

간단히 말해서 "장치가 시작된 이후 로그가 회전되었습니다"에 대한 원래 메시지는아니요로그가 회전하기 때문입니다. 이것은 저널드 자체 운영의 일부입니다. 또한 Scality 로그인은 /var/log/scalityJournald가 아니라 Scality 자체에서 관리합니다.

관련 정보