sublime text 不能直接统计千万行 nginx 日志的 ip 高频特征，因其仅为编辑器，缺乏流式读取、正则控制、时间解析、滑动窗口及多字段提取能力；应使用 awk 或 python 流式处理。
Sublime Text 不能做千万行 Nginx 日志的 IP 高频特征统计——它不是运行环境，连逐行读取大文件都可能卡死或崩溃。
你真正需要的是一个能流式处理、内存可控、支持时间窗口和代理头解析的统计流程，Sublime Text 只能帮你编辑脚本、查看采样片段、比对输出结构。
为什么不能在 Sublime 里直接统计 IP？
Sublime Text 是纯编辑器，没有：
- 文件流式读取能力（打开千万行日志会 OOM）
- 正则回溯控制机制（.*error.* 类写法极易卡死）
- 时间解析函数（无法把 [10/Jan/2024:14:22:05 +0800] 转成 timestamp）
- 滑动窗口计数器（如每 60 秒重置 IP 计数）
- 多字段联合提取逻辑（比如优先取 $http_x_forwarded_for 而非 $remote_addr）
用 awk 快速跑通基础 IP 排行（适合线上应急）
这是最轻量、最可靠、无需安装依赖的方案，适用于大多数默认 log_format combined 的 Nginx 日志：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
但要注意几个坑：
- 如果日志含 IPv6 地址（如
2001:db8::1），$1仍可正确提取，无需改逻辑 - 若启用了反向代理且日志中记录了
$http_x_forwarded_for，该字段在第 12 列左右（取决于log_format），需显式指定列号，例如：awk '{print $12}' - 日志含压缩文件（
.gz）时，不能直接cat，要用zcat access.log.1.gz | awk ... - 千万行下
sort | uniq -c会触发磁盘临时排序，耗时长但内存友好；加-S 512M可提速（GNU sort 支持）
Python 脚本必须绕开的三个典型陷阱
写 Python 统计脚本时，最容易栽在以下三点：
-
编码错误：Nginx 日志可能是
latin-1（尤其含中文 UA 或 referer），用open(..., encoding="utf-8")会报UnicodeDecodeError；应统一用open(..., errors="ignore")或errors="replace" -
IP 提取逻辑硬编码：默认认为首字段是真实 IP，但若 Nginx 启用了
real_ip模块且信任上游代理，真实客户端 IP 实际在$http_x_forwarded_for中（逗号分隔，取第一个非私有地址）；脚本需判断并 fallback -
内存爆炸：用
readlines()加载整份日志到内存，千万行 ≈ 2–3 GB；必须用for line in f:逐行迭代 +collections.Counter流式计数
时间范围过滤必须用 awk，别碰 Python 的 datetime.strptime
对千万行日志做时间段筛选（如“过去一小时”），Python 的 datetime.strptime 解析每行时间戳太慢，CPU 成瓶颈；而 awk 内建时间函数（mktime）+ 字符串切片快得多：
awk -v d1="$(date -d'1 hour ago' +'%d/%b/%Y:%H:%M:%S')" \
'$4 > "["d1 {gsub(/\[/, "", $4); split($4, t, /[/:]/); ts = mktime(t[3]" "t[2]" "t[1]" "t[4]" "t[5]" "t[6]); if (ts > start_ts) print $1}' \
access.log | sort | uniq -c | sort -nr
注意：
- $4 是时间字段（[10/Jan/2024:14:22:05 +0800]），需先 gsub 去掉左括号
- split 按 / 和 : 分割后顺序为：日、月缩写、年、时、分、秒
- mktime 要求格式为 "YYYY MM DD HH MM SS"，所以字段要重排（t[3], t[2], t[1], ...）
真正卡点不在工具选型，而在你是否清楚日志里哪个字段才是你要的真实 IP，以及能否接受“统计结果延迟 30 秒”还是必须“实时滑动窗口”。前者用 awk 就够，后者得上 Redis 或专用流处理系统。
