在服务器上保存运行日志，核心做法是把进程的标准输出（stdout）和标准错误（stderr）通过重定向符号写入指定文件，再用追加模式保证多次运行不覆盖旧记录。这套操作在Linux和Windows的PowerShell里都有对应实现，配合nohup、tee、logrotate等工具，能做到随时可查、过期自动清理,下面从命令细节到实际场景逐一拆解。
服务器日志怎么看：先分清stdout和stderr再动手
很多新手在服务器上跑程序时，只看到屏幕上滚动的输出，却不知道这些内容其实走了两条不同的通道。stdout（标准输出） 是程序正常打印的结果，stderr（标准错误） 是报错信息，这两条通道可以分别重定向,也可以合并写进同一个文件。
保存日志的基础命令格式
在Linux终端里,把运行输出保存到log的最简单写法是：
python app.py > app.log
这条命令把stdout写入app.log，如果文件不存在就创建，存在则直接覆盖，但报错信息（stderr）仍然会出现在屏幕上，不会进文件。如果你想让报错也落盘，必须显式重定向stderr：
python app.py > app.log 2>&1
2>&1 的含义是把文件描述符2（stderr）指向文件描述符1（stdout）当前的位置，多数情况下，运维日志推荐全量重定向，即 > app.log 2>&1 合并保存,排查问题时只需要打开一个文件。
为什么只重定向stdout时报错信息会丢
举一个实际例子，你运行一个Python爬虫，代码里用print输出进度，用logging.error输出失败请求，如果只写 python crawl.py > run.log，进度全在文件里，但错误信息直接甩到终端，一旦你关闭SSH窗口，这些报错就永久消失了，行业共识认为，stderr是排查故障的第一手线索,丢失stderr等于丢了一半日志价值。
服务器日志保存到本地：用重定向命令写文件
弄懂双通道后，接下来解决“怎么把运行的部分保存到log”的具体操作，这里的核心痛点是两个：如何防止SSH断开导致进程被杀，以及如何让多次运行的日志不互相覆盖。
覆盖写与追加写的区别
> 是覆盖写，>> 是追加写,假设你的服务每天凌晨跑一次数据同步：
# 错误用法：每次运行都覆盖前一天的日志 ./sync_data > sync.log 2>&1 # 正确用法：日志不断累积，方便回溯历史 ./sync_data >> sync.log 2>&1
如果服务频繁启动，比如Nginx在reload时，覆盖写会让每次重载前的错误信息全部丢失。追加模式是日志保存的底线操作，配合日期分割,才能形成完整的时间线。
解决SSH断开后日志中断：nohup与setsid
直接在终端里跑 python app.py >> app.log 2>&1 有个致命问题：关掉SSH窗口，进程收到SIGHUP信号就死了，这时必须用nohup来忽略挂断信号，再加&放到后台：
nohup python app.py >> app.log 2>&1 &
这条命令是服务器后台运行程序的经典组合，nohup有一个特性：如果不手动指定输出文件，默认会把输出写入当前目录的nohup.out文件，所以显式重定向到log文件，既能控制文件名，也能避免nohup.out越积越大。
另一类场景是使用systemd管理的服务，比如Docker容器或自定义的service文件，这类进程由systemd托管，用 journalctl -u 服务名 就能查看日志，但如果你用重定向方式启动过临时任务,nohup仍然是最直接的方案。
实时查看和统计日志内容
日志文件写好了，接下来的需求是“怎么看”,最常用的几个命令：
# 实时跟踪末尾更新的内容，Ctrl+C退出 tail -f app.log # 只看最后100行，适合快速判断最近状态 tail -100 app.log # 统计总行数，判断日志量级 wc -l app.log # 按关键词过滤，比如只提取ERROR级别 grep "ERROR" app.log
相当一部分运维事故排查，就是从 tail -f 盯日志开始的，如果你用宝塔面板管理服务器，可以直接在面板的“日志”菜单里查看,也可以进入文件管理目录找到log文件在线预览。
服务器日志清理：logrotate自动轮转
日志无限累积会撑爆磁盘，这是一定会遇到的问题，服务器上的log文件如果长期不处理，几个月就能膨胀到几十GB，解决办法是logrotateLinux自带的日志轮转工具，按天、按大小切割旧日志,并可以自动压缩。
logrotate配置示例
在 /etc/logrotate.d/ 目录下新建一个配置文件,以应用名命名：
/applogs/app.log {
daily
rotate 30
compress
missingok
notifempty
copytruncate
}
参数含义：
daily：每天轮转一次。rotate 30：保留最近30个历史文件,更早自动删除。
compress
missingok：文件不存在时跳过,不报错。notifempty：日志为空时不轮转,避免产生大量空文件。copytruncate：先复制内容到历史文件再清空原文件，对正在写入的进程最友好。
配置好后，用 logrotate -d /etc/logrotate.d/app 做一次预演验证，多数情况下，logrotate由cron每天自动执行,无需手动干预。
轮转后日志仍然只有一个文件的原因
不少人在配置完logrotate后发现，log文件还是无限增长，根本没有按天切割，这通常是两个原因造成的。第一，cron服务没有运行，logrotate根本不会被触发。第二，copytruncate参数缺失，导致应用进程持有旧文件句柄，写操作全部落进被轮转的历史文件,原文件自然永远不增长。
业内专家指出，配置logrotate后必须检查 /var/lib/logrotate/status 这个状态文件，看最近一次执行时间,否则很难发现静默失败。
日志文件在哪里：常见存放路径判定方法
保存日志是一回事，事后找到日志是另一回事，不同服务有各自的默认路径,按这套规律找基本不会错。
系统级与应用级日志的默认路径
- 系统通用日志：
/var/log/messages（CentOS/RHEL）或/var/log/syslog（Ubuntu/Debian）。 - Nginx访问日志：
/var/log/nginx/access.log，错误日志：/var/log/nginx/error.log。 - MySQL数据库日志：
/var/log/mysql/目录下，包含error.log和慢查询日志。 - 定时任务cron日志：
/var/log/cron。
宝塔面板日志文件位置说明
用宝塔面板运维服务器的用户数量相当大，宝塔的日志路径比较固定。站点访问日志位于 /www/wwwlogs/ 目录，按域名命名，example.com.log，PHP运行日志或Java应用的日志，需要看站点配置文件里填写的绝对路径，宝塔的“日志”菜单支持可视化查看,但深层次的业务日志还是在文件系统里。
systemd服务的日志查询
新一代Linux发行版都用systemd托管服务，日志由journald统一管理,查看某个服务的运行记录：
journalctl -u myservice.service journalctl -u myservice.service --since today journalctl -u myservice.service -f
注意journalctl的日志默认不会持久化，重启服务器后历史就没了，如果确实需要保存，要在
/etc/systemd/journald.conf 里设置 Storage=persistent，然后重启systemd-journald服务。
日志保存的增强方案：时间戳与集中管理
基础日志已经跑通,接下来这两招能显著提升日志的可用性。
给日志文件名加时间戳
如果手动保存多个批处理任务的日志，用固定文件名会把不同批次的输出混在一起,可以通过脚本生成带日期的文件名：
LOG_FILE="backup_$(date +%Y%m%d_%H%M%S).log" python backup.py >> "$LOG_FILE" 2>&1
这样每次运行生成独立文件，不会互相干扰，也可以交给logrotate的 dateext 参数,轮转时自动追加日期后缀。
多台服务器日志统一收集
对于只有一两台服务器的中小项目，建议直接用logrotate加本地文件，简单可靠，只有当服务器数量超过三五台时，才需要引入集中式收集工具，比如ELK或Loki。架构越简单，故障点越少。
日志保存常见问题：服务器上怎么把运行保存到log
服务器日志保存到本地后编码乱码怎么办
程序输出GBK编码，而Linux终端默认UTF-8，写入文件后打开就是乱码，解决方法是在启动命令前指定编码环境变量，LANG=zh_CN.UTF-8 python app.py >> app.log 2>&1，已经乱码的文件可以用 iconv -f GBK -t UTF-8 app.log > app_utf8.log 转换。
重启服务器后nohup运行的进程和日志还在吗
nohup启动的进程会随服务器重启而终止，这是保护机制，不会自动恢复，但log文件本身完整保留在磁盘上，如果使用追加写模式，重新执行 nohup python app.py >> app.log 2>&1 & 后，新日志会接着旧日志尾部继续写入,不会清空历史记录。
日志文件被误删后进程还在写，怎么恢复
进程仍在运行，但log文件已被rm删除时，文件占用空间不会立刻释放，执行 lsof | grep deleted 找到对应进程的删除项，记录第一列进程PID，再执行 ls -l /proc/PID/fd/1 查看文件描述符指向，用 cat /proc/PID/fd/1 > 恢复后的日志路径 重建文件，进程的后续输出会继续写入这个新文件，处理完毕后,改回原来的启动脚本就行。
日志保存的核心思路很清晰：重定向解决去向问题，nohup解决生命周期问题，logrotate解决空间问题，把这三件事做成一套固定动作，服务器的运行记录就能长期稳定地保留下来,排查故障和事后追溯都有了可靠依据。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/592589.html
