简介这是一份面向安全运维人员与Python学习者的Web日志审计工具源码包聚焦在终端环境下快速完成日志排查与恶意请求识别。项目将访问量统计、日志审查、请求统计与机器学习异常检测整合到命令行界面并借助终端图形化输出降低阅读门槛适合具备Python 3.6基础、希望理解日志分析与机器学习落地流程的开发者。压缩包共63个文件约10.58MB以35个py源码文件为核心辅以17张jpg界面截图、4个txt样本与说明、2个ini配置文件及日志文件结构上分为bin、lib、machine_learning、conf、thirdparty等模块便于按功能定位代码。资源已有832人学习读者可获取完整的命令行审计实现、配置检测脚本、白名单与黑名单样本集以及机器学习模块的训练与识别思路既能直接运行体验统计与检测效果也可作为二次开发或课程设计的参考。1. 从一堆 Nginx access.log 里挖出异常这套 Python 工具到底解决什么问题凌晨两点被告警叫醒打开服务器一看Nginx 的 access.log 已经滚到 3 个 Ggrep 一条可疑 IP 要等十几秒肉眼翻页翻到怀疑人生。这不是段子是很多运维和后台开发都经历过的场景。基于机器学习的 Web 日志统计分析与异常检测工具要干的事就是把这件事自动化把原始日志解析成结构化数据做访问量、状态码、UA、URL 维度的统计再用无监督模型把「和大多数请求长得不一样」的那些记录挑出来。它适合三类人手里有 Web 服务日志但只会 grep 的运维、想入门异常检测但缺真实数据集的算法新手、以及需要给现有监控加一层「未知威胁兜底」的后端工程师。Python 生态里 pandas scikit-learn 就能跑通全流程不需要 GPU一台 2 核 4G 的机器足够处理百万级日志。2. 日志解析与特征工程把非结构化文本变成模型能吃的矩阵2.1 为什么不能直接把日志行丢给模型原始 access.log 一行长这样192.168.1.10 - - [12/Mar/2024:10:23:45 0800] GET /api/user?id1 HTTP/1.1 200 1024 - Mozilla/5.0。这是纯文本模型看不懂。常见做法是用正则把每一行拆成字段再对字段做数值化或编码。这里有个容易翻车的点日志格式不是永远一致的Nginx 默认 combined 格式和自定义 log_format 输出的字段顺序、分隔符都可能不同正则写死会导致解析率骤降。我一般会先统计解析成功率低于 95% 就说明正则要改。import re import pandas as pd # Nginx combined 格式正则命名分组方便后续取字段 LOG_PATTERN re.compile( r(?Pip\S) \S \S \[(?Ptime[^\]])\] r(?Pmethod\S) (?Purl\S) \S r(?Pstatus\d{3}) (?Pbytes\d|-) r(?Preferer[^]*) (?Pua[^]*) ) def parse_line(line): m LOG_PATTERN.match(line) if not m: return None d m.groupdict() d[bytes] int(d[bytes]) if d[bytes] ! - else 0 d[status] int(d[status]) return d def load_logs(path): rows [] with open(path, r, encodingutf-8, errorsignore) as f: for line in f: r parse_line(line) if r: rows.append(r) df pd.DataFrame(rows) df[time] pd.to_datetime(df[time], format%d/%b/%Y:%H:%M:%S %z, errorscoerce) return df这段代码的关键在errorsignore和errorscoerce日志里混入二进制或编码异常的行很常见直接抛异常会让整个解析中断。bytes字段的-要转成 0否则后面做数值统计会报类型错误。解析完成后建议打印len(df)和原始行数对比确认没有大面积丢行。2.2 从字段到特征哪些维度真正有区分度解析完只是第一步模型需要的是数值特征。Web 日志异常检测里真正有用的特征通常分四类请求频率类单 IP 每分钟请求数、行为类URL 长度、参数个数、请求方法分布、响应类状态码、响应字节数、时间类请求间隔方差、是否集中在深夜。这里要提醒一句特征不是越多越好我见过有人把 IP 直接 one-hot 编码成几千维结果模型只记住了 IP 没学到行为换一批日志就废了。import numpy as np def build_features(df): df df.sort_values(time).reset_index(dropTrue) # 单 IP 请求频率按 IP 分组后计算相邻请求时间差 df[gap] df.groupby(ip)[time].diff().dt.total_seconds().fillna(0) # URL 长度和参数个数 df[url_len] df[url].str.len() df[param_cnt] df[url].str.count() df[url].str.count() # 状态码是否异常4xx/5xx 标记为 1 df[is_error] df[status].apply(lambda s: 1 if s 400 else 0) # 响应字节数取对数压缩长尾 df[log_bytes] np.log1p(df[bytes]) # 请求小时捕捉深夜异常 df[hour] df[time].dt.hour feat_cols [gap, url_len, param_cnt, is_error, log_bytes, hour] return df, feat_colsgap这个特征对 CC 攻击类异常特别敏感因为攻击流量往往间隔极短且均匀。log_bytes取对数是因为正常请求字节数从几百到几兆都有不压缩的话方差太大会淹没其他特征。hour用原始小时值而不是 one-hot是为了让模型能感知「凌晨 3 点」和「下午 3 点」的差异如果业务本身夜间也有正常流量这个特征权重会被模型自动调低。3. 无监督异常检测Isolation Forest 与统计基线怎么配合3.1 为什么选 Isolation Forest 而不是聚类异常检测算法很多K-Means、DBSCAN、One-Class SVM、Isolation Forest 各有适用场景。Web 日志的特点是异常样本极少、异常类型未知、特征维度中等6-20 维。K-Means 需要指定簇数且对异常点不敏感DBSCAN 对密度参数 eps 极其敏感One-Class SVM 在样本量大时训练慢。Isolation Forest 的优势在于不需要标签、对高维数据友好、训练复杂度接近线性、对异常点的定义就是「容易被孤立的点」和日志场景天然契合。我一般会先用 Isolation Forest 跑一版再用统计基线比如 3-sigma做交叉验证两者都标异常的才重点排查。from sklearn.ensemble import IsolationForest from sklearn.preprocessing import StandardScaler def detect_anomaly(df, feat_cols, contamination0.01): X df[feat_cols].values # 标准化Isolation Forest 对尺度不敏感但标准化后更稳定 scaler StandardScaler() X_scaled scaler.fit_transform(X) # contamination 是预期异常比例根据业务调整 model IsolationForest( n_estimators100, max_samplesauto, contaminationcontamination, random_state42, n_jobs-1 ) df[anomaly] model.fit_predict(X_scaled) # -1 异常1 正常 df[score] model.decision_function(X_scaled) # 分数越低越异常 return df, modelcontamination是最关键的参数。设太大比如 0.1会误报一堆正常请求设太小0.001会漏掉真正的攻击。我的经验值是先按 0.01 跑然后看 score 的分布如果 -0.1 以下的数量远小于 1%说明可以调低如果 0 附近就有一堆点说明特征区分度不够要回去改特征。n_estimators100是精度和速度的平衡点日志量超过千万级可以降到 50。random_state固定是为了复现生产环境可以去掉。3.2 统计基线3-sigma 和 IQR 作为兜底机器学习模型有个黑匣子问题它说某条记录异常但你不知道为什么。统计基线的好处是可解释。对每个数值特征单独算均值和标准差超过 3 倍标准差的标记为统计异常。IQR 方法更鲁棒用四分位距代替标准差适合有极端值的数据。def stat_baseline(df, col, k3): mean df[col].mean() std df[col].std() df[f{col}_stat_anomaly] ((df[col] - mean).abs() k * std).astype(int) return df def iqr_baseline(df, col): q1 df[col].quantile(0.25) q3 df[col].quantile(0.75) iqr q3 - q1 lower q1 - 1.5 * iqr upper q3 1.5 * iqr df[f{col}_iqr_anomaly] ((df[col] lower) | (df[col] upper)).astype(int) return df实际使用时我会把 Isolation Forest 的 anomaly 和统计基线的 anomaly 做交集两者都判异常的记录置信度最高优先人工核查只有模型判异常的作为二级告警只有统计判异常的作为观察项。这样能把误报率压下来。注意k3对应正态分布下约 99.7% 的覆盖率如果日志本身分布严重偏斜改用 IQR 更合适。4. 避坑与排查日志异常检测里最容易翻车的 5 个地方4.1 现象模型把所有深夜请求都标成异常原因hour特征在训练集里深夜样本极少模型把「深夜」等同于「罕见」但业务上深夜可能有正常的定时任务或海外用户。解决要么把hour从特征里去掉改用「该 IP 历史同时段请求频率」这种相对特征要么在训练时对深夜样本做加权让模型知道深夜也有正常流量。4.2 现象解析成功率只有 70%大量行被丢弃原因日志里混了其他格式的行比如健康检查、内部调用、或者 Nginx error.log 被误合并进来。解决先跑一遍解析把失败的行单独输出到文件肉眼看几条就知道是什么格式。常见做法是加多个正则按优先级匹配或者用 Grok 模式做兜底。别小看这一步解析率低意味着你的统计和检测都建立在残缺数据上。4.3 现象Isolation Forest 训练报内存错误原因日志量太大一次性把几千万行读进 DataFrame特征矩阵撑爆内存。解决分块读取用pd.read_csv(chunksize100000)或者手动按行流式处理每块算完特征后只保留异常分数和关键字段正常记录直接丢弃。Isolation Forest 支持warm_start可以增量训练但要注意max_samples的设置。4.4 现象同一批数据两次跑结果不一样原因Isolation Forest 的random_state没固定或者特征里有随机性比如用了train_test_split没设种子。解决所有涉及随机的步骤都固定random_state包括模型初始化、数据划分、采样。生产环境如果要求结果稳定还要把训练好的模型用 joblib 持久化推理时加载同一个模型。4.5 现象异常分数全是 0分不出高低原因特征尺度差异太大某个特征比如 bytes 原始值主导了距离计算其他特征被淹没。解决标准化是必须的StandardScaler或RobustScaler都行。如果标准化后还是分不出检查是不是特征之间高度相关比如url_len和param_cnt相关性超过 0.9可以删掉一个。另外decision_function返回的是相对分数如果所有点都在 0 附近说明数据本身没有明显异常或者 contamination 设得太高。5. 从跑通到好用阈值调优、可视化与增量更新5.1 用业务反馈调阈值而不是拍脑袋contamination0.01只是起点。真正好用的阈值来自业务反馈把模型判异常的记录导出让运维或安全同学标注「确实是攻击」还是「误报」积累几十条后就能算准确率和召回率。如果误报太多调低 contamination如果漏报太多调高。我一般会做一个简单的阈值扫描看不同 contamination 下异常数量的变化曲线拐点附近就是比较合适的值。import matplotlib.pyplot as plt def scan_contamination(df, feat_cols, values): results [] for c in values: _, model detect_anomaly(df.copy(), feat_cols, contaminationc) n_anomaly (df[anomaly] -1).sum() results.append((c, n_anomaly)) # 画曲线找拐点 cs, ns zip(*results) plt.plot(cs, ns, markero) plt.xlabel(contamination) plt.ylabel(anomaly count) plt.title(Contamination vs Anomaly Count) plt.show() return results这条曲线通常先陡后平contamination 从 0.001 增到 0.01 时异常数快速上升超过 0.02 后趋于平缓说明真正的异常点就那么多再调高只是把正常点也拉进来。拐点位置就是推荐值。5.2 可视化让非技术同学也能看懂异常检测结果如果只输出一个 CSV运维同学不会看。常见做法是画两张图一张是按小时的请求量折线图异常点用红点标出另一张是异常 IP 的 TOP 10 柱状图。这样一眼就能看出「凌晨 3 点有个 IP 请求了 5 万次」这种明显异常。def plot_anomaly_timeline(df): df[minute] df[time].dt.floor(5min) grouped df.groupby(minute).agg( total(ip, count), anomaly(anomaly, lambda x: (x -1).sum()) ).reset_index() plt.figure(figsize(14, 5)) plt.plot(grouped[minute], grouped[total], labeltotal, alpha0.6) plt.scatter(grouped[minute], grouped[anomaly], colorred, labelanomaly, s10) plt.legend() plt.title(Request Volume with Anomalies) plt.xticks(rotation45) plt.tight_layout() plt.show()按 5 分钟聚合是为了平滑噪声如果日志量小可以改成 1 分钟。红色散点如果集中在某个时间段基本就能锁定攻击窗口。5.3 增量更新别每次都全量重训生产环境日志是持续产生的每天全量重训既慢又没必要。我的习惯是首次用最近 7 天数据训练一个基线模型之后每天用新数据做推理同时把新数据里置信度高的正常样本加入训练集每周重训一次。这样模型能适应业务变化又不会因为某天的突发流量把基线带偏。Isolation Forest 本身不支持在线学习但可以用warm_startTrue配合max_samples做近似增量或者干脆用 River 这类流式异常检测库。最后说个血泪教训别一上来就追求复杂模型。我见过有人用 Autoencoder 做日志异常检测调参调了两周效果还不如 Isolation Forest 加几个手工特征。先把解析、特征、基线跑通再考虑上深度学习。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 16:55:57 · 阅读 1.2k 基于机器学习的Web日志异常检测：Python实战Nginx access.log分析
简介这是一份面向安全运维人员与Python学习者的Web日志审计工具源码包聚焦在终端环境下快速完成日志排查与恶意请求识别。项目将访问量统计、日志审查、请求统计与机器学习异常检测整合到命令行界面并借助终端图形化输出降低阅读门槛适合具备Python 3.6基础、希望理解日志分析与机器学习落地流程的开发者。压缩包共63个文件约10.58MB以35个py源码文件为核心辅以17张jpg界面截图、4个txt样本与说明、2个ini配置文件及日志文件结构上分为bin、lib、machine_learning、conf、thirdparty等模块便于按功能定位代码。资源已有832人学习读者可获取完整的命令行审计实现、配置检测脚本、白名单与黑名单样本集以及机器学习模块的训练与识别思路既能直接运行体验统计与检测效果也可作为二次开发或课程设计的参考。1. 从一堆 Nginx access.log 里挖出异常这套 Python 工具到底解决什么问题凌晨两点被告警叫醒打开服务器一看Nginx 的 access.log 已经滚到 3 个 Ggrep 一条可疑 IP 要等十几秒肉眼翻页翻到怀疑人生。这不是段子是很多运维和后台开发都经历过的场景。基于机器学习的 Web 日志统计分析与异常检测工具要干的事就是把这件事自动化把原始日志解析成结构化数据做访问量、状态码、UA、URL 维度的统计再用无监督模型把「和大多数请求长得不一样」的那些记录挑出来。它适合三类人手里有 Web 服务日志但只会 grep 的运维、想入门异常检测但缺真实数据集的算法新手、以及需要给现有监控加一层「未知威胁兜底」的后端工程师。Python 生态里 pandas scikit-learn 就能跑通全流程不需要 GPU一台 2 核 4G 的机器足够处理百万级日志。2. 日志解析与特征工程把非结构化文本变成模型能吃的矩阵2.1 为什么不能直接把日志行丢给模型原始 access.log 一行长这样192.168.1.10 - - [12/Mar/2024:10:23:45 0800] GET /api/user?id1 HTTP/1.1 200 1024 - Mozilla/5.0。这是纯文本模型看不懂。常见做法是用正则把每一行拆成字段再对字段做数值化或编码。这里有个容易翻车的点日志格式不是永远一致的Nginx 默认 combined 格式和自定义 log_format 输出的字段顺序、分隔符都可能不同正则写死会导致解析率骤降。我一般会先统计解析成功率低于 95% 就说明正则要改。import re import pandas as pd # Nginx combined 格式正则命名分组方便后续取字段 LOG_PATTERN re.compile( r(?Pip\S) \S \S \[(?Ptime[^\]])\] r(?Pmethod\S) (?Purl\S) \S r(?Pstatus\d{3}) (?Pbytes\d|-) r(?Preferer[^]*) (?Pua[^]*) ) def parse_line(line): m LOG_PATTERN.match(line) if not m: return None d m.groupdict() d[bytes] int(d[bytes]) if d[bytes] ! - else 0 d[status] int(d[status]) return d def load_logs(path): rows [] with open(path, r, encodingutf-8, errorsignore) as f: for line in f: r parse_line(line) if r: rows.append(r) df pd.DataFrame(rows) df[time] pd.to_datetime(df[time], format%d/%b/%Y:%H:%M:%S %z, errorscoerce) return df这段代码的关键在errorsignore和errorscoerce日志里混入二进制或编码异常的行很常见直接抛异常会让整个解析中断。bytes字段的-要转成 0否则后面做数值统计会报类型错误。解析完成后建议打印len(df)和原始行数对比确认没有大面积丢行。2.2 从字段到特征哪些维度真正有区分度解析完只是第一步模型需要的是数值特征。Web 日志异常检测里真正有用的特征通常分四类请求频率类单 IP 每分钟请求数、行为类URL 长度、参数个数、请求方法分布、响应类状态码、响应字节数、时间类请求间隔方差、是否集中在深夜。这里要提醒一句特征不是越多越好我见过有人把 IP 直接 one-hot 编码成几千维结果模型只记住了 IP 没学到行为换一批日志就废了。import numpy as np def build_features(df): df df.sort_values(time).reset_index(dropTrue) # 单 IP 请求频率按 IP 分组后计算相邻请求时间差 df[gap] df.groupby(ip)[time].diff().dt.total_seconds().fillna(0) # URL 长度和参数个数 df[url_len] df[url].str.len() df[param_cnt] df[url].str.count() df[url].str.count() # 状态码是否异常4xx/5xx 标记为 1 df[is_error] df[status].apply(lambda s: 1 if s 400 else 0) # 响应字节数取对数压缩长尾 df[log_bytes] np.log1p(df[bytes]) # 请求小时捕捉深夜异常 df[hour] df[time].dt.hour feat_cols [gap, url_len, param_cnt, is_error, log_bytes, hour] return df, feat_colsgap这个特征对 CC 攻击类异常特别敏感因为攻击流量往往间隔极短且均匀。log_bytes取对数是因为正常请求字节数从几百到几兆都有不压缩的话方差太大会淹没其他特征。hour用原始小时值而不是 one-hot是为了让模型能感知「凌晨 3 点」和「下午 3 点」的差异如果业务本身夜间也有正常流量这个特征权重会被模型自动调低。3. 无监督异常检测Isolation Forest 与统计基线怎么配合3.1 为什么选 Isolation Forest 而不是聚类异常检测算法很多K-Means、DBSCAN、One-Class SVM、Isolation Forest 各有适用场景。Web 日志的特点是异常样本极少、异常类型未知、特征维度中等6-20 维。K-Means 需要指定簇数且对异常点不敏感DBSCAN 对密度参数 eps 极其敏感One-Class SVM 在样本量大时训练慢。Isolation Forest 的优势在于不需要标签、对高维数据友好、训练复杂度接近线性、对异常点的定义就是「容易被孤立的点」和日志场景天然契合。我一般会先用 Isolation Forest 跑一版再用统计基线比如 3-sigma做交叉验证两者都标异常的才重点排查。from sklearn.ensemble import IsolationForest from sklearn.preprocessing import StandardScaler def detect_anomaly(df, feat_cols, contamination0.01): X df[feat_cols].values # 标准化Isolation Forest 对尺度不敏感但标准化后更稳定 scaler StandardScaler() X_scaled scaler.fit_transform(X) # contamination 是预期异常比例根据业务调整 model IsolationForest( n_estimators100, max_samplesauto, contaminationcontamination, random_state42, n_jobs-1 ) df[anomaly] model.fit_predict(X_scaled) # -1 异常1 正常 df[score] model.decision_function(X_scaled) # 分数越低越异常 return df, modelcontamination是最关键的参数。设太大比如 0.1会误报一堆正常请求设太小0.001会漏掉真正的攻击。我的经验值是先按 0.01 跑然后看 score 的分布如果 -0.1 以下的数量远小于 1%说明可以调低如果 0 附近就有一堆点说明特征区分度不够要回去改特征。n_estimators100是精度和速度的平衡点日志量超过千万级可以降到 50。random_state固定是为了复现生产环境可以去掉。3.2 统计基线3-sigma 和 IQR 作为兜底机器学习模型有个黑匣子问题它说某条记录异常但你不知道为什么。统计基线的好处是可解释。对每个数值特征单独算均值和标准差超过 3 倍标准差的标记为统计异常。IQR 方法更鲁棒用四分位距代替标准差适合有极端值的数据。def stat_baseline(df, col, k3): mean df[col].mean() std df[col].std() df[f{col}_stat_anomaly] ((df[col] - mean).abs() k * std).astype(int) return df def iqr_baseline(df, col): q1 df[col].quantile(0.25) q3 df[col].quantile(0.75) iqr q3 - q1 lower q1 - 1.5 * iqr upper q3 1.5 * iqr df[f{col}_iqr_anomaly] ((df[col] lower) | (df[col] upper)).astype(int) return df实际使用时我会把 Isolation Forest 的 anomaly 和统计基线的 anomaly 做交集两者都判异常的记录置信度最高优先人工核查只有模型判异常的作为二级告警只有统计判异常的作为观察项。这样能把误报率压下来。注意k3对应正态分布下约 99.7% 的覆盖率如果日志本身分布严重偏斜改用 IQR 更合适。4. 避坑与排查日志异常检测里最容易翻车的 5 个地方4.1 现象模型把所有深夜请求都标成异常原因hour特征在训练集里深夜样本极少模型把「深夜」等同于「罕见」但业务上深夜可能有正常的定时任务或海外用户。解决要么把hour从特征里去掉改用「该 IP 历史同时段请求频率」这种相对特征要么在训练时对深夜样本做加权让模型知道深夜也有正常流量。4.2 现象解析成功率只有 70%大量行被丢弃原因日志里混了其他格式的行比如健康检查、内部调用、或者 Nginx error.log 被误合并进来。解决先跑一遍解析把失败的行单独输出到文件肉眼看几条就知道是什么格式。常见做法是加多个正则按优先级匹配或者用 Grok 模式做兜底。别小看这一步解析率低意味着你的统计和检测都建立在残缺数据上。4.3 现象Isolation Forest 训练报内存错误原因日志量太大一次性把几千万行读进 DataFrame特征矩阵撑爆内存。解决分块读取用pd.read_csv(chunksize100000)或者手动按行流式处理每块算完特征后只保留异常分数和关键字段正常记录直接丢弃。Isolation Forest 支持warm_start可以增量训练但要注意max_samples的设置。4.4 现象同一批数据两次跑结果不一样原因Isolation Forest 的random_state没固定或者特征里有随机性比如用了train_test_split没设种子。解决所有涉及随机的步骤都固定random_state包括模型初始化、数据划分、采样。生产环境如果要求结果稳定还要把训练好的模型用 joblib 持久化推理时加载同一个模型。4.5 现象异常分数全是 0分不出高低原因特征尺度差异太大某个特征比如 bytes 原始值主导了距离计算其他特征被淹没。解决标准化是必须的StandardScaler或RobustScaler都行。如果标准化后还是分不出检查是不是特征之间高度相关比如url_len和param_cnt相关性超过 0.9可以删掉一个。另外decision_function返回的是相对分数如果所有点都在 0 附近说明数据本身没有明显异常或者 contamination 设得太高。5. 从跑通到好用阈值调优、可视化与增量更新5.1 用业务反馈调阈值而不是拍脑袋contamination0.01只是起点。真正好用的阈值来自业务反馈把模型判异常的记录导出让运维或安全同学标注「确实是攻击」还是「误报」积累几十条后就能算准确率和召回率。如果误报太多调低 contamination如果漏报太多调高。我一般会做一个简单的阈值扫描看不同 contamination 下异常数量的变化曲线拐点附近就是比较合适的值。import matplotlib.pyplot as plt def scan_contamination(df, feat_cols, values): results [] for c in values: _, model detect_anomaly(df.copy(), feat_cols, contaminationc) n_anomaly (df[anomaly] -1).sum() results.append((c, n_anomaly)) # 画曲线找拐点 cs, ns zip(*results) plt.plot(cs, ns, markero) plt.xlabel(contamination) plt.ylabel(anomaly count) plt.title(Contamination vs Anomaly Count) plt.show() return results这条曲线通常先陡后平contamination 从 0.001 增到 0.01 时异常数快速上升超过 0.02 后趋于平缓说明真正的异常点就那么多再调高只是把正常点也拉进来。拐点位置就是推荐值。5.2 可视化让非技术同学也能看懂异常检测结果如果只输出一个 CSV运维同学不会看。常见做法是画两张图一张是按小时的请求量折线图异常点用红点标出另一张是异常 IP 的 TOP 10 柱状图。这样一眼就能看出「凌晨 3 点有个 IP 请求了 5 万次」这种明显异常。def plot_anomaly_timeline(df): df[minute] df[time].dt.floor(5min) grouped df.groupby(minute).agg( total(ip, count), anomaly(anomaly, lambda x: (x -1).sum()) ).reset_index() plt.figure(figsize(14, 5)) plt.plot(grouped[minute], grouped[total], labeltotal, alpha0.6) plt.scatter(grouped[minute], grouped[anomaly], colorred, labelanomaly, s10) plt.legend() plt.title(Request Volume with Anomalies) plt.xticks(rotation45) plt.tight_layout() plt.show()按 5 分钟聚合是为了平滑噪声如果日志量小可以改成 1 分钟。红色散点如果集中在某个时间段基本就能锁定攻击窗口。5.3 增量更新别每次都全量重训生产环境日志是持续产生的每天全量重训既慢又没必要。我的习惯是首次用最近 7 天数据训练一个基线模型之后每天用新数据做推理同时把新数据里置信度高的正常样本加入训练集每周重训一次。这样模型能适应业务变化又不会因为某天的突发流量把基线带偏。Isolation Forest 本身不支持在线学习但可以用warm_startTrue配合max_samples做近似增量或者干脆用 River 这类流式异常检测库。最后说个血泪教训别一上来就追求复杂模型。我见过有人用 Autoencoder 做日志异常检测调参调了两周效果还不如 Isolation Forest 加几个手工特征。先把解析、特征、基线跑通再考虑上深度学习。希望帮到你。本文还有配套的精品资源点击获取