linux服务器处理应用日志主流方案

1 日志轮转（Logrotate）—— 最标准、最推荐

这是 Linux 系统自带的日志切割工具，几乎所有生产环境都在用。
核心能力：
按大小或时间自动切割日志
自动压缩（gzip）旧日志
自动删除超期日志
切割后自动重启应用（避免日志句柄不释放）

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily                   # 每天切割一次
    missingok               # 日志文件不存在时不报错
    rotate 30               # 保留最近30天的日志
    compress                # 切割后自动压缩旧日志
    delaycompress           # 延迟压缩，避免影响正在写入的日志
    notifempty              # 空日志不切割
    create 0644 appuser appgroup  # 新建日志文件的权限和属主
    sharedscripts           # 所有日志文件切割完成后执行一次脚本
    postrotate
        # 切割后通知应用重新打开日志文件
        systemctl reload myapp.service || true
    endscript
}

优点：配置一次，终身省心，完全自动化。

2 集中式日志平台（ELK/ClickHouse/Loki）—— 大型分布式系统首选

当你的应用部署在多台服务器上，或者日志量非常大时，就需要把日志统一收集、存储和分析。
主流方案：
ELK Stack：Elasticsearch + Logstash + Kibana
Filebeat（轻量采集器）部署在应用服务器，把日志发送到 Elasticsearch。
Kibana 提供强大的可视化和查询界面。
Grafana Loki + Promtail：
更轻量，适合云原生和容器化环境，和 Grafana 生态无缝集成。
ClickHouse + Fluentd：
适合超大数据量、高写入吞吐量的场景。
工作流程：
采集器（Filebeat/Promtail/Fluentd）实时读取应用日志。
发送到中央存储（Elasticsearch/Loki/ClickHouse）。
应用服务器本地只保留最近几天的日志，或直接不保留，全部上传。
优点：
彻底解决单台服务器的磁盘压力。
支持多维度查询、告警和可视化。

3 简单脚本定时清理 —— 适合小项目或临时场景

如果你的应用比较简单，不想引入复杂的工具，可以写个简单的 Shell 脚本，配合 cron 定时任务来清理

#!/bin/bash
# 清理7天前的日志，并压缩3天前的日志
LOG_DIR="/var/log/myapp"

# 压缩3天前的.log文件
find $LOG_DIR -name "*.log" -mtime +3 -exec gzip {} \;

# 删除7天前的.gz压缩包
find $LOG_DIR -name "*.gz" -mtime +7 -delete

crontab -e
# 每天凌晨2点执行清理脚本
0 2 * * * /path/to/clean_logs.sh

注意：这种方式需要手动处理日志句柄问题，否则应用可能还在往已经被删除的日志文件里写数据。

4 关键注意事项

日志句柄问题：
当你直接删除或移动正在被应用写入的日志文件时，应用并不会感知到，它会继续向一个已删除的文件句柄写入数据，导致磁盘空间无法释放。
解决方法：使用 logrotate 的 postrotate 脚本，在切割后通知应用（如 kill -HUP 或 systemctl reload）重新打开日志文件。
日志级别控制：
从源头减少日志量是最好的办法。在应用配置中，将日志级别从 DEBUG 调整到 INFO 或 WARN，只记录关键信息。
监控告警：
配置磁盘使用率监控，当 /var/log 分区使用率超过阈值（如 85%）时，及时收到告警，避免服务中断。

5

单服务器、中小规模应用：首选 Logrotate，配置简单，稳定可靠。
多服务器、大规模微服务：首选 集中式日志平台（如 Loki + Grafana 或 ELK），彻底解放运维压力。
临时、测试环境：可以用 脚本 + cron 的方式快速解决。