1. 为什么我们需要告别print调试记得刚开始学Python的时候我最喜欢用的调试方法就是print。每次遇到问题第一反应就是在代码里插入一堆print语句看看变量值对不对程序执行到哪一步了。这种方法在小项目或者快速验证某个想法时确实很方便但随着项目规模扩大print调试的弊端就越来越明显。去年我接手一个机器学习项目训练过程中需要监控各种指标。最初我像往常一样用print输出损失值和准确率结果训练了不到半小时控制台就被刷屏了。更糟的是当我想回溯某个时间点的训练状态时发现print输出的信息早已淹没在茫茫日志中。这时候我才意识到print调试就像用螺丝刀当锤子使 - 虽然能凑合用但绝对不是最佳工具。Python的logging模块提供了更专业的解决方案。它不仅支持多级别日志DEBUG、INFO、WARNING等还能将日志输出到不同目的地控制台、文件、网络等。举个例子在模型训练时我们可以这样配置import logging # 基础配置 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, filenametraining.log ) # 训练循环中 for epoch in range(epochs): train_loss train_one_epoch(model, train_loader) val_loss validate(model, val_loader) logging.info(fEpoch {epoch}: train_loss{train_loss:.4f}, val_loss{val_loss:.4f})这样配置后所有日志都会自动记录到文件中包含时间戳和日志级别而且不会污染控制台输出。当我们需要排查问题时只需打开日志文件就能清晰看到训练过程中的每个状态变化。2. logging模块的核心概念2.1 日志级别从DEBUG到CRITICALlogging模块定义了5个标准日志级别按严重程度递增排列级别数值使用场景DEBUG10详细的调试信息INFO20确认程序按预期运行WARNING30表明可能出现问题ERROR40严重问题某些功能失效CRITICAL50严重错误程序可能无法继续运行理解这些级别的区别很重要。在实际项目中我通常会这样设置开发阶段设置为DEBUG获取尽可能多的信息测试环境设置为INFO关注程序运行状态生产环境设置为WARNING或ERROR只记录重要问题# 设置日志级别 logging.basicConfig(levellogging.DEBUG) # 开发环境 # logging.basicConfig(levellogging.INFO) # 测试环境 # logging.basicConfig(levellogging.WARNING) # 生产环境2.2 Logger、Handler和Formatter的三重奏logging模块的核心是三个组件的协作Logger负责产生日志消息。每个logger都有一个名称通常使用模块名__name__来创建形成层级结构。Handler决定日志的去向。可以是控制台StreamHandler、文件FileHandler、邮件SMTPHandler等。Formatter控制日志的显示格式。可以包含时间、模块名、行号等信息。下面是一个典型配置示例import logging # 创建logger logger logging.getLogger(__name__) logger.setLevel(logging.DEBUG) # 创建控制台handler并设置级别 console_handler logging.StreamHandler() console_handler.setLevel(logging.WARNING) # 创建文件handler并设置级别 file_handler logging.FileHandler(app.log) file_handler.setLevel(logging.DEBUG) # 创建formatter并添加到handler formatter logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s) console_handler.setFormatter(formatter) file_handler.setFormatter(formatter) # 将handler添加到logger logger.addHandler(console_handler) logger.addHandler(file_handler) # 使用示例 logger.debug(调试信息) # 只写入文件 logger.warning(警告信息) # 同时输出到控制台和文件这种配置下DEBUG及以上级别的日志会写入文件而WARNING及以上级别的日志会同时显示在控制台。这种灵活性是print无法比拟的。3. 实战在不同场景下的logging应用3.1 Web服务中的日志管理在开发Flask或Django应用时良好的日志实践能极大简化问题排查。我曾经遇到一个线上问题用户反映某个API偶尔返回500错误但开发环境无法复现。幸亏我们配置了完善的日志系统最终通过分析日志锁定了问题。以下是一个Flask应用的日志配置示例from flask import Flask import logging from logging.handlers import RotatingFileHandler app Flask(__name__) # 配置日志 def setup_logging(): # 禁用Flask默认的logger app.logger.handlers.clear() # 设置日志格式 formatter logging.Formatter( %(asctime)s %(levelname)s: %(message)s [in %(pathname)s:%(lineno)d] ) # 文件handler - 按大小轮转 file_handler RotatingFileHandler( flask_app.log, maxBytes1024*1024, backupCount10 ) file_handler.setLevel(logging.INFO) file_handler.setFormatter(formatter) # 控制台handler console_handler logging.StreamHandler() console_handler.setLevel(logging.DEBUG) console_handler.setFormatter(formatter) # 添加到app logger app.logger.addHandler(file_handler) app.logger.addHandler(console_handler) app.logger.setLevel(logging.DEBUG) setup_logging() app.route(/) def hello(): app.logger.info(访问首页) try: # 业务逻辑 return Hello World! except Exception as e: app.logger.error(处理请求时出错: %s, str(e), exc_infoTrue) return 服务器错误, 500关键点说明使用RotatingFileHandler实现日志轮转避免单个文件过大记录异常时使用exc_infoTrue会自动包含堆栈信息在日志中包含文件名和行号方便定位问题3.2 数据处理与模型训练日志在数据分析和机器学习项目中日志能帮助我们追踪数据处理流程和模型训练过程。我曾经参与的一个计算机视觉项目就因为完善的日志记录快速定位了一个由数据预处理不一致导致的问题。以下是一个PyTorch模型训练的日志配置示例import logging from logging.handlers import TimedRotatingFileHandler def setup_train_logger(): logger logging.getLogger(model_trainer) logger.setLevel(logging.DEBUG) # 按天轮转的日志文件 file_handler TimedRotatingFileHandler( training.log, whenmidnight, interval1, backupCount7 ) file_handler.setLevel(logging.INFO) # 控制台输出 console_handler logging.StreamHandler() console_handler.setLevel(logging.WARNING) # 详细格式 detailed_formatter logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(message)s ) simple_formatter logging.Formatter(%(levelname)s: %(message)s) file_handler.setFormatter(detailed_formatter) console_handler.setFormatter(simple_formatter) logger.addHandler(file_handler) logger.addHandler(console_handler) return logger train_logger setup_train_logger() # 在训练循环中使用 for epoch in range(epochs): train_loss train_one_epoch(model, train_loader) val_loss validate(model, val_loader) train_logger.info( fEpoch {epoch:03d}: fTrain Loss: {train_loss:.4f}, fVal Loss: {val_loss:.4f} ) if val_loss best_loss: train_logger.debug(发现新的最佳模型保存中...) best_loss val_loss torch.save(model.state_dict(), best_model.pth)这种配置下每天的日志会单独保存最多保留7天控制台只显示重要警告和错误文件日志包含详细的时间戳和上下文信息关键训练指标被系统化记录便于后续分析4. 高级技巧与最佳实践4.1 使用字典配置实现灵活日志管理随着项目复杂度增加直接在代码中配置logging会变得难以维护。Python支持通过字典配置logging这种方式更加灵活且易于管理。以下是一个使用字典配置的示例import logging.config LOGGING_CONFIG { version: 1, disable_existing_loggers: False, formatters: { standard: { format: %(asctime)s [%(levelname)s] %(name)s: %(message)s, datefmt: %Y-%m-%d %H:%M:%S }, detailed: { format: %(asctime)s [%(levelname)s] %(name)s (%(filename)s:%(lineno)d): %(message)s } }, handlers: { console: { class: logging.StreamHandler, level: INFO, formatter: standard, stream: ext://sys.stdout }, file: { class: logging.handlers.RotatingFileHandler, level: DEBUG, formatter: detailed, filename: app_debug.log, maxBytes: 1048576, backupCount: 5 }, error_file: { class: logging.FileHandler, level: WARNING, formatter: detailed, filename: app_errors.log } }, loggers: { : { # root logger handlers: [console, file, error_file], level: DEBUG, propagate: False }, data: { handlers: [file], level: INFO, propagate: False }, api: { handlers: [console, error_file], level: DEBUG, propagate: False } } } # 应用配置 logging.config.dictConfig(LOGGING_CONFIG) # 使用示例 data_logger logging.getLogger(data) api_logger logging.getLogger(api) data_logger.info(开始数据处理) api_logger.debug(API请求接收: %s, request_path)这种配置方式的优势在于配置与代码分离便于维护可以为不同模块设置不同的日志策略支持多种handler和formatter组合配置可以保存为JSON或YAML文件实现动态加载4.2 结构化日志与日志分析随着系统规模扩大简单的文本日志变得越来越难以分析。结构化日志如JSON格式更适合现代日志分析系统。以下是使用Python的logging模块输出JSON格式日志的示例import logging import json from datetime import datetime class JsonFormatter(logging.Formatter): def format(self, record): log_record { timestamp: datetime.utcnow().isoformat(), level: record.levelname, logger: record.name, message: record.getMessage(), module: record.module, function: record.funcName, line: record.lineno, thread: record.threadName, } if record.exc_info: log_record[exception] self.formatException(record.exc_info) return json.dumps(log_record) # 配置logger logger logging.getLogger(json_logger) logger.setLevel(logging.DEBUG) handler logging.StreamHandler() handler.setFormatter(JsonFormatter()) logger.addHandler(handler) # 使用示例 logger.info(用户登录, extra{ user: user123, ip: 192.168.1.1, action: login })输出结果示例{ timestamp: 2023-05-15T14:30:00.123456, level: INFO, logger: json_logger, message: 用户登录, module: auth, function: handle_login, line: 42, thread: MainThread, user: user123, ip: 192.168.1.1, action: login }结构化日志的优势易于被日志系统如ELK、Splunk解析支持丰富的字段查询和过滤便于生成统计报表和可视化与微服务架构更契合4.3 性能考量与线程安全logging模块在设计时就考虑了线程安全但在高并发场景下仍需注意一些性能问题避免同步写入频繁的磁盘I/O可能成为性能瓶颈。可以考虑使用QueueHandler和QueueListener实现异步日志记录。import logging import logging.handlers from queue import Queue import threading # 创建队列 log_queue Queue() queue_handler logging.handlers.QueueHandler(log_queue) # 配置主logger root_logger logging.getLogger() root_logger.addHandler(queue_handler) root_logger.setLevel(logging.DEBUG) # 创建实际的日志处理器 file_handler logging.FileHandler(async.log) formatter logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s) file_handler.setFormatter(formatter) # 创建队列监听器 listener logging.handlers.QueueListener(log_queue, file_handler) listener.start() # 在多线程环境中使用 def worker(): logging.info(来自工作线程的消息) threads [] for i in range(5): t threading.Thread(targetworker) threads.append(t) t.start() for t in threads: t.join() listener.stop()合理设置日志级别生产环境中避免记录过多DEBUG日志特别是高频调用的代码路径。使用适当的Handler对于高性能场景可以考虑使用SysLogHandler或直接写入syslog。避免昂贵的日志消息构建使用延迟求值方式构建复杂日志消息# 不推荐 - 无论是否记录都会执行字符串格式化 logger.debug(f耗时操作结果: {expensive_operation()}) # 推荐 - 只有在需要记录时才执行字符串格式化 logger.debug(耗时操作结果: %s, expensive_operation())5. 常见问题与解决方案5.1 日志不显示或显示不全这是初学者最常见的问题之一。通常原因包括日志级别设置过高确保logger和handler的级别设置正确未添加handler创建logger后需要添加至少一个handlerbasicConfig已被调用logging.basicConfig()只能调用一次且必须在添加其他handler之前解决方案示例import logging # 正确配置方式 logging.basicConfig(levellogging.DEBUG) # 必须在其他配置前调用 logger logging.getLogger(__name__) logger.setLevel(logging.DEBUG) # 设置logger级别 handler logging.StreamHandler() handler.setLevel(logging.DEBUG) # 设置handler级别 formatter logging.Formatter(%(message)s) handler.setFormatter(formatter) logger.addHandler(handler) # 添加handler logger.debug(这条消息应该会显示)5.2 日志重复输出有时会发现同一条日志被重复记录多次这通常是因为多次添加handler确保不要重复添加相同的handlerlogger层级问题子logger的日志可能会传播到父logger解决方案# 防止重复添加handler if not logger.handlers: logger.addHandler(handler) # 关闭传播 logger.propagate False5.3 在多模块中使用logging在大型项目中如何在多个模块中正确使用logging是一个常见问题。最佳实践是在每个模块中使用__name__创建logger在主模块中配置logging子模块继承主模块的配置示例# main.py import logging import module1 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s ) module1.do_something() # module1.py import logging logger logging.getLogger(__name__) def do_something(): logger.info(这是在module1中记录的消息)5.4 处理Unicode和异常记录包含非ASCII字符的消息或异常时可能会遇到编码问题。正确处理方式try: # 可能抛出异常的代码 result operation_that_may_fail() except Exception as e: logger.error(操作失败: %s, str(e), exc_infoTrue) # 或者使用 logger.exception(操作失败) # 自动包含异常信息对于非ASCII字符确保文件handler使用正确的编码handler logging.FileHandler(app.log, encodingutf-8)6. 从项目实战中学到的经验在多年的开发经历中我总结出一些logging的最佳实践尽早引入logging不要等到项目复杂了才开始加日志从一开始就规划好日志策略合理使用日志级别DEBUG详细的调试信息通常只在开发时开启INFO记录程序正常运行的关键节点WARNING记录意外情况但程序仍能继续运行ERROR记录错误情况某些功能不可用CRITICAL记录严重错误程序可能崩溃包含足够的上下文信息每条日志都应该包含足够的信息以便事后分析比如# 不好 logger.error(文件处理失败) # 好 logger.error(文件处理失败: 文件%s, 用户%s, 大小%d, filename, user_id, file_size)使用轮转日志文件避免单个日志文件过大使用RotatingFileHandler或TimedRotatingFileHandler生产环境考虑集中式日志对于分布式系统考虑使用ELK、Splunk等集中式日志解决方案定期审查日志配置随着项目演进定期评估日志配置是否仍然满足需求平衡日志量和性能过多的日志会影响性能找到适合项目的平衡点保护敏感信息确保日志中不会记录密码、密钥等敏感信息一个真实案例在一次系统升级后我们突然发现数据库连接偶尔会失败。通过分析日志我们发现错误信息是连接超时但没有更多上下文。后来我们改进了日志记录包含了连接参数去掉密码和重试次数最终发现是网络配置问题。这个经历让我深刻体会到良好日志记录的价值。