sublime text 仅是代码编辑器，不能用于日志采集、实时过滤或异常监测；它只支持编辑脚本、查看采样日志和比对输出结果，所有运行时功能需依赖外部程序执行。
Sublime Text 本身不支持日志采集，别把它当运行环境用
Sublime Text 是编辑器，不是执行引擎。它没有网络能力、不能监听端口、无法读取实时日志流，更不提供 syslog 或 tail -f 级别的文件监控机制。试图在 Sublime 里“开发分布式日志采集工具”，本质是混淆了「编辑」和「运行」两个阶段。你真正需要的是：用 Python/Go/Rust 写采集器，用 Sublime 编辑代码——仅此而已。
关键词过滤必须在采集端做，而不是靠 Sublime 的 Find 功能
有人想用 Sublime 的 Ctrl+F 或正则查找来“过滤关键词”，这只能处理静态快照，对持续写入的 /var/log/nginx/access.log 或 Kafka 日志主题完全无效。实时过滤必须由采集程序完成：
- 用
re.search(r"error|50[0-9]|timeout", line)在每行解析时判断（Python 示例） - 避免把整条日志加载进内存再匹配；应逐行读取 + 流式判断
- 注意编码：日志可能是
utf-8、latin-1，甚至混合编码，open(..., errors="ignore")比崩溃更实用 - 正则不要写成
.*error.*—— 回溯爆炸会让吞吐骤降；用原子组或锚点优化，比如(?:error|ERROR)
异常流量监测依赖时间窗口统计，Sublime 无时间感知能力
所谓“异常流量”，通常指单位时间请求数突增（如 1 秒内超 1000 次）、状态码分布偏移（如 429 比例从 0.1% 升至 15%）、或 IP 请求频次超标。这些都需要：
- 一个带滑动窗口的计数器（如 Python 的
collections.deque或 Redis 的ZSET） - 固定间隔的聚合逻辑（如每 10 秒计算一次 QPS），不是靠人工打开 Sublime 看日志滚动
- 基线数据支撑：昨天同一时段的均值、P95 延迟等，Sublime 无法存储或对比历史
- 告警触发后要发 HTTP 请求或写 Kafka，这超出编辑器职责边界
真正在 Sublime 里能做的只有三件事
如果你坚持用 Sublime 配合日志采集开发，它只适合承担以下角色：
- 编辑采集脚本：比如维护
log_collector.py，配置项写在config.yaml里，Sublime 能高亮、跳转、多光标改参数 - 查看采样日志：用
Ctrl+Shift+P → "Open File..."加载临时sample.log，配合Ctrl+R快速定位函数入口 - 比对输出结果：把采集器输出的 JSON 和预期结构并排打开，用
Ctrl+Shift+2分屏，肉眼核对字段是否缺失
所有涉及“分布式”“实时”“监测”的动作，都发生在你保存文件后手动执行的 python log_collector.py 或容器里跑的 ./collector --nodes=3 过程中。Sublime 不参与其中任何一环。
