Python在Debian上的日志管理怎么做

在 Debian 环境下给 Python 应用做日志管理，其实有一个很成熟的套路：以 Python 内置的 logging 模块为根基，根据不同环境灵活配置日志级别和输出目标，再配合按大小或时间的轮转策略，最后视情况与 systemd journal 或 syslog 这类系统级日志设施对接。如果业务复杂度上来了，还可以引入结构化日志和集中式日志平台。这样搭出来的体系，可维护、可观测，也方便未来扩展。

一、核心方案与最小示例

先从最基础的部分说起。直接用标准库的 logging，同时输出到控制台和一个按大小滚动的文件，这对本地开发和线上排查问题都足够了。

一个典型配置需要关注几个要点：

• 日志级别：DEBUG、INFO、WARNING、ERROR、CRITICAL，按场景选。
• 处理器：StreamHandler 走控制台，RotatingFileHandler 走文件（按大小滚动）。
• 日志格式：建议包含时间、级别、模块名、函数名、行号、进程ID和线程名——这些信息在排查问题时价值巨大。

# pip install python-json-logger
# 如需 JSON 输出
import logging
from logging.handlers import RotatingFileHandler

LOG_FMT = '%(asctime)s %(levelname)s %(name)s %(funcName)s:%(lineno)d %(process)d %(threadName)s | %(message)s'
DATE_FMT = '%Y-%m-%d %H:%M:%S'

logger = logging.getLogger("myapp")
logger.setLevel(logging.DEBUG)

# 控制台：INFO 及以上
ch = logging.StreamHandler()
ch.setLevel(logging.INFO)
ch.setFormatter(logging.Formatter(LOG_FMT, DATE_FMT))
logger.addHandler(ch)

# 滚动文件：DEBUG 及以上，单个 10MB，保留 7 个备份
fh = RotatingFileHandler("/var/log/myapp/app.log", maxBytes=10*1024*1024, backupCount=7, encoding="utf-8")
fh.setLevel(logging.DEBUG)
fh.setFormatter(logging.Formatter(LOG_FMT, DATE_FMT))
logger.addHandler(fh)

# 使用示例
logger.info("服务启动", extra={"host": "app01", "port": 8000})
try:
    1 / 0
except Exception:
    logger.exception("未捕获异常")  # 自动附带 traceback

这段代码里有两个细节值得注意：控制台只输出 INFO 及以上的日志，避免开发阶段的 DEBUG 日志刷屏；文件日志则保留了所有 DEBUG 级别的信息，方便事后回溯。

二、系统级集成与集中化

如果应用跑在 systemd 管理的服务里，日志管理的思路可以再往上一层。

写入 systemd journal（推荐）

把日志直接交给 journald，好处是显而易见的：所有日志统一采集，可以按服务或单元检索，还能利用结构化字段做更精细的过滤。怎么操作？看这个示例：

import logging
from logging.handlers import SysLogHandler

logger = logging.getLogger("myapp")
logger.setLevel(logging.INFO)
handler = SysLogHandler(address="/dev/log", facility=SysLogHandler.LOG_LOCAL0)
handler.setFormatter(logging.Formatter("%(name)s[%(process)d]: %(levelname)s %(message)s"))
logger.addHandler(handler)

logger.info("通过 journal 写入的日志")

查看日志也很方便：

• 实时查看：journalctl -u myapp.service -f
• 按时间过滤：journalctl --since "2025-11-23 00:00:00"

写入 syslog（传统方案）

如果你的环境里已经有了成熟的 rsyslog 流程，也可以把日志发送到 syslog，由 rsyslog 统一负责落盘和转发。

集中式日志

规模不大的时候，rsyslog 加文件收集就够用。一旦服务数量上来，建议上 ELK 或 Graylog 这类平台，做检索、告警和可视化会轻松很多。

三、日志轮转与保留策略

日志不能无限增长，轮转策略需要从一开始就规划好。通常有两种思路：

应用内轮转（推荐优先）

用 RotatingFileHandler 按大小轮转，或者用 TimedRotatingFileHandler 按时间轮转。下面是一个按天轮转、保留 7 天的例子：

from logging.handlers import TimedRotatingFileHandler
fh = TimedRotatingFileHandler("/var/log/myapp/app.log", when="midnight", interval=1, backupCount=7, encoding="utf-8")

系统级轮转

也可以交给 logrotate 来管理。创建一个 /etc/logrotate.d/myapp 配置文件：

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0644 myapp myapp
    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

测试配置用 logrotate --debug /etc/logrotate.d/myapp，强制执行用 logrotate -f /etc/logrotate.d/myapp。

选择建议

应用内轮转更贴近业务语义——比如按文件大小或按一天切割；系统级轮转则便于统一运维策略，比如压缩、保留时长和归档。两者并不冲突，甚至可以结合使用。

四、结构化日志与第三方库

当你的日志需要被集中式平台消费时，结构化格式就很有必要了。

结构化日志（JSON）

JSON 格式的日志在 ELK 或 Graylog 里做检索和可视化非常方便。可以用 python-json-logger 来实现：

import logging
from pythonjsonlogger import jsonlogger

logger = logging.getLogger("myapp.json")
handler = logging.StreamHandler()
fmt = jsonlogger.JsonFormatter("%(asctime)s %(levelname)s %(name)s %(funcName)s %(lineno)d %(message)s")
handler.setFormatter(fmt)
logger.addHandler(handler)
logger.setLevel(logging.INFO)

logger.info("用户登录", extra={"user": "alice", "ip": "192.0.2.10"})

第三方库选择

• Loguru：样板代码少，自带自动轮转、异常捕获装饰器，还能轻松输出 JSON 或彩色日志。一个例子就够说明问题：

from loguru import logger
logger.add("app.log", rotation="10 MB", retention="7 days", compression="zip", format="{time} {level} {message}")
logger.info("使用 Loguru 写入日志")

• Structlog：面向事件和上下文的日志库，特别适合微服务场景下的链路追踪和复杂系统。

五、生产落地清单

最后，把经验总结成一份清单，供参考：

• 目录与权限：日志目录 /var/log/myapp/，属主设为 myapp:myapp，目录权限 0755，文件权限 0644。确保服务账号有写入权限。
• 服务化与标准输出：用 systemd 管理服务时，优先把日志打到 stdout/stderr，由 journald 统一采集。文件日志作为补充或审计用途。
• 级别与环境：开发环境用 DEBUG，预发用 INFO，生产环境用 WARNING/ERROR。通过环境变量或配置文件切换，千万不要硬编码。
• 安全与合规：日志里绝对不要出现密码、密钥或卡号。必要时做脱敏处理，或者加一层过滤器。
• 监控与告警：对 ERROR 和 CRITICAL 级别的日志建立告警，可以对接 Sentry、企业微信/钉钉机器人或邮件。
• 保留与归档：明确日志的保留周期（比如 14 天或 30 天），并制定归档策略，满足审计和合规要求。

这套体系从基础搭建到生产落地，是经过多次实战检验的。希望能帮你少踩一些坑。