다시 로드하지 않고 실행 중인 SystemD 서비스의 JournalD 로그 수준 변경

다시 로드하지 않고 실행 중인 SystemD 서비스의 JournalD 로그 수준 변경

로깅을 위해 SystemD JournalHandler를 사용하는 Python으로 작성된 간단한 서비스가 있습니다(SysLogHandler도 비슷하게 작동해야 합니다).

# myservice.py
import time

import logging
from systemd.journal import JournalHandler

log = logging.getLogger('demo')
log.addHandler(JournalHandler())
log.setLevel(logging.DEBUG)


while True:
    log.debug("debug")
    log.info("info")
    log.warning("warning")
    log.error("error")
    time.sleep(3)

이 서비스를 실행하는 SystemD 구성은 다음과 같습니다.

# myservice.service
[Unit]
Description=Python logging test
 
[Service]
ExecStart=/usr/bin/python3 .../myservice.py
Type=simple
 
[Install]
WantedBy=multi-user.target

이제 이는 항상 모든 것을 JournalD에 기록합니다.

# journalctl -f
Mar 06 15:58:13 myhost .../myservice.py[12852]: debug
Mar 06 15:58:13 myhost .../myservice.py[12852]: info
Mar 06 15:58:13 myhost .../myservice.py[12852]: warning
Mar 06 15:58:13 myhost .../myservice.py[12852]: error

런타임 시 이 SystemD 서비스의 로깅 구성을 변경할 수 있습니까?뒤쪽에이미 시작되었습니다(DEBUG 수준). 서비스를 다시 로드하거나 다시 시작할 필요가 없나요? Python 코드에서 로그 수준을 완전히 설정하지 않고 SystemD가 로그 수준을 처리하도록 하고 싶습니다.

기본적으로 나는 이것을 다음과 같이 부르고 싶습니다.

# Log everything to JournalD
change-systemd-service-loglevel myservice DEBUG

# Ignore all logs < WARNING, these should not show up on journalctl
change-systemd-service-loglevel myservice WARNING

답변1

대신, 로그에 기록될 내용을 선택하면 일반적으로 모든 내용을 기록한 다음 로그에서 원하는 내용을 필터링할 수 있습니다. 이렇게 하면 문제가 발생하더라도 문제를 재현하지 않고도 디버그 내용을 읽을 수 있습니다.

journalctl --priority필터 로그 수준을 사용할 수 있습니다 . man journalctl설명하다:

       -p, --priority=
           Filter output by message priorities or priority ranges. Takes
           either a single numeric or textual log level (i.e. between
           0/"emerg" and 7/"debug"), or a range of numeric/text log levels
           in the form FROM..TO. The log levels are the usual syslog log
           levels as documented in syslog(3), i.e.  "emerg" (0),
           "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5),
           "info" (6), "debug" (7). If a single log level is specified, all
           messages with this log level or a lower (hence more important)
           log level are shown. If a range is specified, all messages within
           the range are shown, including both the start and the end value
           of the range. This will add "PRIORITY=" matches for the specified
           priorities.

시연하기 위해 몇 초 동안 Python 스크립트를 실행했습니다. 내 터미널에는 회색, 흰색, 호박색, 빨간색이 debug있습니다 .infowarningerror

사례 1: 필터가 없습니다.

$ journalctl --user -u pylog --no-hostname
Mar 07 08:54:03 systemd[1064]: Started Python logging test.
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: debug
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: info
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: warning
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: error
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: debug
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: info
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: warning
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: error

사례 2: 경고 필터(상세 구문)

$ journalctl --user -u pylog --no-hostname --priority=warning
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: warning
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: error
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: warning
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: error

사례 3: 정보 및 경고 범위 필터(간단한 구문)

$ journalctl --user -u pylog --no-hostname -p 4..6
Mar 07 08:54:03 systemd[1064]: Started Python logging test.
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: info
Mar 07 08:54:03 /home/stew/bin/pylog.py[953165]: warning
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: info
Mar 07 08:54:06 /home/stew/bin/pylog.py[953165]: warning

특정 수준의 로깅을 실제로 방지하려면 다음을 참조하세요 man systemd.exec.

       LogLevelMax=
           Configures filtering by log level of log messages generated by
           this unit. Takes a syslog log level, one of emerg (lowest log
           level, only highest priority messages), alert, crit, err,
           warning, notice, info, debug (highest log level, also lowest
           priority messages). See syslog(3) for details. By default no
           filtering is applied (i.e. the default maximum log level is
           debug). Use this option to configure the logging system to drop
           log messages of a specific service above the specified level. For
           example, set LogLevelMax=info in order to turn off debug logging
           of a particularly chatty unit. Note that the configured level is
           applied to any log messages written by any of the processes
           belonging to this unit, as well as any log messages written by
           the system manager process (PID 1) in reference to this unit,
           sent via any supported logging protocol. The filtering is applied
           early in the logging pipeline, before any kind of further
           processing is done. Moreover, messages which pass through this
           filter successfully might still be dropped by filters applied at
           a later stage in the logging subsystem. For example,
           MaxLevelStore= configured in journald.conf(5) might prohibit
           messages of higher log levels to be stored on disk, even though
           the per-unit LogLevelMax= permitted it to be processed.

man journal.conf. 여기 있습니다:

       MaxLevelStore=
           Controls the maximum log level of messages that are stored in the
           journal. As argument, takes one of "emerg", "alert", "crit", 
           "err", "warning", "notice", "info", "debug", or integer values in 
           the range of 0–7 (corresponding to the same levels). Messages 
           equal or below the log level specified are stored/forwarded, 
           messages above are dropped. Defaults to "debug" to ensure that 
           the all messages are stored in the journal and forwarded to 
           syslog. These settings may be overridden at boot time with the 
           kernel command line options "systemd.journald.max_level_store="

그러나 실시간으로 구성할 수는 없습니다. 실시간 구성의 경우 모든 것을 기록하고 필터를 사용하여 읽으십시오.

관련 정보