简介这是一套面向Web安全工程师、运维开发人员及机器学习初学者的终端日志分析工具聚焦于Web服务器日志的自动化统计、审计与恶意请求识别。项目基于Python实现集成日志解析、访问量/请求类型多维统计、SQLite或MySQL持久化存储及轻量级机器学习模型含训练与预测模块支持在命令行中快速完成日志审查与异常检测任务。压缩包共63个文件含35个核心Python源码如main.py、check_conf.py、各类controller与machine_learning模块、17张界面与流程示意图JPG、4份说明文档TXT/MD、2个日志样本log、2个配置文件INI及1个动态演示GIF整体10.58MB结构清晰、模块解耦度高便于二次开发与教学拆解。目前已有833人学习下载读者可直接运行完整工具链获取从配置校验、日志加载、特征提取到恶意请求标记的全流程实践能力并参考sample_set与test_log等数据样例理解模型输入输出逻辑。1. 这不是又一个日志解析脚本它用无监督聚类规则引擎双路识别恶意请求3 分钟跑通 Apache/Nginx 日志审计闭环你有没有试过在凌晨两点翻着几百万行 access.log 查某个可疑 IPgrep、awk、sort、uniq 轮番上阵最后发现攻击特征藏在 User-Agent 的 Base64 编码段里而你刚用的正则根本没覆盖这个编码层——这种“日志盲区”正是传统统计工具的死穴。这个基于机器学习的 Web 日志统计分析与异常检测工具不是简单把日志转成表格而是把request_uri、status、user_agent、referer、ip五维字段喂进一个轻量级特征工程管道先用 Isolation Forest 做无监督异常打分再叠加基于规则的 payload 模式匹配SQLi/XSS/路径遍历三类模板最后把高危请求按风险等级时间密度聚合推送到终端图形界面。它不依赖 Elasticsearch 或商业 WAF纯 Python 实现开箱即用适合渗透测试复盘、运维日常巡检、CTF 日志分析训练场景。如果你手头有 Apache 或 Nginx 的标准 combined 日志格式或稍作预处理且 Python 版本 ≥3.6就能在本地终端完成从原始日志到可交互风险热力图的全流程——不是演示是真实跑得动的生产级轻量方案。2. 从 config.ini 到 check_conf.py配置驱动型架构如何让日志源、模型、输出三者解耦这个项目最值得借鉴的设计不是算法本身而是它的配置驱动型架构。整个流程不硬编码日志路径、数据库类型、特征权重全部通过config.ini控制check_conf.py则是这套机制的“守门人”。它不只校验文件是否存在更会模拟一次最小化数据流读取 sample_set 下的测试日志 → 解析字段 → 构建特征向量 → 调用模型 predict 接口 → 写入 logs 目录。这种“端到端冒烟测试”设计直接把部署阶段 70% 的配置类报错前置到了启动前。2.1 config.ini 的四个关键 section 及其真实作用域config.ini文件结构清晰但每个 section 的职责边界必须理清否则后续 train_log.log 里全是KeyError: feature_weight这类报错[log_source] # 注意这里不是指定单个文件而是支持 glob 通配符 log_path ./conf/*.log # 必须严格匹配 Nginx/Apache combined 格式字段顺序 log_format combined # 若你的日志是 JSON 格式如 Logstash 输出此处需改为 json并确保 lib/io.py 中有对应 parser[model] # 无监督模型选型逻辑Isolation Forest 对日志这种稀疏高维数据比 OneClassSVM 更鲁棒内存占用低 40% algorithm isolation_forest # n_estimators100 是血泪经验低于 50 时误报率陡增高于 200 后 AUC 提升不足 0.5%但训练耗时翻倍 n_estimators 100 # contamination0.01 表示假设 1% 请求为异常——别乱调这是根据 OWASP Top 10 攻击占比反推的基线值 contamination 0.01[database] # 默认 sqlite 是明智选择免安装、免权限、事务安全。MySQL 仅在需要跨节点共享模型状态时启用 type sqlite # sqlite 路径必须写相对路径且目录需存在。若写成 /tmp/analog.db程序不会自动创建 /tmp 目录 path ./logs/analog.db # MySQL 配置仅当 typemysqldb 时生效且要求已安装 PyMySQL host 127.0.0.1 port 3306 user analog_user password your_password database analog_db[output] # terminaltables 是核心渲染引擎table_style 控制终端显示效果 table_style SINGLE_BORDER # risk_threshold0.85 是模型输出分数的切割点高于此值才进入“高危”列表。该值需结合你的日志样本校准 risk_threshold 0.85 # 是否开启实时日志 tail 模式类似 tail -f。生产环境慎用会持续占用文件句柄 live_mode false提示config.ini中所有路径均为相对于analog/根目录的路径。若你把项目解压到/home/user/weblog-tool/那么log_path ./conf/*.log实际指向/home/user/weblog-tool/conf/*.log而非当前 shell 所在目录。2.2 check_conf.py 的三层校验逻辑与失败定位技巧check_conf.py不是简单的os.path.exists()检查它执行三阶验证配置语法层用configparser.ConfigParser()加载并检查必需 section 和 key 是否缺失资源可达层对log_path执行glob.glob()确认至少匹配一个文件对database.path检查目录可写性运行时兼容层实例化machine_learning.model.IsolationForestModel调用model.fit_sample()方法用test_white_log.txt和test_black_log.txt各抽 10 条构造 mini-batch验证特征向量维度与模型输入是否匹配。执行命令python check_conf.py成功输出示例✅ Config syntax OK ✅ Log source accessible: found 3 files in ./conf/ ✅ Database path writable: ./logs/analog.db ✅ Model compatibility test passed (input dim: 12, output score range: [0.12, 0.98]) → Configuration is READY for main.py execution.若失败错误信息会明确指向哪一层SyntaxError: No option log_format in section: log_source→ 缺少必填项回 config.ini 补全FileNotFoundError: No log files matched ./conf/*.log→ 检查 conf 目录是否存在、文件名后缀是否为 .logPermissionError: [Errno 13] Permission denied: ./logs/→ 手动执行mkdir -p ./logs并chmod 755 ./logsValueError: Input dimension mismatch: expected 12, got 8→ 特征工程代码与日志字段解析不一致需检查lib/io.py中parse_combined_line()函数是否正确提取了 5 个基础字段 7 个衍生特征如 uri_length、ua_entropy、referer_domain_count。3. main.py 的四阶段流水线从 raw log 到 risk_heatmap 的完整数据流拆解main.py是整个工具的执行中枢它把日志分析拆成原子化、可插拔的四阶段流水线ingest → feature_engineer → detect → render。每个阶段对应一个独立模块且支持通过配置开关启停。这种设计让你能快速定位瓶颈——比如发现detect阶段耗时过长就可单独对machine_learning/detector.py做性能剖析而不用在整条链路里大海捞针。3.1 ingest 阶段日志解析器如何应对 real-world 日志脏数据ingest阶段由lib/io.py中的LogReader类驱动。它不假设日志 100% 规范而是内置三重容错行级跳过遇到无法解析的行如压缩日志、空行、非 combined 格式记录file_log.log并跳过不中断整个流程字段降级若某行缺失referer字段referer值设为-而非抛出KeyError编码自适应自动探测文件编码UTF-8 GBK Latin-1避免中文 User-Agent 显示为b\xe4\xbd\xa0\xe5\xa5\xbd。核心代码段lib/io.pydef parse_combined_line(self, line: str) - Optional[Dict]: Parse one line of Apache/Nginx combined log format. Fields: ip - user [time] method uri proto status bytes referer ua Returns dict with keys: ip, method, uri, status, bytes, referer, ua, time If parsing fails, returns None and logs error to file_log.log try: # 正则预编译提升 3x 解析速度 if not self._compiled_pattern: self._compiled_pattern re.compile( r(\S) \S \S \[([^\]])\] (\S) ([^\s]) ([^\s]) (\d) (\S) ([^]*) ([^]*) ) match self._compiled_pattern.match(line.strip()) if not match: self.logger.warning(fLine skipped (no match): {line[:50]}...) return None ip, time, method, uri, proto, status, bytes_, referer, ua match.groups() # 字段清洗bytes_ 可能为 -转为 0status 强制 int bytes_val int(bytes_) if bytes_.isdigit() else 0 status_val int(status) if status.isdigit() else 0 return { ip: ip, time: time, method: method, uri: uri, status: status_val, bytes: bytes_val, referer: referer if referer ! - else , ua: ua if ua ! - else } except Exception as e: self.logger.error(fParse error on line {line[:50]}...: {e}) return None注意parse_combined_line()返回None时不抛异常这是刻意设计。ingest阶段的职责是“尽最大努力喂数据”异常处理交给上层main.py的ingest.run()统一汇总。你在file_log.log里看到的Line skipped日志就是它在默默帮你过滤脏数据。3.2 feature_engineer 阶段12 维特征如何从原始字符串中炼出来特征工程是本项目区分于脚本工具的核心。它不只做len(uri)这种基础统计而是构建语义感知特征特征名计算逻辑业务含义是否参与模型训练uri_lengthlen(uri)URL 长度异常常关联 fuzzing✅uri_param_counturi.count(?) uri.count()参数过多暗示 SQLi/XSS✅ua_entropyscipy.stats.entropy(Counter(ua.lower()).values())UA 随机性高暗示 bot✅referer_domain_countlen(set([domain for domain in extract_domains(referer)]))Referer 域名离散度高暗示爬虫✅status_4xx_rate_5m滑动窗口内 5 分钟 4xx 状态码占比短时高频 404 暗示目录爆破✅ip_request_freq_1h滑动窗口内 1 小时 IP 请求频次单 IP 高频请求是扫描特征✅method_mismatch1 if method not in [GET,POST,HEAD,PUT,DELETE] else 0非标 HTTP 方法如 PROPFIND✅uri_contains_php1 if .php in uri.lower() else 0PHP 脚本路径是常见攻击入口✅ua_contains_sqlmap1 if sqlmap in ua.lower() else 0工具指纹直连❌规则引擎专用uri_has_double_slash1 if // in uri else 0路径遍历特征❌规则引擎专用status_500_count_10m滑动窗口内 10 分钟 500 错误数应用层崩溃可能由注入引发✅time_hourint(time.split(:)[1])时间维度特征如凌晨 2 点高频请求✅这些特征全部在lib/feature_engineer.py的build_feature_vector()方法中生成。关键点在于所有滑动窗口计算均基于time字段解析出的datetime对象而非系统时间确保离线分析结果可复现。3.3 detect 阶段为什么用 Isolation Forest 而不是 AutoEncoderdetect阶段同时启用两条路径无监督路径IsolationForestModel位于machine_learning/model.py输入 12 维特征向量输出anomaly_score范围 0~1越高越异常规则路径RuleBasedDetector位于controller/detector.py对uri、ua、referer字段执行正则匹配命中即标记rule_flag1。选择 Isolation Forest 的三个硬理由小样本友好Web 日志中真实攻击样本极少0.1%AutoEncoder 需大量正常样本重建而 IF 只需随机切分即可隔离异常点可解释性保留IF 的decision_function()可返回每棵树的路径长度anomaly_score越高说明该样本被更快隔离——这与“攻击行为偏离正常模式”的直觉完全吻合推理速度快单条请求平均耗时 0.8msi5-8250U比 LSTM-based 检测快 12 倍满足终端实时分析需求。模型训练代码machine_learning/model.pyclass IsolationForestModel: def __init__(self, n_estimators100, contamination0.01): self.model IsolationForest( n_estimatorsn_estimators, contaminationcontamination, random_state42, # 固定 seed 保证结果可复现 n_jobs-1 # 自动使用所有 CPU 核心 ) self.is_fitted False def fit(self, X: np.ndarray): X: (n_samples, 12) feature matrix self.model.fit(X) self.is_fitted True # 保存训练时的 mean/std 用于后续标准化IF 内部已做此处为兼容其他模型预留 self.scaler StandardScaler().fit(X) def predict_score(self, X: np.ndarray) - np.ndarray: Return anomaly score in [0,1]. Higher more anomalous. if not self.is_fitted: raise RuntimeError(Model must be fitted before predict_score) # IF 返回的是 -1/1需映射到 [0,1] raw_scores self.model.decision_function(X) # 使用 sigmoid 映射避免极端值 scores 1 / (1 np.exp(-raw_scores)) return scores注意predict_score()返回的scores是经过 sigmoid 映射的不是原始decision_function输出。这是为了统一接口让main.py中的阈值判断score risk_threshold逻辑更直观。3.4 render 阶段terminaltables 如何把风险列表变成可交互热力图render阶段由controller/renderer.py驱动核心是TerminalTableRenderer类。它不只打印表格而是实现三重增强风险分级着色anomaly_score 0.9 为红色高危0.7~0.9 为黄色中危0.7 为绿色低危IP 地理位置标注调用lib/geoip.py内置 GeoLite2 City 数据库精简版将114.114.114.114映射为CN, Jiangsu, NanjingURI 截断与高亮对uri字段自动截断超长部分/api/v1/users/.../delete?tokenxxx→/api/v1/users/.../delete并对?后参数加粗显示。渲染主逻辑controller/renderer.pydef render_risk_table(self, risk_list: List[Dict]): risk_list: [ {ip: 192.168.1.100, uri: /admin.php?id1 UNION SELECT ..., score: 0.97, rule_flag: 1, time: 10/Oct/2023:14:22:33}, ... ] table SingleTable([ [Time, IP (Location), Method, URI, Status, Score, Rule], *[ [ item[time][-8:], # 只取 HH:MM:SS f{item[ip]} ({self.geoip.lookup(item[ip])}), # 地理位置 item[method], self._highlight_uri_params(item[uri]), # URI 高亮 item[status], self._colorize_score(item[score]), # 分数着色 ✓ if item[rule_flag] else — ] for item in risk_list[:50] # 限制显示前 50 条 ] ]) table.inner_footing_row_border True print(table.table)_colorize_score()方法使用 ANSI 转义序列实现终端着色无需额外依赖def _colorize_score(self, score: float) - str: if score 0.9: return f\033[91m{score:.3f}\033[0m # 红色 elif score 0.7: return f\033[93m{score:.3f}\033[0m # 黄色 else: return f{score:.3f} # 默认白色提示若你的终端不支持 ANSI 颜色如某些 Windows CMD可临时关闭着色在config.ini中添加color_enabled falserenderer.py会自动降级为纯文本。4. 避坑五个真实踩过的坑与血泪修复方案含日志片段与修复命令部署和运行过程中以下五个坑出现频率最高。它们不是文档遗漏而是 real-world 环境与理想假设的必然摩擦。每个坑都附带可复现的日志现象、根因分析和一行修复命令。4.1 现象main.py启动后立即报错ModuleNotFoundError: No module named terminaltables原因requirements.txt中terminaltables3.1.1依赖未正确安装。常见于 pip 版本 21.3 的旧环境pip install -r requirements.txt会跳过terminaltables因其在 PyPI 上被标记为yanked版本但项目实际兼容。解决pip install terminaltables3.1.1 --force-reinstall注意不要升级到 3.2.0新版 API 不兼容SingleTable接口会导致renderer.py报AttributeError: AsciiTable object has no attribute inner_footing_row_border。4.2 现象check_conf.py通过但main.py运行时file_log.log中持续刷Parse error on line ...且无任何输出表格原因日志文件编码为 GBK常见于 Windows 环境下导出的 IIS 日志而lib/io.py的LogReader默认按 UTF-8 解码line.encode(utf-8).decode(utf-8)失败后触发except返回None导致后续feature_engineer输入为空。解决强制指定编码。编辑main.py在LogReader初始化处添加encoding参数# 修改前第 42 行附近 reader LogReader(config.get(log_source, log_path)) # 修改后 reader LogReader(config.get(log_source, log_path), encodinggbk)然后重新运行python main.py。若不确定编码可先用file -i your_log.log命令探测。4.3 现象main.py运行后终端卡住top显示 Python 进程 CPU 占用 100%train_log.log无新日志原因config.ini中log_path ./conf/*.log匹配到一个 2GB 的压缩日志文件如access.log.gzLogReader尝试一次性读入内存解压触发 OOM Killer。解决禁止 glob 匹配压缩文件。修改config.ini[log_source] # 原来log_path ./conf/*.log # 改为显式列出或用排除模式需 Python 3.10 log_path ./conf/access.log,./conf/error.log # 或推荐在 conf/ 目录下只放解压后的 .log 文件删掉 .gz/.zip并确保conf/下无大体积压缩包。4.4 现象main.py输出表格中IP (Location)列全为??, ??, ??且train_log.log有GeoIP lookup failed for 1.1.1.1原因lib/geoip.py内置的 GeoLite2 数据库lib/geoip/GeoLite2-City.mmdb已过期。MaxMind 自 2022 年起要求 API Key 才能下载新数据库而项目内置的是 2021 年版本对新 IP 段如 Cloudflare 173.245.48.0/20无记录。解决手动更新数据库。访问 https://dev.maxmind.com/geoip/geolite2-free-geolocation-data 需注册免费账号下载GeoLite2-City.mmdb替换项目中的lib/geoip/GeoLite2-City.mmdb。注意不要用mmdb命令行工具转换格式必须下载原生.mmdb文件。4.5 现象main.py运行后输出No risky requests detected但你知道日志里有明显 SQLi如id1 OR 11原因config.ini中risk_threshold 0.85过高而你的测试日志中攻击样本的anomaly_score普遍在 0.75~0.82 区间因特征工程未充分激活uri_param_count和uri_contains_php。解决降低阈值并验证。先用测试集校准# 1. 用 test_black_log.txt 单独跑检测看分数分布 python main.py --log-path ./conf/test_black_log.txt --no-render # 2. 查看 train_log.log 最后 10 行找到 scores 数组 # 3. 取 95% 分位数作为新阈值例如0.78然后修改config.ini[output] risk_threshold 0.78重启main.py。记住阈值不是固定值需随你的日志样本分布动态调整。5. 进阶技巧用 train.txt 快速重训模型让检测器适配你的业务日志特征train.txt是项目预留的“模型热更新”接口。它不是用来训练全新模型而是对已加载的IsolationForestModel进行增量微调incremental update让检测器快速适应你业务特有的日志模式——比如你新增了 GraphQL 接口/graphql路径下的高频 POST 请求会被原始模型误判为异常这时只需提供 200 条正常/graphql请求日志就能让模型学会“这是合法流量”。5.1 train.txt 的格式规范与生成脚本train.txt必须是标准 combined 格式日志且必须包含你业务中典型的“正常”请求样本非攻击样本。格式示例192.168.1.100 - - [10/Oct/2023:10:00:00 0000] POST /graphql HTTP/1.1 200 1234 - Mozilla/5.0 (X11; Linux x86_64) 192.168.1.101 - - [10/Oct/2023:10:00:01 0000] POST /graphql HTTP/1.1 200 567 - curl/7.68.0 ...共 200 行。生成脚本gen_train_sample.py#!/usr/bin/env python3 # 从你的生产日志中抽取 200 条 /graphql 正常请求 import re import random def extract_graphql_normal(log_file: str, output_file: str, count: int 200): pattern rPOST /graphql HTTP/1\.1 200 \d matches [] with open(log_file, r, encodingutf-8) as f: for line in f: if re.search(pattern, line): matches.append(line.strip()) # 随机采样避免时间序列偏差 sampled random.sample(matches, min(count, len(matches))) with open(output_file, w, encodingutf-8) as f: f.write(\n.join(sampled)) print(fGenerated {len(sampled)} lines to {output_file}) if __name__ __main__: extract_graphql_normal(./prod_logs/access.log, ./conf/train.txt)5.2 三步完成模型微调从数据准备到效果验证Step 1准备 train.txt 并放置到 conf/ 目录确保./conf/train.txt存在且内容为上述格式。若conf/目录不存在先创建mkdir -p ./conf。Step 2修改 config.ini 启用微调[model] # 添加这一行指向你的训练样本 train_data_path ./conf/train.txt # 保持原有参数 algorithm isolation_forest n_estimators 100 contamination 0.01Step 3执行微调命令# --retrain 参数触发增量训练不重新加载整个日志 python main.py --retrain成功输出✅ Loaded 200 samples from ./conf/train.txt ✅ Feature engineering completed (12 dims) ✅ Model incremental update done: new contamination estimate 0.0082 → New model saved to ./logs/model_iforest.pkl注意--retrain不会清空历史检测记录只更新模型权重。./logs/model_iforest.pkl是序列化后的模型文件下次main.py启动时自动加载。5.3 效果验证用 test_white_log.txt 对比微调前后差异test_white_log.txt是项目自带的“白样本”测试集200 条典型正常请求。微调后应观察到微调前test_white_log.txt中/graphql请求的anomaly_score平均值为 0.65接近阈值易误报微调后同一请求的anomaly_score平均值降至 0.32远离阈值稳定为正常。验证脚本verify_retrain.pyimport numpy as np from machine_learning.model import IsolationForestModel from lib.io import LogReader # 加载微调后模型 model IsolationForestModel() model.load(./logs/model_iforest.pkl) # load 方法需在 model.py 中实现 # 读取白样本 reader LogReader(./conf/test_white_log.txt) features [] for record in reader.read(): if record and record.get(uri) /graphql: vec build_feature_vector(record) # 调用 feature_engineer.py 中函数 features.append(vec) features np.array(features) # 预测 scores model.predict_score(features) print(fGraphQL white samples: count{len(scores)}, mean_score{np.mean(scores):.3f}, std{np.std(scores):.3f})运行python verify_retrain.py对比微调前后的mean_score。若下降幅度 0.1说明样本量不足或特征未覆盖关键维度需补充更多/graphql样本。从那以后我每次给客户部署这个工具都会强制走一遍gen_train_sample.py → python main.py --retrain → python verify_retrain.py三步验证。哪怕只是多花 5 分钟也能避免上线后被误报淹没——毕竟日志分析的价值不在“发现多少异常”而在“让真正危险的异常浮出水面”。希望帮到你。本文还有配套的精品资源点击获取