尧图网站开发 
在业务系统运维和开发过程中最让人头疼的不是功能复杂而是日志里那些密密麻麻、反复出现的红色报错。它们就像一场永远打不完的“红字游戏”今天修一个明天又冒出来一个这一台机器刚清完另一台机器又出现同款异常。如果你也经历过这种“日志越看越多、报错越查越乱”的阶段这篇文章值得看完。本文不会讨论游戏赛事而是把“一人杀穿整个赛场”的思路搬到日志治理上用一个轻量级脚本方案自动扫描、分类、聚合、统计并输出日志中的 ERROR 级异常让红色报错不再需要人工逐个翻找而是像战神一样快速“清场”。内容适合后端开发、运维工程师和刚接触日志分析的新手包含完整可复制的 Shell 与 Python 脚本、配置片段、常见报错排查思路和工程实践建议。1. 背景为什么日志里的红色报错会变成“红字游戏”1.1 什么是“红字游戏”式日志问题很多应用框架在输出 ERROR 级别日志时控制台或日志文件中会以红色、高亮颜色显示。例如 Spring Boot 默认的错误输出、Java Logback 的%red颜色编码、Python logging 的自定义 Formatter都会让异常信息变成刺眼的红字。当一个系统运行一段时间后日志文件中的红色 ERROR 会越来越多。它们来自不同模块、不同线程、不同时间点有些是偶发网络抖动导致有些是数据边界问题有些则是重复打印的同一异常。这时候排查效率会非常低2025-06-10 10:12:01 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:03 [http-nio-8080-exec-7] ERROR c.example.PayService - 支付回调处理异常: 签名校验失败 2025-06-10 10:12:05 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:08 [http-nio-8080-exec-9] ERROR c.example.UserService - 用户信息缓存更新失败: Redis连接超时一眼看去全是红字但包含的信息量极低。真正需要回答的问题是业务中最频繁的 Top 异常是什么哪个服务/类产生的错误最多哪些错误是重复噪声哪些需要立即修复报错趋势是上升还是下降如果靠人工 “一人一屏” 去盯日志那就像在红字赛场里被反复消耗不仅效率低还容易漏掉关键问题。1.2 为什么说“零”是一种高效治理思路“零”可以理解为零依赖、零人工干预、零多余日志噪声。零依赖不引入重量级日志平台用系统自带的命令和脚本就能分析。零人工干预定时任务自动扫描日志异常自动分类、自动统计、自动推送。零多余噪声通过聚合和去重把成千上万条 ERROR 收敛成几类核心问题。这套思路的价值在于它不需要你立刻上线 ELK、Loki、SkyWalking 等大型可观测性平台也能在中小型项目中快速获得“红字清场”的能力。2. 环境准备与版本说明本文示例以常见 Linux 环境为例重点演示配置思路。版本需要根据你的项目实际情况调整对应的运行环境大致如下组件说明操作系统CentOS 7.9 / Ubuntu 22.04 均可ShellBash 4.x 以上PythonPython 3.6 以上自带标准库即可定时任务crontab / systemd timer日志来源Spring Boot、Python、Nginx、通用文本日志不需要安装第三方 Python 包。下面的脚本只用标准库re、collections、datetime、pathlib。如果你的日志格式不同只需要调整正则表达式即可。本文示例项目结构如下log-cleaner/ ├── analyze_log.py # 核心分析脚本 ├── scan_error.sh # 快速扫描脚本 ├── config.ini # 日志路径和阈值配置 ├── output/ │ ├── error_report.txt # 聚合报告 │ └── error_detail.log # 过滤后的错误明细 └── run_cron.sh # 定时任务入口3. 核心思路拆解如何实现“一人杀穿全场”3.1 第一步先定位红字在哪里日志分析的第一步是确定日志文件位置。常见的路径模式包括/app/logs/app.log /app/logs/error.log /var/log/order-service/order-service.log如果是 Spring Boot 项目通常可以在application.yml中配置logging: file: name: /app/logs/app.log level: root: INFO com.example: DEBUG如果还没有日志文件配置建议先明确日志输出路径再交给脚本分析。脚本可以对单个文件、目录通配符或按日期滚动的app.log.2025-06-10这类文件都做兼容处理。3.2 第二步区分“真红字”和“假红字”并不是所有 ERROR 都需要立即处理。运维中经常遇到心跳检查失败导致的 ERROR但其实服务会自动恢复。上游接口超时但业务有重试机制。某些框架启动阶段打印的异常堆栈但后续初始化成功。所以在脚本中我们需要定义一个“可忽略关键词”列表例如heartbeat、retry、CircuitBreaker等。这些关键词可以按项目实际情况动态调整。3.3 第三步做聚合而不是逐条查看聚合的核心是按“异常签名”分组。比如下面两条日志2025-06-10 10:12:01 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:03 [http-nio-8080-exec-7] ERROR c.example.OrderService - 订单创建失败: 库存不足它们时间不同、线程不同但业务信息完全一致。聚合时才应该归为同一条异常。聚合的维度可以是日志中的类名例如c.example.OrderService日志中的固定消息模板例如订单创建失败: {}异常堆栈的第一行例如java.lang.NullPointerException: xxx3.4 第四步输出报告并触发后续动作分析完成后脚本应该输出Top 10 异常类型及出现次数每个异常类型的最新出现时间异常趋势今日 vs 昨日如果异常数量超过阈值还可以通过 Webhook 推送到钉钉、企业微信或飞书机器人实现自动告警。4. 完整实战案例红字日志“清场”脚本下面我们一步步实现一个可运行的日志分析案例。先实现快速扫描脚本再实现分类聚合脚本最后接入定时任务。4.1 创建项目结构在服务器上执行mkdir -p /opt/log-cleaner/output cd /opt/log-cleaner touch scan_error.sh analyze_log.py config.ini run_cron.sh chmod x scan_error.sh analyze_log.py run_cron.sh4.2 编写快速扫描脚本文件路径/opt/log-cleaner/scan_error.sh#!/bin/bash # 快速统计日志文件中 ERROR 出现的次数和分布 # 用法: ./scan_error.sh /app/logs/app.log LOG_FILE${1:-/app/logs/app.log} if [ ! -f $LOG_FILE ]; then echo 日志文件不存在: $LOG_FILE exit 1 fi echo 红字日志快速扫描 echo 日志文件: $LOG_FILE # 统计 ERROR 总数 TOTAL_ERRORS$(grep -c ERROR $LOG_FILE || true) echo ERROR 总次数: $TOTAL_ERRORS echo echo 按小时统计 ERROR 分布 grep ERROR $LOG_FILE | awk {print $2} | cut -d: -f1 | sort | uniq -c echo echo 按类名统计 Top 10 ERROR 分布 grep ERROR $LOG_FILE | grep -oE c\.example\.[A-Za-z] | sort | uniq -c | sort -nr | head -10 echo echo 最近 10 条 ERROR 原始日志 grep ERROR $LOG_FILE | tail -10这个脚本的核心价值是快速概览适合在服务器上手动执行./scan_error.sh /app/logs/app.log如果你还没有实际日志文件也可以用下面这段命令生成一份模拟日志用于测试mkdir -p /tmp/log-demo for i in $(seq 1 50); do echo 2025-06-10 10:$(printf %02d $((i % 60))):01 [http-nio-8080-exec-$((i % 10))] ERROR c.example.OrderService - 订单创建失败: 库存不足 done /tmp/log-demo/app.log for i in $(seq 1 30); do echo 2025-06-10 11:$(printf %02d $((i % 60))):03 [http-nio-8080-exec-$((i % 10))] ERROR c.example.PayService - 支付回调处理异常: 签名校验失败 done /tmp/log-demo/app.log然后扫描./scan_error.sh /tmp/log-demo/app.log预期输出类似ERROR 总次数: 80 按小时统计 ERROR 分布 50 10 30 11 按类名统计 Top 10 ERROR 分布 50 c.example.OrderService 30 c.example.PayService4.3 编写 Python 分类聚合脚本快速扫描脚本只能解决“有多少红字”的问题接下来用 Python 解决“有哪些类型的红字、各自出现多少次、是否需要告警”。文件路径/opt/log-cleaner/analyze_log.py#!/usr/bin/env python3 # -*- coding: utf-8 -*- 日志 ERROR 分类聚合分析脚本 功能 1. 扫描指定日志文件中包含 ERROR 的日志行 2. 按“类名 消息模板”聚合异常 3. 输出 Top N 异常报告 4. 支持忽略指定关键词的噪声异常 import re import sys from collections import Counter, defaultdict from datetime import datetime from pathlib import Path class LogAnalyzer: def __init__(self, log_path, ignore_keywordsNone, top_n10): self.log_path Path(log_path) self.ignore_keywords ignore_keywords or [heartbeat, retry] self.top_n top_n # 匹配日志中常见的“类名 - 消息”结构 self.pattern re.compile( r(?Ptime\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}) r.*?ERROR\s(?Pclass\S)\s-\s(?Pmessage.*) ) def _is_ignored(self, message): 判断是否为需要忽略的噪声异常 return any(keyword.lower() in message.lower() for keyword in self.ignore_keywords) def analyze(self): 执行分析返回聚合结果 if not self.log_path.exists(): print(f[错误] 日志文件不存在: {self.log_path}) sys.exit(1) # 用于统计的容器 error_counter Counter() # (类名, 消息模板) - 次数 latest_time {} # (类名, 消息模板) - 最新时间 detail_lines [] # 原始明细 with open(self.log_path, r, encodingutf-8, errorsignore) as f: for line in f: if ERROR not in line: continue match self.pattern.search(line.strip()) if not match: continue class_name match.group(class) message match.group(message).strip() log_time match.group(time) # 消息模板化把具体的 ID、数字替换为占位符 template re.sub(r\d, {id}, message) if self._is_ignored(template): continue key (class_name, template) error_counter[key] 1 latest_time[key] log_time detail_lines.append(line.strip()) return error_counter, latest_time, detail_lines def report(self, error_counter, latest_time, detail_lines): 生成可读报告 lines [] lines.append( * 60) lines.append(ERROR 聚合分析报告) lines.append(f报告生成时间: {datetime.now().strftime(%Y-%m-%d %H:%M:%S)}) lines.append(f日志文件: {self.log_path}) lines.append(f原始 ERROR 行数: {len(detail_lines)}) lines.append(f聚合后异常类型数: {len(error_counter)}) lines.append( * 60) lines.append() lines.append(fTop {self.top_n} 异常类型) lines.append() for idx, (key, count) in enumerate(error_counter.most_common(self.top_n), start1): class_name, template key lines.append(f{idx}. [{count} 次] 最近出现: {latest_time[key]}) lines.append(f 类名: {class_name}) lines.append(f 消息模板: {template}) lines.append() return \n.join(lines) def main(): log_path sys.argv[1] if len(sys.argv) 1 else /app/logs/app.log analyzer LogAnalyzer(log_path) counter, latest, details analyzer.analyze() report_text analyzer.report(counter, latest, details) # 输出报告到 output 目录 output_dir Path(/opt/log-cleaner/output) output_dir.mkdir(exist_okTrue) report_path output_dir / error_report.txt report_path.write_text(report_text, encodingutf-8) detail_path output_dir / error_detail.log detail_path.write_text(\n.join(details), encodingutf-8) # 控制台也打印一份 print(report_text) print(f报告已保存: {report_path}) print(f明细已保存: {detail_path}) if __name__ __main__: main()这段代码有几个值得注意的设计点消息模板化订单创建失败: 库存不足会保留订单创建失败: 订单号 12345会被统一为订单创建失败: 订单号 {id}从而把同类型异常聚合到一起。忽略关键词把heartbeat、retry这类噪声过滤掉避免误报。输出双份结果报告给人看明细留档用于后续排查。运行方式cd /opt/log-cleaner python3 analyze_log.py /tmp/log-demo/app.log预期输出核心片段 ERROR 聚合分析报告 报告生成时间: 2025-06-10 12:00:00 日志文件: /tmp/log-demo/app.log 原始 ERROR 行数: 80 聚合后异常类型数: 2 Top 10 异常类型 1. [50 次] 最近出现: 2025-06-10 10:59:01 类名: c.example.OrderService 消息模板: 订单创建失败: 库存不足 2. [30 次] 最近出现: 2025-06-10 11:59:03 类名: c.example.PayService 消息模板: 支付回调处理异常: 签名校验失败4.4 接入定时任务日志分析最好定时执行而不是等出事了再手动跑。创建一个入口脚本文件路径/opt/log-cleaner/run_cron.sh#!/bin/bash # 定时任务入口分析日志并检查是否需要告警 LOG_PATH${1:-/app/logs/app.log} OUTPUT_DIR/opt/log-cleaner/output THRESHOLD${THRESHOLD:-100} cd /opt/log-cleaner # 执行分析 python3 analyze_log.py $LOG_PATH # 检查异常总数是否超过阈值 ERROR_COUNT$(grep -oE 原始 ERROR 行数: [0-9] output/error_report.txt | grep -oE [0-9]) if [ -n $ERROR_COUNT ] [ $ERROR_COUNT -gt $THRESHOLD ]; then # 超过阈值输出告警提示 # 实际项目中可以在这里调用钉钉/企业微信 Webhook echo [告警] ERROR 数量 $ERROR_COUNT 超过阈值 $THRESHOLD # 示例curl -X POST -H Content-Type: application/json \ # -d {\msgtype\:\text\,\text\:{\content\:\日志告警: ERROR $ERROR_COUNT 条\}} \ # https://example.com/webhook fi配置 crontabcrontab -e添加内容# 每小时的第 5 分钟执行一次日志分析 5 * * * * /opt/log-cleaner/run_cron.sh /app/logs/app.log /opt/log-cleaner/cron.log 21保存后系统每小时会自动分析一次日志并将结果写入/opt/log-cleaner/output目录。4.5 结果说明与扩展方向经过上面几步你可以实现1 分钟内扫描出日志中全部 ERROR 的数量。自动把相同异常聚合为一类输出 Top 10 榜单。手动执行脚本即可生成报告无需登录日志平台。每小时定时分析不需要人工盯日志文件。如果后续想要更强大的能力可以朝两个方向扩展接入消息队列把分析结果发送到 Kafka由下游日志系统做长期存储和趋势分析。接入告警机器人当前脚本已经预留了 Webhook 注释位置可以对接钉钉、企业微信、飞书等机器人。5. 常见问题与排查思路在实际使用这套脚本方案时可能会遇到一些问题下面按常见程度列举。问题现象常见原因解决思路脚本提示“日志文件不存在”日志路径配置错误或应用还没生成日志检查应用日志配置文件确认绝对路径正确ERROR 数量统计为 0日志级别高于 ERROR或日志格式中不包含 ERROR 单词检查logback.xml/log4j2.xml级别配置聚合后异常类型太多消息中包含 UUID、时间戳、IP 等动态内容模板化不彻底扩展正则表达式把所有动态值统一替换为占位符脚本执行慢日志文件达到 GB 级别逐行正则匹配耗时较长改用grep ERROR先过滤再交给 Python 处理中文日志乱码日志文件编码与脚本读取编码不一致读取时指定encodingutf-8必要时改为gbk定时任务不执行crontab 环境变量和 PATH 问题在脚本入口处显式指定 Python 绝对路径如/usr/bin/python35.1 日志级别不打印 ERROR 怎么处理有些应用配置了rootWARN导致 ERROR 日志不会输出。此时需要修改日志级别logging: level: root: INFO或者如果只想保留 ERROR 到一个独立文件可以使用 Logback 的过滤器!-- logback-spring.xml 示例片段 -- appender nameERROR_FILE classch.qos.logback.core.rolling.RollingFileAppender file/app/logs/error.log/file filter classch.qos.logback.classic.filter.LevelFilter levelERROR/level onMatchACCEPT/onMatch onMismatchDENY/onMismatch /filter encoder pattern%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender5.2 日志文件按天滚动后如何扫描历史文件如果是app.log.2025-06-10这种格式可以把脚本的日志路径参数改成目录然后遍历目录下所有匹配文件。Python 里可以用Path.glob实现for p in Path(/app/logs).glob(app.log*): # 处理每个文件5.3 异常趋势怎么比较当前脚本只输出分析时刻的快照。要比较趋势可以在定时任务里每天归档一份报告cp output/error_report.txt output/error_report_$(date %F).txt之后对比不同日期的报告就能看出异常数量是上升还是下降。6. 最佳实践与工程建议要让这套日志治理方案真正落地而不是变成又一个“跑完就没用”的脚本有几个工程实践值得认真考虑。6.1 日志格式尽量结构化非结构化日志很难做自动化分析。建议团队内部统一日志格式比如时间 | 线程 | 级别 | 类名 | 消息 | traceId如果你使用 Spring Boot可以这样配置logging: pattern: console: %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - traceId%X{traceId} - %msg%n好处是脚本正则写起来容易后续接入 ELK 时也不用二次改造。6.2 控制 ERROR 日志的打印频率某些异常在循环中会被打爆日志。例如订单批量处理时1000 条数据里有 500 条失败如果每条打印一次 ERROR日志文件会瞬间膨胀。建议增加“异常熔断打印”逻辑比如同一类异常每 10 秒最多打印一次其余只累加计数。// Java 示例思路使用 RateLimiter 控制错误日志输出频率 // 实际代码需根据项目使用的限流组件调整 if (rateLimiter.tryAcquire()) { log.error(订单处理失败: {}, orderId, e); } else { errorCount.incrementAndGet(); }6.3 敏感信息脱敏日志中经常出现手机号、身份证、token、密码等敏感字段。分析脚本和日志平台都可能采集这些数据因此必须做脱敏处理。可以按照下面的方式替换138****1234 token*** {password: ***}在日志输出时就应该脱敏而不是等到分析脚本再做。Logback 中可以自定义MessageConverter或使用脱敏工具类。6.4 告警阈值要有业务含义不要把阈值拍脑袋定为 1000。建议先观察一周正常运行的 ERROR 基线然后设置“基线 x 2”或“基线 20%”作为告警阈值。同时区分瞬时异常和持续异常瞬时异常某分钟 ERROR 突增但下一分钟恢复正常可能只是网络抖动。持续异常连续 10 分钟 ERROR 持续走高才是需要处理的真正问题。6.5 保留原始明细但设置保留周期聚合报告适合快速定位问题但要真正排查堆栈信息还是需要原始明细。建议原始日志保留 30 天聚合报告保留 90 天过期日志自动清理。可以借助logrotate实现# /etc/logrotate.d/app-log /app/logs/app.log { daily rotate 30 compress missingok copytruncate }6.6 尽量控制脚本的权限范围日志分析脚本建议使用只读权限运行不要用 root 执行。涉及告警 Webhook 地址时不要把密钥直接写在脚本里建议通过环境变量或配置文件注入。# 示例通过环境变量传入 Webhook WEBHOOK_URL${WEBHOOK_URL:-https://example.com/hook}7. 总结与后续学习方向本文从一个看起来很“游戏化”的标题出发实际上解决的是一个非常务实的运维痛点日志里红色 ERROR 太多、太杂、太难处理。通过快速扫描脚本、Python 聚合分析脚本和定时任务组合你可以在一小时内搭建一套轻量级的“红字清场”方案不需要额外引入任何大数据组件。核心收获可以归纳为三点先知道红色报错有多少、在哪、什么类型再谈修复。聚合分析永远比逐条查看高效关键是做好消息模板化。自动化定时分析可以让日志治理从“救火”变成“日常巡检”。如果接下来想继续深入可以从这些方向入手学习 ELK 或 Loki Grafana 搭建集中式日志平台。学习 OpenTelemetry把日志、指标、链路追踪统一起来。学习告警规则设计避免告警风暴。学习日志采集器的实现原理理解 filebeat、fluentd 的工作方式。最后也建议你从一个小项目开始先拿一份真实业务日志跑一遍脚本把 Top 10 异常列出来挑出最频繁的一个修复掉。当下一轮分析发现它从榜单上消失时你会真正感受到“红字清场”的成就感。 
在业务系统运维和开发过程中最让人头疼的不是功能复杂而是日志里那些密密麻麻、反复出现的红色报错。它们就像一场永远打不完的“红字游戏”今天修一个明天又冒出来一个这一台机器刚清完另一台机器又出现同款异常。如果你也经历过这种“日志越看越多、报错越查越乱”的阶段这篇文章值得看完。本文不会讨论游戏赛事而是把“一人杀穿整个赛场”的思路搬到日志治理上用一个轻量级脚本方案自动扫描、分类、聚合、统计并输出日志中的 ERROR 级异常让红色报错不再需要人工逐个翻找而是像战神一样快速“清场”。内容适合后端开发、运维工程师和刚接触日志分析的新手包含完整可复制的 Shell 与 Python 脚本、配置片段、常见报错排查思路和工程实践建议。1. 背景为什么日志里的红色报错会变成“红字游戏”1.1 什么是“红字游戏”式日志问题很多应用框架在输出 ERROR 级别日志时控制台或日志文件中会以红色、高亮颜色显示。例如 Spring Boot 默认的错误输出、Java Logback 的%red颜色编码、Python logging 的自定义 Formatter都会让异常信息变成刺眼的红字。当一个系统运行一段时间后日志文件中的红色 ERROR 会越来越多。它们来自不同模块、不同线程、不同时间点有些是偶发网络抖动导致有些是数据边界问题有些则是重复打印的同一异常。这时候排查效率会非常低2025-06-10 10:12:01 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:03 [http-nio-8080-exec-7] ERROR c.example.PayService - 支付回调处理异常: 签名校验失败 2025-06-10 10:12:05 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:08 [http-nio-8080-exec-9] ERROR c.example.UserService - 用户信息缓存更新失败: Redis连接超时一眼看去全是红字但包含的信息量极低。真正需要回答的问题是业务中最频繁的 Top 异常是什么哪个服务/类产生的错误最多哪些错误是重复噪声哪些需要立即修复报错趋势是上升还是下降如果靠人工 “一人一屏” 去盯日志那就像在红字赛场里被反复消耗不仅效率低还容易漏掉关键问题。1.2 为什么说“零”是一种高效治理思路“零”可以理解为零依赖、零人工干预、零多余日志噪声。零依赖不引入重量级日志平台用系统自带的命令和脚本就能分析。零人工干预定时任务自动扫描日志异常自动分类、自动统计、自动推送。零多余噪声通过聚合和去重把成千上万条 ERROR 收敛成几类核心问题。这套思路的价值在于它不需要你立刻上线 ELK、Loki、SkyWalking 等大型可观测性平台也能在中小型项目中快速获得“红字清场”的能力。2. 环境准备与版本说明本文示例以常见 Linux 环境为例重点演示配置思路。版本需要根据你的项目实际情况调整对应的运行环境大致如下组件说明操作系统CentOS 7.9 / Ubuntu 22.04 均可ShellBash 4.x 以上PythonPython 3.6 以上自带标准库即可定时任务crontab / systemd timer日志来源Spring Boot、Python、Nginx、通用文本日志不需要安装第三方 Python 包。下面的脚本只用标准库re、collections、datetime、pathlib。如果你的日志格式不同只需要调整正则表达式即可。本文示例项目结构如下log-cleaner/ ├── analyze_log.py # 核心分析脚本 ├── scan_error.sh # 快速扫描脚本 ├── config.ini # 日志路径和阈值配置 ├── output/ │ ├── error_report.txt # 聚合报告 │ └── error_detail.log # 过滤后的错误明细 └── run_cron.sh # 定时任务入口3. 核心思路拆解如何实现“一人杀穿全场”3.1 第一步先定位红字在哪里日志分析的第一步是确定日志文件位置。常见的路径模式包括/app/logs/app.log /app/logs/error.log /var/log/order-service/order-service.log如果是 Spring Boot 项目通常可以在application.yml中配置logging: file: name: /app/logs/app.log level: root: INFO com.example: DEBUG如果还没有日志文件配置建议先明确日志输出路径再交给脚本分析。脚本可以对单个文件、目录通配符或按日期滚动的app.log.2025-06-10这类文件都做兼容处理。3.2 第二步区分“真红字”和“假红字”并不是所有 ERROR 都需要立即处理。运维中经常遇到心跳检查失败导致的 ERROR但其实服务会自动恢复。上游接口超时但业务有重试机制。某些框架启动阶段打印的异常堆栈但后续初始化成功。所以在脚本中我们需要定义一个“可忽略关键词”列表例如heartbeat、retry、CircuitBreaker等。这些关键词可以按项目实际情况动态调整。3.3 第三步做聚合而不是逐条查看聚合的核心是按“异常签名”分组。比如下面两条日志2025-06-10 10:12:01 [http-nio-8080-exec-3] ERROR c.example.OrderService - 订单创建失败: 库存不足 2025-06-10 10:12:03 [http-nio-8080-exec-7] ERROR c.example.OrderService - 订单创建失败: 库存不足它们时间不同、线程不同但业务信息完全一致。聚合时才应该归为同一条异常。聚合的维度可以是日志中的类名例如c.example.OrderService日志中的固定消息模板例如订单创建失败: {}异常堆栈的第一行例如java.lang.NullPointerException: xxx3.4 第四步输出报告并触发后续动作分析完成后脚本应该输出Top 10 异常类型及出现次数每个异常类型的最新出现时间异常趋势今日 vs 昨日如果异常数量超过阈值还可以通过 Webhook 推送到钉钉、企业微信或飞书机器人实现自动告警。4. 完整实战案例红字日志“清场”脚本下面我们一步步实现一个可运行的日志分析案例。先实现快速扫描脚本再实现分类聚合脚本最后接入定时任务。4.1 创建项目结构在服务器上执行mkdir -p /opt/log-cleaner/output cd /opt/log-cleaner touch scan_error.sh analyze_log.py config.ini run_cron.sh chmod x scan_error.sh analyze_log.py run_cron.sh4.2 编写快速扫描脚本文件路径/opt/log-cleaner/scan_error.sh#!/bin/bash # 快速统计日志文件中 ERROR 出现的次数和分布 # 用法: ./scan_error.sh /app/logs/app.log LOG_FILE${1:-/app/logs/app.log} if [ ! -f $LOG_FILE ]; then echo 日志文件不存在: $LOG_FILE exit 1 fi echo 红字日志快速扫描 echo 日志文件: $LOG_FILE # 统计 ERROR 总数 TOTAL_ERRORS$(grep -c ERROR $LOG_FILE || true) echo ERROR 总次数: $TOTAL_ERRORS echo echo 按小时统计 ERROR 分布 grep ERROR $LOG_FILE | awk {print $2} | cut -d: -f1 | sort | uniq -c echo echo 按类名统计 Top 10 ERROR 分布 grep ERROR $LOG_FILE | grep -oE c\.example\.[A-Za-z] | sort | uniq -c | sort -nr | head -10 echo echo 最近 10 条 ERROR 原始日志 grep ERROR $LOG_FILE | tail -10这个脚本的核心价值是快速概览适合在服务器上手动执行./scan_error.sh /app/logs/app.log如果你还没有实际日志文件也可以用下面这段命令生成一份模拟日志用于测试mkdir -p /tmp/log-demo for i in $(seq 1 50); do echo 2025-06-10 10:$(printf %02d $((i % 60))):01 [http-nio-8080-exec-$((i % 10))] ERROR c.example.OrderService - 订单创建失败: 库存不足 done /tmp/log-demo/app.log for i in $(seq 1 30); do echo 2025-06-10 11:$(printf %02d $((i % 60))):03 [http-nio-8080-exec-$((i % 10))] ERROR c.example.PayService - 支付回调处理异常: 签名校验失败 done /tmp/log-demo/app.log然后扫描./scan_error.sh /tmp/log-demo/app.log预期输出类似ERROR 总次数: 80 按小时统计 ERROR 分布 50 10 30 11 按类名统计 Top 10 ERROR 分布 50 c.example.OrderService 30 c.example.PayService4.3 编写 Python 分类聚合脚本快速扫描脚本只能解决“有多少红字”的问题接下来用 Python 解决“有哪些类型的红字、各自出现多少次、是否需要告警”。文件路径/opt/log-cleaner/analyze_log.py#!/usr/bin/env python3 # -*- coding: utf-8 -*- 日志 ERROR 分类聚合分析脚本 功能 1. 扫描指定日志文件中包含 ERROR 的日志行 2. 按“类名 消息模板”聚合异常 3. 输出 Top N 异常报告 4. 支持忽略指定关键词的噪声异常 import re import sys from collections import Counter, defaultdict from datetime import datetime from pathlib import Path class LogAnalyzer: def __init__(self, log_path, ignore_keywordsNone, top_n10): self.log_path Path(log_path) self.ignore_keywords ignore_keywords or [heartbeat, retry] self.top_n top_n # 匹配日志中常见的“类名 - 消息”结构 self.pattern re.compile( r(?Ptime\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}) r.*?ERROR\s(?Pclass\S)\s-\s(?Pmessage.*) ) def _is_ignored(self, message): 判断是否为需要忽略的噪声异常 return any(keyword.lower() in message.lower() for keyword in self.ignore_keywords) def analyze(self): 执行分析返回聚合结果 if not self.log_path.exists(): print(f[错误] 日志文件不存在: {self.log_path}) sys.exit(1) # 用于统计的容器 error_counter Counter() # (类名, 消息模板) - 次数 latest_time {} # (类名, 消息模板) - 最新时间 detail_lines [] # 原始明细 with open(self.log_path, r, encodingutf-8, errorsignore) as f: for line in f: if ERROR not in line: continue match self.pattern.search(line.strip()) if not match: continue class_name match.group(class) message match.group(message).strip() log_time match.group(time) # 消息模板化把具体的 ID、数字替换为占位符 template re.sub(r\d, {id}, message) if self._is_ignored(template): continue key (class_name, template) error_counter[key] 1 latest_time[key] log_time detail_lines.append(line.strip()) return error_counter, latest_time, detail_lines def report(self, error_counter, latest_time, detail_lines): 生成可读报告 lines [] lines.append( * 60) lines.append(ERROR 聚合分析报告) lines.append(f报告生成时间: {datetime.now().strftime(%Y-%m-%d %H:%M:%S)}) lines.append(f日志文件: {self.log_path}) lines.append(f原始 ERROR 行数: {len(detail_lines)}) lines.append(f聚合后异常类型数: {len(error_counter)}) lines.append( * 60) lines.append() lines.append(fTop {self.top_n} 异常类型) lines.append() for idx, (key, count) in enumerate(error_counter.most_common(self.top_n), start1): class_name, template key lines.append(f{idx}. [{count} 次] 最近出现: {latest_time[key]}) lines.append(f 类名: {class_name}) lines.append(f 消息模板: {template}) lines.append() return \n.join(lines) def main(): log_path sys.argv[1] if len(sys.argv) 1 else /app/logs/app.log analyzer LogAnalyzer(log_path) counter, latest, details analyzer.analyze() report_text analyzer.report(counter, latest, details) # 输出报告到 output 目录 output_dir Path(/opt/log-cleaner/output) output_dir.mkdir(exist_okTrue) report_path output_dir / error_report.txt report_path.write_text(report_text, encodingutf-8) detail_path output_dir / error_detail.log detail_path.write_text(\n.join(details), encodingutf-8) # 控制台也打印一份 print(report_text) print(f报告已保存: {report_path}) print(f明细已保存: {detail_path}) if __name__ __main__: main()这段代码有几个值得注意的设计点消息模板化订单创建失败: 库存不足会保留订单创建失败: 订单号 12345会被统一为订单创建失败: 订单号 {id}从而把同类型异常聚合到一起。忽略关键词把heartbeat、retry这类噪声过滤掉避免误报。输出双份结果报告给人看明细留档用于后续排查。运行方式cd /opt/log-cleaner python3 analyze_log.py /tmp/log-demo/app.log预期输出核心片段 ERROR 聚合分析报告 报告生成时间: 2025-06-10 12:00:00 日志文件: /tmp/log-demo/app.log 原始 ERROR 行数: 80 聚合后异常类型数: 2 Top 10 异常类型 1. [50 次] 最近出现: 2025-06-10 10:59:01 类名: c.example.OrderService 消息模板: 订单创建失败: 库存不足 2. [30 次] 最近出现: 2025-06-10 11:59:03 类名: c.example.PayService 消息模板: 支付回调处理异常: 签名校验失败4.4 接入定时任务日志分析最好定时执行而不是等出事了再手动跑。创建一个入口脚本文件路径/opt/log-cleaner/run_cron.sh#!/bin/bash # 定时任务入口分析日志并检查是否需要告警 LOG_PATH${1:-/app/logs/app.log} OUTPUT_DIR/opt/log-cleaner/output THRESHOLD${THRESHOLD:-100} cd /opt/log-cleaner # 执行分析 python3 analyze_log.py $LOG_PATH # 检查异常总数是否超过阈值 ERROR_COUNT$(grep -oE 原始 ERROR 行数: [0-9] output/error_report.txt | grep -oE [0-9]) if [ -n $ERROR_COUNT ] [ $ERROR_COUNT -gt $THRESHOLD ]; then # 超过阈值输出告警提示 # 实际项目中可以在这里调用钉钉/企业微信 Webhook echo [告警] ERROR 数量 $ERROR_COUNT 超过阈值 $THRESHOLD # 示例curl -X POST -H Content-Type: application/json \ # -d {\msgtype\:\text\,\text\:{\content\:\日志告警: ERROR $ERROR_COUNT 条\}} \ # https://example.com/webhook fi配置 crontabcrontab -e添加内容# 每小时的第 5 分钟执行一次日志分析 5 * * * * /opt/log-cleaner/run_cron.sh /app/logs/app.log /opt/log-cleaner/cron.log 21保存后系统每小时会自动分析一次日志并将结果写入/opt/log-cleaner/output目录。4.5 结果说明与扩展方向经过上面几步你可以实现1 分钟内扫描出日志中全部 ERROR 的数量。自动把相同异常聚合为一类输出 Top 10 榜单。手动执行脚本即可生成报告无需登录日志平台。每小时定时分析不需要人工盯日志文件。如果后续想要更强大的能力可以朝两个方向扩展接入消息队列把分析结果发送到 Kafka由下游日志系统做长期存储和趋势分析。接入告警机器人当前脚本已经预留了 Webhook 注释位置可以对接钉钉、企业微信、飞书等机器人。5. 常见问题与排查思路在实际使用这套脚本方案时可能会遇到一些问题下面按常见程度列举。问题现象常见原因解决思路脚本提示“日志文件不存在”日志路径配置错误或应用还没生成日志检查应用日志配置文件确认绝对路径正确ERROR 数量统计为 0日志级别高于 ERROR或日志格式中不包含 ERROR 单词检查logback.xml/log4j2.xml级别配置聚合后异常类型太多消息中包含 UUID、时间戳、IP 等动态内容模板化不彻底扩展正则表达式把所有动态值统一替换为占位符脚本执行慢日志文件达到 GB 级别逐行正则匹配耗时较长改用grep ERROR先过滤再交给 Python 处理中文日志乱码日志文件编码与脚本读取编码不一致读取时指定encodingutf-8必要时改为gbk定时任务不执行crontab 环境变量和 PATH 问题在脚本入口处显式指定 Python 绝对路径如/usr/bin/python35.1 日志级别不打印 ERROR 怎么处理有些应用配置了rootWARN导致 ERROR 日志不会输出。此时需要修改日志级别logging: level: root: INFO或者如果只想保留 ERROR 到一个独立文件可以使用 Logback 的过滤器!-- logback-spring.xml 示例片段 -- appender nameERROR_FILE classch.qos.logback.core.rolling.RollingFileAppender file/app/logs/error.log/file filter classch.qos.logback.classic.filter.LevelFilter levelERROR/level onMatchACCEPT/onMatch onMismatchDENY/onMismatch /filter encoder pattern%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender5.2 日志文件按天滚动后如何扫描历史文件如果是app.log.2025-06-10这种格式可以把脚本的日志路径参数改成目录然后遍历目录下所有匹配文件。Python 里可以用Path.glob实现for p in Path(/app/logs).glob(app.log*): # 处理每个文件5.3 异常趋势怎么比较当前脚本只输出分析时刻的快照。要比较趋势可以在定时任务里每天归档一份报告cp output/error_report.txt output/error_report_$(date %F).txt之后对比不同日期的报告就能看出异常数量是上升还是下降。6. 最佳实践与工程建议要让这套日志治理方案真正落地而不是变成又一个“跑完就没用”的脚本有几个工程实践值得认真考虑。6.1 日志格式尽量结构化非结构化日志很难做自动化分析。建议团队内部统一日志格式比如时间 | 线程 | 级别 | 类名 | 消息 | traceId如果你使用 Spring Boot可以这样配置logging: pattern: console: %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - traceId%X{traceId} - %msg%n好处是脚本正则写起来容易后续接入 ELK 时也不用二次改造。6.2 控制 ERROR 日志的打印频率某些异常在循环中会被打爆日志。例如订单批量处理时1000 条数据里有 500 条失败如果每条打印一次 ERROR日志文件会瞬间膨胀。建议增加“异常熔断打印”逻辑比如同一类异常每 10 秒最多打印一次其余只累加计数。// Java 示例思路使用 RateLimiter 控制错误日志输出频率 // 实际代码需根据项目使用的限流组件调整 if (rateLimiter.tryAcquire()) { log.error(订单处理失败: {}, orderId, e); } else { errorCount.incrementAndGet(); }6.3 敏感信息脱敏日志中经常出现手机号、身份证、token、密码等敏感字段。分析脚本和日志平台都可能采集这些数据因此必须做脱敏处理。可以按照下面的方式替换138****1234 token*** {password: ***}在日志输出时就应该脱敏而不是等到分析脚本再做。Logback 中可以自定义MessageConverter或使用脱敏工具类。6.4 告警阈值要有业务含义不要把阈值拍脑袋定为 1000。建议先观察一周正常运行的 ERROR 基线然后设置“基线 x 2”或“基线 20%”作为告警阈值。同时区分瞬时异常和持续异常瞬时异常某分钟 ERROR 突增但下一分钟恢复正常可能只是网络抖动。持续异常连续 10 分钟 ERROR 持续走高才是需要处理的真正问题。6.5 保留原始明细但设置保留周期聚合报告适合快速定位问题但要真正排查堆栈信息还是需要原始明细。建议原始日志保留 30 天聚合报告保留 90 天过期日志自动清理。可以借助logrotate实现# /etc/logrotate.d/app-log /app/logs/app.log { daily rotate 30 compress missingok copytruncate }6.6 尽量控制脚本的权限范围日志分析脚本建议使用只读权限运行不要用 root 执行。涉及告警 Webhook 地址时不要把密钥直接写在脚本里建议通过环境变量或配置文件注入。# 示例通过环境变量传入 Webhook WEBHOOK_URL${WEBHOOK_URL:-https://example.com/hook}7. 总结与后续学习方向本文从一个看起来很“游戏化”的标题出发实际上解决的是一个非常务实的运维痛点日志里红色 ERROR 太多、太杂、太难处理。通过快速扫描脚本、Python 聚合分析脚本和定时任务组合你可以在一小时内搭建一套轻量级的“红字清场”方案不需要额外引入任何大数据组件。核心收获可以归纳为三点先知道红色报错有多少、在哪、什么类型再谈修复。聚合分析永远比逐条查看高效关键是做好消息模板化。自动化定时分析可以让日志治理从“救火”变成“日常巡检”。如果接下来想继续深入可以从这些方向入手学习 ELK 或 Loki Grafana 搭建集中式日志平台。学习 OpenTelemetry把日志、指标、链路追踪统一起来。学习告警规则设计避免告警风暴。学习日志采集器的实现原理理解 filebeat、fluentd 的工作方式。最后也建议你从一个小项目开始先拿一份真实业务日志跑一遍脚本把 Top 10 异常列出来挑出最频繁的一个修复掉。当下一轮分析发现它从榜单上消失时你会真正感受到“红字清场”的成就感。