在 Ubuntu 里排查 Python 程序问题，第一步往往不是改代码，而是先把日志看对。很多人卡在“日志在哪、该用什么命令、文件变大后怎么处理”这几个环节，本文就按实际使用顺序，把文件查看、systemd 日志、logrotate 轮转和 Python 自身配置串起来讲清楚，让你能更快判断该从哪条路径下手。
先判断日志写到了哪里
在 Ubuntu 中查看 Python 日志，最关键的是先分辨程序的输出方式。不同部署方式，对应的查看入口并不一样。
如果你的 Python 程序通过 logging 模块写入了日志文件，或者启动时用了重定向，比如追加到 app.log，那么最直接的办法就是去看对应文件。
如果程序是以 systemd 服务方式运行，例如通过 systemctl start your_service 启动，那么日志通常会进入 systemd 的日志系统，这时就更适合用 journalctl。
有时候连日志路径都不确定，可以先从进程信息入手，看看 Python 是怎么启动的，再反推日志文件位置或服务名：
ps aux | grep python
这一步虽然简单，但很实用。先确认日志来源，后面的查看命令才不会用错方向。
查看日志文件时，常用的 3 个命令
如果日志已经落到了文件里，命令行工具就是最省事的查看方式。根据你的目标不同，通常会在实时跟踪、分页浏览和关键词筛选之间切换。
实时跟踪：tail -f
调试运行中的程序时，最常用的是 tail -f。它会持续输出日志文件新增内容，适合边跑程序边观察状态变化。退出时按 Ctrl+C 即可。
tail -f /path/to/your/logfile.log
如果你正在排查接口报错、定时任务执行结果或者后台消费进程异常，这个命令通常是第一选择。
大文件浏览：less 或 more
当日志文件已经比较大，不适合直接整段输出时，可以用 less 或 more 分页查看，其中 less 更常用，因为它支持翻页和搜索。
less /path/to/your/logfile.log
在 less 中，按空格可以翻页，输入 /keyword 可以搜索关键词。对于需要回溯前后文的排错场景，这比单纯 cat 更高效。
筛选关键信息：grep
如果你只关心错误、警告或某个请求 ID，对整份日志逐行看并不划算。这时可以用 grep 快速过滤。
grep "ERROR" /path/to/your/logfile.log
grep -i "warning" /path/to/your/logfile.log
grep "ERROR" 适合直接找错误行，grep -i "warning" 则会忽略大小写搜索告警信息。对于先缩小范围、再深入分析的场景，效率很高。
作为 systemd 服务运行时，直接看 journalctl
如果 Python 程序不是手工在终端里运行，而是注册成了 systemd 服务，那么优先使用 journalctl。这类日志不一定会单独落成你熟悉的 .log 文件，直接查服务日志通常更准确。
常用命令如下：
journalctl -u your_service_name # 查看指定服务的日志
journalctl -u your_service_name -f # 实时跟踪
journalctl -u your_service_name --since "2025-09-27" # 查看指定时间后的日志
这组命令覆盖了三个高频需求：
- 查看某个服务的历史日志；
- 像
tail -f一样实时观察输出； - 按时间范围缩小排查区间。
如果服务在某天之后开始异常，--since "2025-09-27" 这样的时间过滤会比全量翻日志更省时间。对长期运行的后台服务来说，这往往是比手找日志文件更稳妥的入口。
日志太大时，用 logrotate 做轮转
日志能看只是第一步，能长期管理才不会给系统带来新问题。Python 程序持续运行后，日志文件很容易越积越大，占用磁盘空间，甚至影响服务稳定性。Ubuntu 下常用的解决方案是 logrotate。
如果系统里还没有安装，可以先执行：
sudo apt-get install logrotate
然后在 /etc/logrotate.d/ 目录下创建轮转配置文件，例如 python_logs，把目标日志纳入管理：
/path/to/your/logfile.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
}
这份配置表达的意思很直接：
daily：每天切割一次；rotate 7：保留最近 7 份旧日志；compress：压缩旧日志文件；missingok：日志不存在时不报错；notifempty：空日志不轮转；copytruncate：先复制再清空原文件，避免程序因文件轮转而必须重启。
其中 copytruncate 对很多还在持续写入日志的 Python 程序尤其重要。它不是最复杂的方案，但在不改应用写日志方式的前提下，通常足够实用。
配置写完后，可以手动触发一次，确认规则是否生效：
sudo logrotate -f /etc/logrotate.d/python_logs
这一步适合上线前检查，避免等到日志膨胀后才发现配置没起作用。
从源头优化：把 Python 日志写规范
想让日志真正好查，最后还是要回到程序本身。与其事后想办法“翻日志”，不如一开始就把日志输出得更清楚。Python 标准库里的 logging 模块已经能满足大多数基础需求。
下面是一份基础配置示例，把日志写入文件，并带上时间、级别和消息内容：
import logging
logging.basicConfig(
filename='/path/to/your/logfile.log',
level=logging.INFO,
format='%(asctime)s - %(levelname)s - %(message)s',
datefmt='%Y-%m-%d %H:%M:%S'
)
logging.info("程序启动成功")
logging.error("发生错误：无法连接数据库")
这里保留了几个最有用的字段：
- 日志文件路径：明确输出位置，便于后续用命令查看；
level=logging.INFO：控制记录级别；format：统一日志格式，便于人工阅读和后续检索；datefmt='%Y-%m-%d %H:%M:%S'：让时间信息更直观。
脚本运行后，日志会按指定格式写入文件，之后就可以配合前面的 tail -f、less 和 grep 使用。对排查问题来说，规范日志格式的价值通常比单次查看命令更大，因为它决定了日志后续是不是可读、可搜、可维护。
实际使用中的两个提醒
第一，如果你暂时不知道日志文件路径，不要盲目全盘搜索，先用下面的命令看 Python 进程启动参数：
ps aux | grep python
很多时候，启动命令里就会带出配置文件、重定向路径或服务入口信息，能帮助你更快定位。
第二，如果已经进入生产环境，单机日志查看只适合做基础排查。日志量一大，最好还是考虑集中式方案，例如远程日志服务器、ELK Stack 或 Fluentd。这类工具的优势不在“替代命令行”，而在于集中管理、统一检索和更强的分析能力。
简单总结就是：文件日志用 tail -f、less、grep；systemd 服务优先用 journalctl；日志持续增长时交给 logrotate；想长期省事，就把 Python 的 logging 先配置规范。按这个顺序处理，Ubuntu 里的 Python 日志基本都能找到合适入口。
