简介这是一套面向安全运维与日志分析学习者的命令行Web日志审计工具基于Python实现将日志统计、终端可视化与机器学习恶意请求识别整合在一起适合具备Python基础、希望上手日志审计与异常检测实战的开发者。资源包共63个文件以35个py源码文件为核心辅以17张jpg运行截图、4个txt样本与说明、2个ini配置文件及日志、md文档等压缩包约10.58MB目录按bin、lib、machine_learning、conf、logs等模块划分结构清晰。功能上覆盖访问量统计、日志审查、请求统计与恶意请求分析内置白名单与黑名单样本集及训练数据可支撑机器学习模型的训练与验证。配置方面通过config.ini连接数据库与日志读取参数并提供check_conf.py做配置校验默认使用sqlite也可选装MySQL。目前已有832人学习适合作为日志审计与异常检测方向的练手项目或二次开发基础。1. 从一堆 access.log 到能用的审计结论这套 Python 工具到底解决什么手里拿到一个几百 MB 的 Nginx access.log老板要你半小时内说清楚「有没有人在扫我们」「哪个 IP 最可疑」「昨天下午那波 502 是不是被打的」——这种场景下grep加awk能顶一阵但一旦要按时间窗口做统计、按请求特征做异常识别纯命令行就开始力不从心。这套「基于机器学习的 Web 日志统计分析与异常检测工具」就是冲着这个痛点来的它是一个跑在终端里的 Web 日志审计工具把访问量统计、日志审查、请求分布统计和恶意请求分析四件事塞进一个命令行界面用terminaltables把结果画成表格用机器学习模型对请求做黑白判定。它适合安全运维、应急响应和做日志分析练手的人Python 3.6 就能跑默认用标准库sqlite落库不强制装 MySQL。下面我按「配置 → 跑通 → 调参 → 避坑」的顺序把它拆成能直接抄的步骤。2. 环境与配置落地config.ini 里每个字段到底管什么这套工具的运行链路是「读日志 → 解析入库 → 统计/建模 → 终端展示」所以配置错一个字段后面全是空表或者直接崩。先把环境搭对再谈分析。2.1 依赖安装与 Python 版本边界项目要求 Python 3.6requirements.txt里主要是机器学习、数据库和终端表格相关的库。安装命令在项目说明里写的是python -r requirements.txt这里其实是个笔误正确写法是带-m pip# 建议先建虚拟环境避免污染系统 Python python3 -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖注意是 -m pip 而不是直接 python -r python -m pip install -r requirements.txt逻辑说明-m pip保证调用的是当前解释器对应的 pip避免多版本 Python 下装错地方。参数上如果你的环境里python指向 2.x全部换成python3。这一步最常见的翻车是terminaltables或机器学习库编译失败多数是 Python 版本过低或缺少编译工具链先确认python --version输出 3.6 以上再继续。2.2 config.ini 关键字段逐项拆解配置文件在analog根目录下主要分数据库连接和日志读取两块。默认走 sqlite如果你不打算上 MySQL数据库那几项保持默认即可重点在日志路径和解析规则。[database] # 默认 sqlite文件会生成在项目目录下 type sqlite # 如果用 mysql下面几项才需要填 host 127.0.0.1 port 3306 user root password your_password dbname analog [log] # 待分析的 Web 日志绝对路径支持 Nginx/Apache 常见格式 path /var/log/nginx/access.log # 日志格式模板字段顺序要和真实日志一致 format $remote_addr - - [$time_local] $request $status $body_bytes_sent逻辑说明type决定走哪套存储后端sqlite 零配置适合快速验证MySQL 适合日志量大、要多人共享结果的场景。format是最容易配错的一项——它必须和你的日志真实字段顺序对齐否则解析出来的 IP、状态码会整体错位统计结果全是垃圾。参数建议先用head -n 5 access.log看一眼真实格式再照着改format不要照抄示例。2.3 用 check_conf.py 做配置自检配完不要急着跑主程序项目自带check_conf.py专门用来验证配置正确性python check_conf.py逻辑说明这个脚本会尝试按config.ini连接数据库、读取日志文件并做一次试解析。如果它报「日志文件不存在」或「格式不匹配」说明路径或format有问题如果报数据库连接失败检查type和账号密码。我的习惯是每次换日志源都先跑一遍它比直接跑main.py再对着报错猜要省事得多。这一步过了才说明环境真正可用。3. 跑通主流程统计、审查与机器学习异常检测怎么串起来配置自检通过后main.py是入口。它把日志审计、统计和机器学习识别恶意请求串成一条流水线理解这条链路才知道每个功能输出的数字从哪来。3.1 日志解析入库与访问量统计主程序启动后会先解析日志并写入数据库再做统计。核心逻辑大致是这样# 简化后的主流程示意实际以 main.py 为准 from lib import configparser, logger from machine_learning import detector def run(): conf configparser.load(config.ini) # 读取配置 logger.init(conf) # 初始化日志 # 1. 解析 access.log 并入库 records parse_and_store(conf[log][path]) # 2. 访问量、状态码、请求路径统计 stats build_statistics(records) # 3. 机器学习模型对请求做恶意判定 result detector.predict(records) render_terminal_table(stats, result) # terminaltables 渲染 if __name__ __main__: run()逻辑说明parse_and_store负责把文本日志转成结构化记录build_statistics按 IP、URL、状态码聚合detector.predict才是机器学习那部分。参数上统计维度由配置和代码里的聚合键决定想加「按小时分布」就得改聚合逻辑。这一步的产出就是终端里那几张表访问量统计、请求统计、恶意请求分析。3.2 机器学习异常检测训练集与黑白样本项目在conf/sample_set下带了test_white_log.txt、test_black_log.txt和train.txt这是模型能工作的前提——白样本是正常请求黑样本是恶意请求train.txt用于训练。# 目录结构节选 conf/ default_config.ini sample_set/ test_white_log.txt # 正常请求样本 test_black_log.txt # 恶意请求样本 train.txt # 训练数据逻辑说明模型本质是把请求特征URL 长度、特殊字符比例、参数个数等映射成「正常/恶意」二分类。白样本决定模型认为什么是「正常」黑样本决定它识别什么为「攻击」。参数建议如果你的业务 URL 风格和自带样本差异大比如全是 RESTful 带 UUID 的路径直接套用自带模型误报会很高需要用自己的日志补充白样本重新训练。这是这套工具能不能真正用起来的分水岭。3.3 终端图形化输出与结果解读统计和检测结果通过terminaltables渲染成终端表格项目_img目录下的截图就是实际输出效果。解读时重点看三列请求量异常的 IP、状态码集中在 4xx/5xx 的路径、被模型标黑的请求。# 典型运行 python main.py # 输出为多张终端表格访问量统计 / 请求统计 / 恶意请求分析逻辑说明终端表格适合快速排查不适合长期留存。我的做法是把输出重定向到文件配合logs/file_log.log一起看。参数上如果表格太宽在终端里换行错乱调小终端字号或把输出重定向后用编辑器看。这一步的坑在于模型标黑不等于真攻击它只是「偏离白样本」必须人工二次确认。4. 避坑与排查这套工具最容易翻车的五个地方工具本身不复杂但日志分析类项目「配置差一点、结果差一片」下面这几条是我实际拆解时踩过或见别人踩过的。4.1 现象统计表全是 0 或空原因config.ini里path指向的日志文件不存在或format与真实日志字段顺序不一致导致解析出空记录。解决先ls -l确认路径再head -n 3对比格式用check_conf.py验证别跳过自检。4.2 现象恶意请求分析误报一大堆正常 URL原因自带黑白样本和你的业务流量分布差异过大模型把正常但「长得不常见」的 URL 判成恶意。解决往test_white_log.txt里补充你自己的正常请求样本重新训练或先只用统计功能模型判定作为参考而非结论。4.3 现象sqlite 库文件越来越大查询变慢原因每次运行都往同一张表追加记录没有清理机制。解决定期备份后删库重建或改用 MySQL 并加时间分区。日志分析场景下数据增长很快这一点要提前规划。4.4 现象python -r requirements.txt报错原因项目说明里的命令少了-m pip直接python -r会被解释成执行一个叫-r的脚本。解决用python -m pip install -r requirements.txt这是标准写法。4.5 现象终端表格中文或宽字符错位原因terminaltables对东亚宽字符宽度计算不准列宽对不齐。解决把输出重定向到文件查看或临时把终端字体换成等宽字体。属于显示层问题不影响数据正确性。5. 进阶技巧把模型判定变成可复现的验证流程工具跑通只是起点真正决定它有没有用的是「你怎么验证模型判得准不准」。我一般会做一件事拿一批已经人工确认过的日志当测试集跑一遍模型统计误报和漏报。# 用自带样本做一次快速验证的思路 from machine_learning import detector white load_lines(conf/sample_set/test_white_log.txt) black load_lines(conf/sample_set/test_black_log.txt) # 白样本被判为恶意的比例 误报率 fp sum(1 for r in white if detector.predict_one(r) malicious) # 黑样本被判为正常的比例 漏报率 fn sum(1 for r in black if detector.predict_one(r) normal) print(误报率: %.2f%% % (fp / len(white) * 100)) print(漏报率: %.2f%% % (fn / len(black) * 100))逻辑说明误报率高说明白样本覆盖不够漏报率高说明黑样本特征太单一。参数上这两个比例没有绝对标准安全场景通常更容忍误报、不能容忍漏报所以优先补黑样本。跑完这组数字你才知道这套模型在你的环境里能不能信。验证指标含义偏高时的处理误报率正常请求被判恶意补充白样本重训漏报率恶意请求被判正常补充黑样本重训覆盖率样本覆盖的请求类型用真实日志扩充样本集还有个小技巧把main.py的输出和logs/train_log.log对照看训练日志里会记录模型处理过程出问题时这是唯一的黑匣子。别嫌日志啰嗦排查时它就是后悔药。从那以后我每次拿到新的日志源都强制先跑一遍check_conf.py再跑验证脚本确认误报漏报在可接受范围才敢把结论交出去。希望这套拆解能帮你少走点弯路。本文还有配套的精品资源点击获取