Linux日志脚本怎么写，如何自动清理系统日志

构建高效的 Linux 日志管理脚本体系，是保障服务器高可用性与安全审计能力的基石，在复杂的 Linux 运维环境中，系统日志不仅记录了内核状态、服务运行情况，更是故障排查与入侵检测的第一手数据源，单纯依赖系统自带的日志生成机制往往不足以应对生产环境的挑战，通过编写专业的 Shell 脚本实现日志的自动化采集、清洗、轮转与告警，能够极大提升运维效率，降低磁盘 I/O 压力，并确保关键信息的实时可追溯性。

日志脚本化的核心价值与设计原则

Linux 系统产生的日志数据量庞大且增长迅速，若缺乏有效的管理策略，极易导致磁盘空间耗尽（No Space Left on Device），进而引发服务宕机。日志脚本的核心价值在于将被动的数据记录转化为主动的监控与维护能力。

在设计日志脚本时,必须遵循以下三大原则：

1. 原子性：日志操作必须具备原子性，避免在脚本执行过程中因异常中断导致日志损坏或丢失。
2. 低侵入性：脚本自身的运行不应占用过多的系统资源（CPU 和内存），应优先使用系统原生的工具如 awk、sed 而非臃肿的解释器。
3. 标准化输出：脚本处理后的日志应遵循统一的格式（如 JSON 或 CEF），以便于后续对接 ELK（Elasticsearch, Logstash, Kibana）或 Splunk 等日志分析平台。

关键功能模块的实现策略

一个专业的 Linux 日志脚本通常包含日志轮转、异常提取与实时告警三个核心模块。

智能日志轮转与归档

虽然 Linux 提供了 logrotate 工具，但在特定业务场景下，自定义脚本能提供更细粒度的控制，脚本需要根据日志文件的大小或时间维度进行切割，并自动压缩旧日志。

核心逻辑：检测当前日志文件大小，若超过阈值（如 100MB），则将其重命名并打包压缩，随后清空原文件或发送 SIGUSR1 信号给进程重新生成日志。关键在于使用 mv 和 gzip 命令的组合，确保在重命名瞬间不会丢失正在写入的新日志。

基于正则的异常日志提取

海量的日志中,只有极少数包含错误或警告信息，脚本需要利用强大的正则表达式引擎，从 /var/log/messages、/var/log/secure 或应用日志中筛选出关键信息。

实战方案：针对 SSH 暴力破解告警，脚本应监控 /var/log/secure，提取包含 “Failed password” 的行，并统计同一 IP 地址的失败次数。当单位时间内失败次数超过阈值（如 10 次）时，应立即触发防火墙规则（如 iptables 或 firewalld）临时封禁该 IP。 这种主动防御脚本是保障服务器安全的重要手段。

多渠道实时告警机制

发现异常后,脚本必须将信息第一时间推送给运维人员，除了传统的邮件发送，现代运维脚本更倾向于集成企业微信、钉钉或飞书的 Webhook 接口。

技术要点：使用 curl 命令发送 POST 请求，将告警内容封装为 JSON 格式。为了防止告警风暴，脚本中必须加入“去重机制”或“静默期”逻辑，避免同一故障在短时间内重复发送数千条通知，造成运维人员的麻木。

专业级日志脚本实战案例

以下是一个集成了日志分析与安全防护的脚本核心逻辑示例,展示了如何将上述理论转化为实际代码：

#!/bin/bash
# 定义日志路径与阈值
SECURE_LOG="/var/log/secure"
TMP_FILE="/tmp/ssh_fail.tmp"
BLOCK_LIST="/tmp/block_list.txt"
THRESHOLD=10
# 1. 提取最近一小时内 SSH 登录失败的 IP 地址
# 使用 awk 统计频次，sort 排序，uniq 去重并计数
grep "Failed password" $SECURE_LOG | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr > $TMP_FILE
# 2. 遍历统计结果，执行封禁逻辑
while read count ip; do
    # 判断失败次数是否超过阈值
    if [ $count -gt $THRESHOLD ]; then
        # 检查 IP 是否已被封禁，避免重复操作
        if ! iptables -L INPUT -n | grep -q $ip; then
            echo "Blocking IP: $ip (Failed attempts: $count)"
            # 封禁 IP 并记录日志
            iptables -A INPUT -s $ip -j DROP
            echo "$(date) : Blocked $ip due to $count failed attempts." >> /var/log/firewall_block.log
            # 3. 触发告警（模拟发送至钉钉）
            # curl -X POST "https://oapi.dingtalk.com/robot/send?access_token=XXX" \
            # -H 'Content-Type: application/json' \
            # -d "{\"msgtype\": \"text\", \"text\": {\"content\": \"警告：服务器检测到 IP $ip 存在暴力破解行为，已自动封禁，\"}}"
        fi
    fi
done < $TMP_FILE
# 清理临时文件
rm -f $TMP_FILE

深度优化与最佳实践

为了使日志脚本达到生产级标准,还需要关注以下细节：

• 性能优化：对于高并发服务器，直接读取大文件会消耗大量 I/O。建议使用 tail -F 配合 while read 循环实现流式处理，或者利用 inotifywait 监控日志文件的写入事件，实现真正的实时响应，而非通过 crontab 轮询。
• 日志结构化：在脚本生成日志时，应强制输出 JSON 格式。echo "{\"timestamp\": \"$(date -Iseconds)\", \"level\": \"ERROR\", \"message\": \"Disk usage high\"}"，这种结构化数据能被监控系统直接解析，无需后续复杂的正则清洗。
• 权限控制：日志脚本通常以 root 权限运行，因此脚本文件本身必须设置严格的权限（如 700），防止被恶意篡改导致执行任意代码，日志文件的归属组应根据应用需求合理配置，避免敏感信息泄露。

Linux 日志脚本不仅仅是简单的文本处理工具，它是运维自动化体系中不可或缺的感知器官，通过构建包含智能轮转、精准分析、主动防御、即时告警的脚本体系，运维人员可以从繁琐的日常巡检中解放出来，将精力投入到更具价值的架构优化中，掌握 Shell 脚本对日志的深度控制能力，是每一位 Linux 工程师从“操作者”迈向“架构师”的必经之路。

相关问答

Q1：在使用脚本处理日志时，如何避免日志轮转过程中丢失数据？
A： 避免数据丢失的关键在于不要直接删除或清空正在被进程写入的文件，最佳实践是先使用 cp 命令复制日志文件到备份目录，再使用 > /path/to/log 或 truncate -s 0 /path/to/log 清空原文件，而不是使用 rm 删除原文件，清空操作保留了文件的 inode 号，确保正在写入该文件的进程不会丢失句柄，清空后应向进程发送重载信号（如 nginx -s reload 或 kill -USR1），确保进程重新打开日志文件。

Q2：对于每秒产生数千行日志的高并发应用，Shell 脚本处理效率不足怎么办？
A： 当 Shell 脚本（如 Bash）成为性能瓶颈时，应转向更高性能的语言或工具，可以尝试优化正则表达式，减少贪婪匹配；使用 awk 或 sed 等流编辑器通常比纯 Bash 循环快得多，如果依然无法满足需求，建议使用 Lua 或 Python 编写处理脚本，它们在文本处理性能上优于 Shell，对于极致性能要求的场景，应直接在应用层集成日志采集 Agent（如 Fluentd 或 Filebeat），或使用 Go/Rust 编写专用的日志处理服务。

互动环节：
你在实际运维中是否遇到过因日志未及时处理导致的服务故障？欢迎在评论区分享你的踩坑经验或独家的日志处理脚本技巧，我们一起探讨更高效的解决方案！