如何编写文件监控脚本

wen 实用脚本 2026-07-01 29

从入门到生产级部署实战指南

目录导读

文件监控脚本的核心应用场景 – 为什么你需要监控文件变化？
主流技术方案对比 – Python、Inotify、Watchdog、PowerShell谁更合适？
Python Watchdog实战 – 20行代码实现实时监控
脚本进阶技巧 – 防重复触发、日志记录、邮件告警
生产环境部署 – 进程守护、性能优化与安全加固
常见问题FAQ – 监控漏报、CPU飙升、跨平台兼容性解答

文件监控脚本的核心应用场景

文件监控脚本是运维、开发、安全团队必备的自动化工具，它能实时捕捉文件系统的创建、修改、删除、移动等事件，广泛应用于：

如何编写文件监控脚本

日志文件分析：监控应用日志目录，发现异常自动告警
配置热更新：配置文件变更后自动重载服务（如Nginx）
数据同步：检测新上传文件，触发备份或迁移任务
安全审计：监控敏感目录（如/etc/passwd）的未授权修改
文件完整性验证：检测勒索病毒对文件的批量篡改

问答：
Q：脚本监控和系统自带的inotify命令有什么区别？
A：inotify是Linux内核子系统，可用inotifywait命令手动观察事件，但脚本能实现持久化、多事件处理、自定义回调逻辑，用Python watchog封装后，可同时监控目录、过滤文件类型、触发后续流程。

主流技术方案对比

方案	跨平台	实时性	资源占用
Python Watchdog	是	高	中
Linux inotify + Shell	仅Linux	极高	低
Go fsnotify	是	高	极低
Node.js chokidar	是	高	中
Powershell FileSystemWatcher	仅Windows	中	高

推荐首选：Python的Watchdog库 – 跨平台（Linux/macOS/Windows）、API简洁、生态成熟、社区支持完善。

问答：
Q：监控大量文件（10万+）时，哪种方案性能最优？
A：Go的fsnotify因无Python GIL锁且内存占用低，表现更佳，但Python Watchdog结合recursive=False按需监控子目录，可缓解性能压力，实际测试中，1万文件场景二者差异不明显，建议根据团队语言偏好选择。

Python Watchdog实战：20行代码实现实时监控

安装Watchdog（仅需一行命令）：

pip install watchdog

完整监控脚本示例（monitor.py）

import time
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
class FileChangeHandler(FileSystemEventHandler):
    def on_modified(self, event):
        if not event.is_directory:
            print(f"[修改] {event.src_path}")
            # 此处可扩展：发送邮件、调用API、写数据库
    def on_created(self, event):
        print(f"[新建] {event.src_path}")
    def on_deleted(self, event):
        print(f"[删除] {event.src_path}")
if __name__ == "__main__":
    watch_dir = "/var/log/myapp"  # 替换为目标目录
    event_handler = FileChangeHandler()
    observer = Observer()
    observer.schedule(event_handler, path=watch_dir, recursive=True)
    observer.start()
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()

运行命令：

python3 monitor.py

问答：
Q：为什么我运行后只捕获到部分事件？
A：Watchdog默认依赖系统API（Linux用inotify，Windows用ReadDirectoryChangesW），若监控网络挂载目录（NFS/CIFS），可能因文件系统不支持事件通知而漏报，建议监听本地ext4/NTFS分区，或设置observer.schedule()的event_filter参数。

脚本进阶技巧

1 防重复触发

同时保存文件（如IDE的*.swp）会触发多次事件，可用时间戳去重：

LAST_EVENT_TIME = {}
def on_modified(self, event):
    now = time.time()
    if self.last_event.get(event.src_path, 0) + 0.5 > now:
        return  # 0.5秒内忽略重复事件
    self.last_event[event.src_path] = now
    # 执行真正逻辑

2 日志记录与告警

集成logging模块并支持邮件：

import logging, smtplib
logging.basicConfig(filename='file_monitor.log', level=logging.INFO)
def send_alert(subject, body):
    with smtplib.SMTP('smtp.example.com') as smtp:
        smtp.send_message(f"Subject:{subject}\n\n{body}")

3 过滤无关文件

只监控特定扩展名（如.log, .conf）：

patterns = ["*.log", "*.conf"]
event_handler = WatchdogPatternMatcher(
    patterns=patterns, 
    ignore_patterns=["*.tmp"], 
    ignore_directories=True
)

问答：
Q：监控到文件变动后，如何执行Shell命令或重启服务？
A：使用subprocess.run(["systemctl", "reload", "nginx"])，注意避免在回调中执行耗时命令，可用线程池异步处理：

from concurrent.futures import ThreadPoolExecutor
executor = ThreadPoolExecutor(max_workers=2)
def on_modified(self, event):
    executor.submit(self.reload_service, event)

生产环境部署

1 进程守护

使用systemd创建服务：

[Service]
ExecStart=/usr/bin/python3 /opt/monitor.py
Restart=always
User=monitor_user
WorkingDirectory=/opt

2 性能优化

限制监控深度：recursive=False + 单独对不同子目录注册observer
事件队列调优：设置observer.start()的timeout参数增大轮询间隔
避免IO阻塞：回调函数内不要直接写文件或数据库，使用消息队列（Redis/ RabbitMQ）

3 安全加固

最小权限原则：用专用系统用户运行（如useradd -r -s /sbin/nologin filewatcher）
路径安全检查：校验监控目录是否在预期范围内，防止符号链接攻击
日志脱敏：输出路径时过滤敏感关键字（如password）

问答：
Q：监控脚本在服务器上运行久了，CPU占用越来越高怎么办？
A：常见原因：1）递归监控了动态变化的目录（如/tmp）；2）回调函数中未释放资源（如未关闭文件句柄），可用watchdog的stat_monitoring模式替代基于事件的监控，但会牺牲实时性，生产环境推荐限制监控文件数不超过5万。

常见问题FAQ

Q1：Windows上无法运行Watchdog怎么办？
A：确保安装PyWin32库：pip install pywin32，Windows需管理员权限监控某些系统目录，如仍失败，改用powershell原生方案：

$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = "C:\logs"
$watcher.EnableRaisingEvents = $true
Register-ObjectEvent $watcher "Created" -Action { Write-Host "新文件: $($Event.SourceEventArgs.FullPath)" }

Q2：监控漏掉了一些事件（如重命名、属性变化）？
A：Watchdog默认只监听on_modified等基本事件，需自定义继承FileSystemEventHandler，重写on_moved()和on_any_event()方法，重命名事件（on_moved）需手动记录前后路径。

Q3：能否监控远程FTP或S3存储？
A：不能直接通过文件系统API监控，替代方案：轮询检查文件元数据（Polling Observer，如watchdog.observers.polling.PollingObserver），但实时性差（默认1秒间隔），更优方案：使用云平台的事件通知（如AWS S3 Event Notification + Lambda）。

Q4：脚本启动时，已有文件如何处理？
A：Watchdog只在运行后触发事件，若要处理存量文件，在observer.start()前遍历目录：

for root, dirs, files in os.walk(watch_dir):
    for file in files:
        print(f"[存量] {os.path.join(root, file)}")

通过本文,你应该能根据实际场景选择最合适的监控方案，并从零构建一个健壮、可扩展的文件监控脚本。监控只是手段，自动化处理才是核心——建议将脚本与CI/CD、告警系统的API深度集成，才能发挥最大价值。