GitHub 项目推荐dzh-webscan · 网站文件监控系统用 Go Docker 监控网站文件变化通过飞书接收中文告警在 Grafana 中查看节点健康和历史事件。源码、部署脚本及使用文档都可以从仓库查看推荐先从SH 自动部署开始。如果这个项目对你有帮助欢迎点一个Star收藏支持想了解后续更新可以通过Watch按需订阅也欢迎通过Issues反馈问题和需求。项目地址https://github.com/gzdzh-cn/dzh-webscan网站能打开服务器 CPU 也正常网站文件就一定没问题吗假设某个网站的config.php被修改上传目录里多了一个 PHP 文件或者重要配置被删除——如果没有人主动检查你什么时候才能发现很多时候我们监控了服务器的 CPU、内存和磁盘却没有持续关注一个更直接的问题网站里的文件正在发生什么变化这篇文章介绍一套网站文件监控系统在各台服务器上监听文件变化通过飞书发送中文通知再用 Grafana 查看节点健康和历史事件。自研服务使用 Go打包为 Docker 镜像支持通过 SH 脚本统一部署。先看一条消息长什么样。1. PHP 被修改后飞书里能看到什么下面是一条脱敏后的消息示意具体内容以实际配置和事件为准【网站监控】发现文件被修改 服务器网站节点 A198.51.100.20 网站example.com 文件/www/wwwroot/example.com/config/config.php 发生时间2026-10-07 10:30:00北京时间 安全检查等待扫描发现可疑内容会另行通知 处理建议如果不是您或网站程序的正常更新请检查该文件你可以直接知道哪台服务器、哪个网站、哪个文件、发生了什么以及什么时候发生。除了修改系统还会检测新增、删除、移动或改名。符合扫描条件的文件会进入 YARA 扫描流程命中可疑规则时根据通知配置另发消息。这里有个关键区别文件变化通知和安全扫描结果是两件事。“等待扫描”表示还没有结果文件被修改也不等于遭到攻击。正常发布、插件更新和配置调整同样可能触发通知。收到消息后需要结合自己的操作记录判断。2. 多台服务器不用每台单独盯系统分为主服务器和子服务器两类角色每台子服务器监听本机目录核对文件内容扫描可疑代码缓存和上报事件。主服务器集中接收事件、保存记录、发送飞书通知提供 Grafana 查询面板。一次文件变化的主要路径是子服务器文件变化 → Agent 检测 → 本地保存 → Vector 传输 ↓ 主服务器HTTPS 接收 → 去重与保存 → 飞书通知 / Loki 日志 ↓ Grafana 查询扫描与事件传输异步执行所以普通变化通知不必等扫描完成。主服务器给出的接收回执表示事件已经保存飞书和 Loki 是否投递成功则由各自的后台队列继续跟踪。节点断网期间会缓存事件网络恢复后补传文件清单还会定期核对补查实时监听可能遗漏的变化。数据保留期限、磁盘容量和监控中断时间仍然需要合理设置例如停机期间创建后立即删除的文件恢复后未必能补查。3. 真正影响使用体验的是能不能少发无用通知如果把所有文件变化都发进群缓存、临时文件、程序自动生成的内容很快就会淹没有价值的消息。因此这套系统支持监控多个目录、自定义文件后缀、重要文件名、关键文件路径以及使用通配符忽略缓存目录。例如公共规则可以这样写node_defaults:monitor:roots:-/www/wwwrootextensions:-.php-.phtml-.js-.html-.cssexclude_paths:-/www/wwwroot/*/**/runtime/**/cache-/www/wwwroot/*/caches/tempimportant_filenames:-.user.ini-.htaccess这里的*匹配一个路径段**匹配零层或多层目录。匹配到缓存目录后其下的文件和子目录一起忽略不需要为每个网站逐条填写。这些配置片段需要合并到完整 YAML 中。后缀列表要保留所有需要监控的类型忽略规则也应根据实际网站目录设置避免把需要关注的 PHP 文件一起排除。每台子服务器还可以有自己的规则。比如节点 B 除了网站目录还要监控/data/sitesnodes:-id:node-b# 此处省略该节点已有的名称、IP 和 SSH 配置monitor:roots:-/www/wwwroot-/data/sites注意节点列表配置会整体替换继承的列表。要同时监控两个目录就把两个目录都写上。4. 改过滤规则不用每次重启节点在主服务器修改 YAML 后可以下发过滤规则bashdeploy-webscan.sh --reload-rules节点每 5 秒检查规则变化校验通过后应用非法规则保留旧版。忽略路径、后缀和重要文件名等过滤规则可以热更新不需要重建容器。取消忽略时系统先为已有文件建立基线后续变化再正常通知避免把缓存目录里的存量文件都当成刚刚新增。新增监控根目录则涉及容器挂载需要更新对应节点bashdeploy-webscan.sh --add-node--nodenode-b日常使用中先分清修改的是“过滤规则”还是“挂载目录”就能选对更新方式。5. 容器运行着不代表监控真的正常这是做监控很容易忽略的问题。容器状态显示 Running却可能出现目录监听不完整、扫描任务积压、传输中断或者飞书投递失败。因此检查容器之外还需要检查整条链路。Grafana 提供服务器、健康和事件面板可以查看节点在线情况、目录监听覆盖、心跳、扫描与投递队列以及资源使用情况。服务器面板集中查看各节点的资源和运行状态。健康面板结合心跳、覆盖和积压指标检查监控链路。排查问题时可以先按三个问题检查节点是否可达检查指标采集和网络连接。文件变化是否被发现检查心跳、监听覆盖和本地队列。消息是否送达检查主服务器投递记录及 Loki 日志。面板的颜色只是辅助。更可靠的方法是结合指标更新时间、阈值和真实测试事件判断。飞书接口返回成功也表示机器人接口接受了消息并不表示群成员已经阅读。6. 两种安装方式优先推荐 SH 自动部署方式 1SH 自动部署统一管理多台服务器在主服务器准备部署包/root/webscan-deploy/ ├── deploy-webscan.sh ├── webscan.yaml └── README.md按完整配置示例填写主服务器地址、各节点 SSH 信息、监控路径和飞书机器人凭据并放行所需的云安全组及系统防火墙端口。然后在主服务器执行cd/root/webscan-deploychmod600webscan.yaml# 校验配置并预览操作bashdeploy-webscan.sh --dry-run# 打开部署菜单选择 1 安装bashdeploy-webscan.sh菜单包含安装、重装、卸载和增加子服务器。脚本通过 SSH 操作启用的节点服务器无需安装 Python 或 Go 编译环境。运行环境为 Linux amd64需要 Docker 和 Compose缺少 Docker 时自动安装支持 DebianUbuntu。它的价值是把环境检查、配置下发、启动、验收和失败恢复放在同一条流程里。不必逐台登录手动重复执行相同操作。全新 Go 部署会先准备节点监听和文件清单暂缓传输再应用主服务器配置最后逐台启用传输并验收。首次清单建立速度取决于文件数量、目录数量和磁盘性能不能只用“容器已经起来了”判断完成。方式 2Docker Compose适合自行管理各台服务器需要自己控制每台服务器启动过程时可以使用 Compose。在本地源码目录填写配置再生成每台服务器的专用部署包cpwebscan.example.yaml webscan.compose.yamlchmod600webscan.compose.yaml# 编辑配置填写服务器信息和飞书凭据后执行go run ./cmd/compose--configwebscan.compose.yaml--outputcompose-deploy本地生成需要 Go 环境运行服务器不需要。将主服务器包和各节点包分别上传再按教程执行docker compose up -d等启动命令。节点应先启动 Agent 和 exporter确认清单及监听就绪后再启动 Vector。不同节点拥有自己的身份和证书不能直接复制另一台节点的运行包。完整步骤见项目的 Compose 部署教程。自研服务提供两个 Docker Hub 公开镜像gzdzh/webscan-central主服务器接收服务包含部署工具。gzdzh/webscan-agent子服务器文件监控程序。公开拉取无需账号密码。完整系统还包含 Vector、Grafana、Loki、Prometheus 等组件不能只启动这两个镜像就认为已经部署完成。正式部署使用发布版本及固定摘要具体以配套 YAML 为准。7. 装好以后必须做一次真实验证一套文件监控是否可用最终要通过真实文件变化来确认。SH 部署流程会使用独立测试目录验证文件检测、扫描及消息投递飞书开启时还会发送部署完成通知和各节点部署后的 PHP 修改测试通知。单独增加节点也会执行对应测试。验收不需要修改业务网站文件也不需要执行测试 PHP 内容。实际使用时可以重点核对飞书是否收到预期通知时间和服务器名称是否正确。Loki 是否能查询到对应事件。Grafana 中的心跳、监听覆盖和采集目标是否正常。测试结束后扫描及投递队列是否恢复到正常水平。YARA 根据已有规则识别可疑内容规则没有命中不能证明文件一定安全。系统提供的是变化检测和调查线索仍需要结合代码审核、访问日志和实际业务判断。8. 这套系统适合谁如果你维护着多个 PHP 网站服务器分散在不同云平台希望文件变化有人提醒、历史记录能够查询、节点故障也能发现这套方案值得尝试。从一台测试节点开始配置最需要关注的目录和文件类型排除确认无须告警的缓存再验证检测到飞书的整条链路。规则稳定后再逐步接入其他服务器。Go 程序的实际资源占用与目录数量、文件规模、扫描频率和队列积压有关整套系统还包含监控组件选型应看完整容器的 CPU 和内存数据不能只凭语言判断性能。如果现在只做一个检查你的重要配置文件被修改后有没有一条可靠的通知能告诉你你的网站最希望监控哪些文件PHP 源码、配置文件还是上传目录中的异常脚本欢迎在评论区分享场景后续可以围绕这些需求继续介绍规则配置和排查方法。