Python在Debian中的日志如何配置

在Debian系统上配置Python日志，说简单也简单，说复杂也有不少坑。核心思路是：用好内置的logging模块，它能覆盖从开发调试到生产监控的绝大多数场景。下面把常见的配置方式、轮转策略、甚至系统日志集成都过一遍，省得以后反复查文档。

Python在Debian中的日志配置指南

Debian系统一般预装Python 3，logging模块是标准库的一部分，开箱即用。如果你想要更简洁的API，可以考虑第三方库Loguru——不过那是后话，先把基本功练扎实。

1. 基础环境准备

先确认Python版本：python3 --version。如果还没安装pip，用sudo apt install python3-pip搞定。Loguru（可选）通过pip3 install loguru安装，不过下面我们先从标准模块开始。

sudo apt update
sudo apt install python3 python3-pip
# 确保Python及pip已安装
pip3 install loguru  # 可选：安装Loguru（第三方日志库）

2. 基础代码配置（推荐入门）

最直接的方式是用basicConfig快速设置日志级别、格式和输出。注意一点：basicConfig只能调用一次，之后想改就得用更高级的Handler了。

import logging

logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    filename='app.log',
    filemode='a'  # 'a'追加，'w'覆盖
)

logger = logging.getLogger(__name__)

logger.debug('Debug message: 程序启动')
logger.info('Info message: 用户登录成功')
logger.warning('Warning message: 磁盘空间不足')
logger.error('Error message: 数据库连接失败')
logger.critical('Critical message: 服务崩溃')

运行后日志会写入app.log，格式类似：2025-10-08 14:30:00 - __main__ - INFO - Info message: 用户登录成功。对于小项目，这样足够用了。

3. 高级配置：日志轮转（避免文件过大）

生产环境中日志文件如果不控制大小，几个月就能把磁盘撑爆。有两种常见的轮转策略：按大小轮转和按时间轮转。轮转后旧文件会自动重命名（比如app_rotating.log.1），不会丢失历史记录。

3.1 按大小轮转（RotatingFileHandler）

比如设置每个日志文件最大10MB，保留5个备份。超过10MB时新日志写入.1文件，旧文件依次递增。

import logging
from logging.handlers import RotatingFileHandler

logger = logging.getLogger(__name__)
logger.setLevel(logging.DEBUG)

handler = RotatingFileHandler(
    'app_rotating.log',
    maxBytes=10*1024*1024,  # 10MB
    backupCount=5
)
handler.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)

# 测试：写10000条日志，超过10MB会自动轮转
for i in range(10000):
    logger.info(f'Log entry {i}')

3.2 按时间轮转（TimedRotatingFileHandler）

如果希望每天午夜自动分割日志，并保留7天，用这个：

from logging.handlers import TimedRotatingFileHandler

handler = TimedRotatingFileHandler(
    'app_timed.log',
    when='midnight',  # 每天午夜分割
    interval=1,
    backupCount=7  # 保留7天
)
handler.setLevel(logging.DEBUG)
handler.setFormatter(formatter)
logger.addHandler(handler)

4. 配置文件方式（推荐生产环境）

把日志配置从代码里抽出来，放到logging.conf中，这样改日志策略不用改代码，运维更方便。下面是一个简单示例：

[loggers]
keys=root

[handlers]
keys=fileHandler

[formatters]
keys=simpleFormatter

[logger_root]
level=DEBUG
handlers=fileHandler

[handler_fileHandler]
class=FileHandler
level=DEBUG
formatter=simpleFormatter
args=('app_config.log', 'a')

[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=%Y-%m-%d %H:%M:%S

代码中加载：

import logging
import logging.config

logging.config.fileConfig('logging.conf')
logger = logging.getLogger(__name__)
logger.info('This is an info message from config file')

如果项目需要多个Logger或不同的Handler，配置文件比代码要清晰得多。具体细节可以查Python官方文档，这里不展开了。

5. 集成系统日志（syslog）

有些场景下希望Python日志直接写入系统日志（比如/var/log/syslog），便于统一监控。用SysLogHandler就行：

import logging
from logging.handlers import SysLogHandler

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

handler = SysLogHandler(address='/dev/log')  # Debian默认syslog socket
handler.setLevel(logging.INFO)
formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)

logger.info('System log message: User logged in')

之后用tail -f /var/log/syslog就能实时看到。

6. 日志文件权限管理

日志文件如果权限不对，程序可能写不进去。简单的做法是创建文件后修改所有者和权限：

touch app.log
sudo chown $USER:$USER app.log
sudo chmod 664 app.log  # 用户可读写，组可读，其他可读

如果是多用户环境，建议把日志文件放在专门的目录（如/var/log/myapp/），并设置合适的组权限。

7. 第三方库：Loguru（简化配置）

如果厌倦了手动配置Handler和Formatter，Loguru是个不错的选择。它把常见需求封装成一行配置：

from loguru import logger

# 输出到文件，10MB轮转；同时控制台输出INFO及以上
logger.add("file_loguru.log", rotation="10 MB", level="DEBUG")
logger.add(sys.stdout, level="INFO")

logger.debug('Debug message (only to file)')
logger.info('Info message (to file and console)')
logger.error('Error message (to file and console)')

注意：Loguru和标准logging模块的互操作性需要额外处理，但大部分场景下直接用Loguru就能满足。

最后总结一下：中小项目用basicConfig快速起步，生产环境用配置文件+轮转Handler，需要统一监控就集成syslog。至于Loguru，适合追求开发效率的团队。无论哪种方式，先跑起来，再根据实际需求调整就好。