使用本地LLM构建自动化基础设施日志分析系统 #
AI 每 15 分钟自动分析来自防火墙、认证基础设施、交换机、负载均衡器和 Web 服务器的日志，检测异常、判断严重程度并提出应对建议——全部通过 Slack 通知完成。日志数据绝不会外发。
我们为什么要做这个 #
动机很简单：我们没有时间去查看日志。
BESTNET-CLOUD 运行着多台防火墙、二层/三层交换机、Windows AD、负载均衡器和 Web 服务器。每台设备都会产生 syslog 输出，但让人每天手动查看所有日志是不现实的。我们使用 Zabbix 进行资源监控，但读取 syslog 内容并判断某种攻击模式应忽略还是应处理，这项工作仍然依赖人工。
AWS DevOps Agent（2026 年 3 月正式发布）和 Azure Security Copilot 等服务如今在公有云一侧提供了 AI 驱动的日志分析功能。然而，这些方案主要面向云端资源，缺乏直接解析和分析来自本地物理设备 syslog 的能力。而且，由于日志数据会被传输至云厂商的 AI 基础设施，这些方案无法在封闭网络环境中使用。
于是我们只能自己动手构建。幸运的是，本地 LLM 的性能已经达到了实用水平，所需的全部组件也都能以开源形式获得。
系统架构 #
该系统名为 BASTION——意为堡垒或最后的据点，体现了在封闭网络环境中保护基础设施的愿景。
系统架构非常简单直接。
所使用的组件如下——全部为开源或免费套餐：
| 组件 | 作用 | 许可协议 |
|---|---|---|
| rsyslog | 集中接收来自所有设备的 syslog，按主机分别保存 | OSS（GPL） |
| Shell 脚本套件 | 按设备进行日志汇总、解析、预处理 | 自研开发 |
| OpenClaw | AI 代理框架（LLM 集成、Slack 集成、命令执行） | OSS |
| Qwen2.5-14B | 本地 LLM（日语日志分析、异常检测） | OSS（Apache 2.0） |
| GPUStack | GPU 推理服务器（提供与 OpenAI 兼容的 API） | OSS |
| Slack（Socket Mode） | 通知与双向交互 | 免费套餐 |
数据流详解 #
1. 日志采集（rsyslog） #
通过 UDP/TCP 514 端口接收各设备的 syslog，并按主机名、年份、月份和程序名分目录存储。
/var/log/remote/ fw-primary/2026/04/filterlog.log ad-server/2026/04/Security-Auditing.log lb-server/2026/04/loadbalancer.log ...
2. 日志汇总（summarize.sh） #
每 15 分钟由 cron 执行一次 summarize.sh，从各设备中提取过去 30 分钟的事件，并生成结构化的文本摘要。
由于各设备的日志格式完全不同，解析逻辑需要按设备单独编写。例如，防火墙的 filterlog 使用逗号分隔字段，源 IP 位于第 19 个字段，目标端口位于第 22 个字段。Windows AD 日志包含二进制数据，需要使用 grep -a。这些嵌入脚本中的设备专属知识正是本系统的核心工作所在。
3. AI 分析（analyze.sh） #
摘要文本通过 OpenClaw 提交给本地 LLM（Qwen2.5-14B）。提示词要求它：“判断严重程度，并以 JSON 格式返回检测到的异常和推荐的应对措施。”
这里应用了两个关键设计决策。
会话隔离：每次分析都会生成一个动态会话 ID，防止过去的对话历史污染上下文。LLM 容易受到先前结果的影响而导致判断出现偏差，因此我们确保每次分析都拥有全新的上下文。
误报控制：正常运行模式（Nextcloud LDAP 定期认证、Kerberos 自动认证、防火墙对外部扫描的拦截等）被定义在系统提示词中，为 LLM 提供排除标准，将其视为噪声。我们会在运维过程中不断迭代添加这些模式。
4. 通知（notify.sh） #
LLM 分析结果会按严重程度用不同颜色发送至 Slack（critical=红色，high=橙色，medium=黄色，low=绿色）。
对于 medium 及以上级别，系统会自动发送第二条详细分析消息。该消息包含原始日志的前 50 行，让运维人员仅凭通知内容即可同时确认“发生了什么”以及原始数据。
5. 交互式分析（Slack 双向交互） #
除定时分析外，在 Slack 中提及 @OpenClaw-Monitor firewall analysis 即可立即触发对指定设备的详细分析。支持诸如“是否有 VPN 认证异常的迹象？”或“检查是否有单个 IP 尝试多种攻击手法”之类的自然语言查询。
由于 OpenClaw 可以执行 bash 命令，未来可扩展至自动化应对——例如动态添加防火墙规则、隔离服务等。
GPU 需求 #
资源消耗出乎意料地小。
| 项目 | 消耗量 |
|---|---|
| 模型（Qwen2.5-14B Q4 量化） | 约 9GB |
| KV 缓存（16K token） | 约 1–2GB |
| 合计 | 约 10–11GB |
支持的设备 #
| 设备类型 | 分析内容 |
|---|---|
| 防火墙 | 攻击拦截次数、攻击源 IP、端口分布、VPN 错误 |
| 认证（AD） | 登录成功/失败/锁定、失败来源 IP、失败账户 |
| 负载均衡器 | 各后端的 5xx 错误率 |
| 二层/三层交换机 | 链路中断、环路、风暴检测 |
| Web 服务器 | HTTP 状态分布、敏感 URL、4xx/5xx 来源 IP |
任何输出 syslog 的设备都可以通过添加解析脚本纳入监控范围。FortiGate、Cisco、Palo Alto 等设备均可通过相同方式支持。
运维经验 #
让 LLM 负责判断，让脚本负责数据处理 #
最初，我们尝试将原始日志直接喂给 LLM，但它会误判 syslog 字段位置，导致计算错误。LLM 不擅长精确的数值汇总。现在，解析、计数和汇总均由 Shell 脚本处理；LLM 仅负责阅读摘要并判断“是否异常？”以及“应采取何种应对措施？”。
误报控制随运维不断完善 #
第一周饱受误报困扰。Kerberos 计算机账户对 AD 的定期认证产生了超过 1,000 条登录成功报告，而 Nextcloud 的 LDAP 集成则被标记为“可疑登录尝试”。将每种模式作为正常行为逐一添加到系统提示词后，大约两周内噪声就被消除了。
会话隔离必不可少 #
如果直接使用会话，先前的分析结果会保留在上下文中，导致 LLM 引入诸如“与上次报告相比……”之类的不必要上下文。安全分析每次都需要以全新视角进行，因此我们为每次分析动态生成会话 ID。
“无事发生”的报告同样有价值 #
最初，频繁的 LOW 级通知感觉很吵。但随着时间推移，我们意识到这些报告其实是在告诉我们“系统运行正常”。当通知停止时，我们便能察觉到“监控本身已经停止”——这正是得益于这些常规报告。
未来计划 #
目前的流程是“检测 → 通知”。我们计划将其扩展为“检测 → AI 判断 → 自动应对”。
具体而言，我们将实现自动封锁攻击源 IP（直接调用防火墙 API）、检测到暴力破解时自动封锁，以及在资源异常使用时自动限流。我们也在探索一种混合方案：让 BASTION 通过 webhook 接收来自现有监控系统（Zabbix、AWS CloudWatch、Azure Monitor）的告警，进行跨系统 AI 分析，并执行自动化应对。
总结 #
我们利用本地 LLM（Qwen2.5-14B）+ GPUStack + OpenClaw + rsyslog + Shell 脚本实现了自动化基础设施日志分析。系统运行在一台 V100 16GB GPU 上，日志数据从不离开该环境，每月运营成本仅为 GPU 电费。
所有组件均为开源，因此任何人都可以复现这套架构。然而，要实现完整运行，还需要针对各设备编写专属的日志解析逻辑、积累误报模式并调优系统提示词——这并非易事，需要相应的运维知识积累。
BASTION 目前正在 BESTNET LLC 自有基础设施（BESTNET-CLOUD）上 24/7 全天候生产运行。
