★ FEATURED ARTICLE 简介SiteMonitor是一款面向企业及个人的多目标网站资讯监控工具主要用于同时跟踪多个网站的页面更新与关键字变化帮助用户在信息竞争环境中及时捕获重要动态。该资源为RAR压缩包共3个文件包含可直接运行的exe安装程序、用于指导部署与版本升级的html说明文档以及提供详细配置建议的txt文本整体包体大小约10.51MB体量精简、上手门槛较低。在功能层面工具支持更新监控与关键字监控两种核心模式并可通过微信推送提醒适合市场调研、品牌舆情跟踪或兴趣内容追更等场景。资源当前已有1178人学习下载借助随包提供的安装指引与配置说明读者可快速完成工具部署并按需设置监控频率、提醒方式从而建立一套可长期运行的自动化站点观察机制。1. 网站监控不是能打开就够了说到网站监控很多人第一反应是“能不能打开、响应快不快”。但我在实际维护某个资讯发布平台时踩过更大的坑页面一直返回 200服务也一直活着可运营同学把新公告挂上去之后整整两周没人发现直到用户打电话来问。这说明“可用性监控”和“资讯监控”是两件事。SiteMonitor 这套资源解决的是后者它按设定周期抓取目标页面抽取你指定区块的内容生成指纹做前后比对内容一旦变化就立刻推送通知——适合内容运营、竞品情报收集以及所有依赖第三方页面数据的开发者。2. 监控策略先想清楚轮询、请求头与关键区的三层选型2.1 轮询周期的选型从“扫一眼”到“盯梢”SiteMonitor 的抓取周期是按站点独立配置的不是全局一个固定值。我见过不少人把间隔统一设成 30 秒结果目标站点稍微做点防护IP 直接被限流。资讯监控的正确思路是先评估页面更新频率再决定轮询密度。站点类型推荐轮询周期日请求量说明静态公告页60 分钟24 次低频更新长周期足够高更新资讯站10 ~ 15 分钟96 ~ 144 次文章更新集中在工作时间活动/价格页5 分钟288 次变化直接影响决策接口型动态页1 ~ 2 分钟720 ~ 1440 次数据实时性要求高资源里对每个站点的配置还额外支持一个jitter参数默认 10%。它的作用是在基础间隔上做随机抖动避免所有站点在同一秒发出请求形成对目标服务器的“脉冲式攻击”。如果你同时监控几十个站点这个参数能显著降低被目标站识别为爬虫的概率。周期选型有一个基本换算逻辑每缩短一半间隔对目标站的请求量就翻一倍。把 10 分钟改成 5 分钟看起来只是“勤快了一点”实际上日请求量从 144 次涨到 288 次。我一般建议先按表格里的档位设跑三天看报警密度再收紧。2.2 用 ETag / Last-Modified 做条件请求减少无谓抓取大部分动态站点的响应头里都带ETag或Last-ModifiedSiteMonitor 的条件请求模式就是吃这两样东西。第一次抓取时把响应头里的这两个字段记下来后续请求带上If-None-Match和If-Modified-Since如果服务端判断资源没变直接返回304站点监控逻辑就可以跳过解析和比对省掉大量带宽和 CPU 开销。import requests def fetch_since(session, url, etagNone, last_modifiedNone): headers {User-Agent: SiteMonitor/1.0} if etag: headers[If-None-Match] etag if last_modified: headers[If-Modified-Since] last_modified resp session.get(url, headersheaders, timeout15) if resp.status_code 304: return {changed: False, body: None} return { changed: True, body: resp.text, etag: resp.headers.get(ETag), last_modified: resp.headers.get(Last-Modified), }这段代码的逻辑分两条路径304直接判定“页面未变化”不进后续流程200则把新响应头和正文一起返回由上层模块更新快照。注意etag和last_modified必须持久化到快照元数据里否则下次进程重启后这两个值丢失条件请求就退化成全量抓取。有个边界情况要提醒不是所有站点都返回ETag。静态文件服务器一般都有但某些动态渲染框架默认关闭Last-Modified。资源里的抓取器会检查响应头如果没有这两个字段就自动降级为全量抓取不影响监控正确性只是开销大一些。2.3 变化判定不是“文本不一样”而是“关键区不一样”如果把整个 HTML 拿来做字符串比较那基本没法用。一个普通页面里至少有广告位、统计脚本、时间戳、动态 Session ID这些元素每次请求都在变但它们和“资讯内容有没有更新”完全无关。SiteMonitor 的做法是先用 CSS 选择器定位关键区块比如公告正文容器、文章列表、价格栏然后只对这一小块内容做提取。from lxml import html import re def extract_zone(raw_html, selector): doc html.fromstring(raw_html) nodes doc.cssselect(selector) if not nodes: return None return \n.join(n.text_content().strip() for n in nodes) def normalize(text): text re.sub(r!--.*?--, , text) text re.sub(r\s, , text) return text.strip()extract_zone的返回值值得单独说当选择器匹配不到任何节点时返回None这是一个特殊信号。SiteMonitor 里把None标记为“解析异常”而不是“内容清空”——这两者如果混在一起站点改版时你会收到一堆假告警。normalize函数负责去掉注释和多余空白因为 HTML 排版变化不影响内容本身但会影响字符串比较结果。列表页的场景比单区块复杂一些。SiteMonitor 允许在一个站点下配置多个selector比如同时取新闻标题列表和正文首段然后把这些区块的文本拼成一个字符串做整体比较。这样既能感知“新增了一条新闻”也能感知“已有新闻的内容被修改”。2.4 多站点优先级先排重点站再排小站监控站点数量一多轮询调度就成了瓶颈。最简单的顺序轮询会把重点站和边缘站排在同等位置某天某个慢站点响应超时后面所有站点都被阻塞。资源里的调度器拆了两个队列优先队列和普通队列。重点站进了优先队列后调度器会保证它的巡检间隔不被普通站点挤占而且失败重试次数更多。我在实际使用里会把三个参数绑定到站点配置上priority决定进哪个队列retry决定失败后最多重试几次timeout决定单次请求的截止时间。普通站的timeout我习惯设 10 秒重点站设 20 秒因为重点站通常是内容繁重的门户首页渲染慢是常态。排队策略本质上是在“响应及时性”和“目标站压力”之间做平衡没有绝对最优只能根据监控规模调整。3. 落地 SiteMonitor 核心链路配置、指纹、快照三步走3.1 站点配置用 YAML 描述目标、选择器和变化阈值SiteMonitor 的配置入口是一个 YAML 文件所有监控行为都在这里声明。这个设计的好处是新增一个监控站点不需要改代码运维同事改两行配置就能上线。下面是一个典型的站点配置节选。sites: - name: release_notes url: https://example.com/release interval: 600 priority: high retry: 3 timeout: 20 selectors: content: #release-content fingerprint: sha256 strip_fields: - .publish-time notify: - work_weixin参数说明参数含义备注interval轮询间隔单位秒600 表示 10 分钟一次selectors关键区 CSS 选择器可配置多个取并集比较fingerprint指纹算法默认 sha256资源里也支持 SimHashstrip_fields忽略字段列表用于排除时间戳等干扰项retry失败重试次数超过后进入降级告警notify通知渠道列表对应下方 notify 配置块strip_fields是这个资源里比较实用的设计。第 2.3 节提到过时间戳会干扰变化判定这里可以直接声明哪些节点需要先从提取结果里剔除。比如.publish-time这类类名在不同页面里经常见提前声明比事后看误报再改选择器省事得多。3.2 抓取与去重内容指纹和增量判定逻辑关键区文本提取出来之后下一步是生成指纹并和上一次对比。SiteMonitor 使用哈希指纹来标识内容状态理由很实际完整快照可能几百 KB每次做全文比对耗时高而 sha256 指纹只有 32 字节内存里存几万个站点的状态毫无压力。import hashlib def fingerprint(text): normalized normalize(text) return hashlib.sha256(normalized.encode(utf-8)).hexdigest() def check_and_update(site_name, current_fp): prev_fp load_fingerprint(site_name) if prev_fp is not None and prev_fp current_fp: return False, None previous_text load_previous_snapshot(site_name) save_fingerprint(site_name, current_fp) save_snapshot(site_name, current_text) return True, build_diff(previous_text, current_text)这里的关键是check_and_update的返回结构第一个返回值表示“是否发生变化”第二个是变化差异文本。差异文本不是全量内容而是新旧快照之间的 diff这样通知消息里可以直接带上变化摘要。有个容易忽略的点第一次抓取时prev_fp是None此时应该记录基线快照但不触发告警。资源里在check_and_update里对prev_fpNone的情况做了静默处理避免刚上线就被每个站点“变化”一遍轰炸。3.3 落盘快照与历史留痕指纹负责快速判断快照负责事后追溯。SiteMonitor 每次发现变化都会把上一版内容存成带时间戳的快照文件供人工核查。这个目录结构是资源包默认的data/ snapshots/ release_notes/ 2025-01-10T1030000800.html 2025-01-10T1215000800.html latest/ release_notes.txt db/ sitemonitor.sqlite3快照保留策略默认是每个站点留 20 份超出后自动清理最旧文件。latest目录里存的是当前指纹对应的最新文本用于和下一次巡检结果做 diff。有一点很关键快照只在内容发生变化时写入所以同一站点在一段时间内没更新快照目录是安静的不会因为每次巡检都落盘而产生大量碎片文件。diff 的生成我习惯用 Python 标准库的difflib它能输出类似 Git 的增删行标记通知消息里直观看出哪里变了。import difflib def build_diff(old_text, new_text): if old_text is None: return new_text[:200] # 首次基线截前 200 字 return .join(difflib.unified_diff( old_text.splitlines(keependsTrue), new_text.splitlines(keependsTrue), lineterm\n))unified_diff输出带-和前缀的行能直接看出删除和新增的内容。首次基线场景下old_text为空此时截取新文本前 200 字作为摘要避免把整个页面塞进通知。4. 部署与通知容器编排、告警通道与失败降级4.1 一键编排用 Docker Compose 部署监控服务SiteMonitor 的部署我推荐直接用 Docker Compose配置、数据目录、健康检查一次声明完。资源包里给的编排文件大致长这样。services: sitemonitor: image: sitemonitor:latest restart: unless-stopped environment: TZ: Asia/Shanghai SITE_CONFIG: /etc/sitemonitor/sites.yaml volumes: - ./config:/etc/sitemonitor:ro - ./data:/data/sitemonitor healthcheck: test: [CMD, python, -m, sitemonitor.check] interval: 60s timeout: 10s retries: 3SITE_CONFIG环境变量指定配置文件路径配置目录以只读方式挂载避免容器内误修改。数据目录挂到宿主机./data这样容器重建后快照和 SQLite 数据库依然在。健康检查命令sitemonitor.check会做两件事确认调度线程存活以及确认最近一次巡检时间没有超过该站设定的最大间隔。如果两个条件任一不满足容器会被标记为 unhealthy随后由宿主机侧的监控拉起。restart: unless-stopped保证了机器重启后监控服务自动恢复。需要留意的是Compose 文件里最好为每个站点单独设置健康检查的超时时间资源里默认是 10 秒如果某个目标站点响应特别慢健康检查会误报。4.2 通知链变化事件推到企业微信、钉钉或邮件SiteMonitor 的通知层做了统一抽象站点配置里写通知渠道名实际推送逻辑在通知配置块里定义。这样切换渠道不用改业务逻辑只改配置文件。notify: channels: work_weixin: type: webhook url: https://example.com/cgi-bin/webhook/send?keyxxxx dingtalk: type: webhook url: https://example.com/robot/send?access_tokenxxxx email: type: smtp host: smtp.example.net port: 465 username: monitorexample.net password: ******企业微信机器人和钉钉机器人都走自定义 Webhook区别在请求体格式和签名方式SiteMonitor 的通知适配器已经封装好了。邮件渠道适合作为兜底当 Webhook 通道不可用时自动切换。资源里的编排把通知失败也视为一次事件会记录到 SQLite并在下一轮巡检时把失败状态追加到告警里。一条典型的变化通知包含四个字段站点名、检测时间、diff 摘要、快照文件路径。时间使用配置文件里TZ指定的时区避免上海时间下午三点的变化被通知成 UTC 时间早上七点。这里有一个容易踩的坑放到第 5 章细讲。4.3 巡检失败时的降级与重试目标站点不会永远稳定SiteMonitor 抓取失败后的行为也要单独设计。资源里的抓取器实现了指数退避重试而不是失败后立刻重试 N 次。这样既避免了对目标站的二次压力也给了网络抖动自我恢复的时间窗口。import time def fetch_with_retry(site, session): last_err None for attempt in range(site.get(retry, 3)): try: return do_fetch(site, session) except requests.Timeout as e: last_err e time.sleep(2 ** attempt) # 第一次等 2s第二次等 4s except requests.RequestException as e: last_err e time.sleep(2 ** attempt) notify_alert(f{site[name]} 连续 {site[retry]} 次抓取失败: {last_err}) return Nonetime.sleep(2 ** attempt)的退避序列是 0、2、4 秒重试 3 次总共额外等待 6 秒。这里有个细节首次失败不等待立即重试应对瞬时网络抖动第二次、第三次逐步拉长间隔给服务端恢复时间。重试全部失败后走的是降级告警通道通知标题里明确写“抓取失败”而非“内容变化”两个事件在通知侧有完全不同的处理路径。对运维来说看到“抓取失败”会去查目标站状态而不是打开页面去比对内容有没有变。关于重试次数我不建议设超过 5 次。某站点真正宕机时重试 10 次也只是把告警推迟了几分钟反而消耗本地资源。SiteMonitor 的默认值是 3对大多数场景够用。5. 避坑排查五次翻车记录里的共性与对策5.1 站点改版后选择器失配误报“页面大变”现象某个周日凌晨监控突然告警“公告页内容大改”快速打开目标站点一看页面内容和昨天一模一样。原因目标站的开发团队悄悄改版公告容器从div.content换成了div.article-body原选择器匹配不到节点抽取结果为空字符串。空字符串和上一次的有效快照不同所以被判定为“内容变化”。解决SiteMonitor 的比较器对空抽取做了单独标记返回None而不是空字符串这两种状态走不同的分支。None进入“解析异常”通道发告警时提示“选择器失配请检查页面结构”而不是发“内容已更新”。我现在每次收到这类告警会先看一眼快照目录里的落盘内容确认是结构变化还是真实更新再决定是否调整选择器。5.2 登录态失效后集体 401快照目录被登录页刷屏现象某个需要登录才能访问的监控站点突然所有巡检请求都返回 302快照目录里出现了大量内容一样的 HTML——全是登录页。原因目标站登录态的 Cookie 过期后SiteMonitor 还在用旧的 Session 发请求服务端把它重定向到登录页。登录页本身也是一个页面如果不做过滤就会被当成“正常抓取到的页面”存进快照。解决资源里对这类站点提供了auth配置块支持在收到 401/302 时自动触发重新登录逻辑拿到新 Cookie 后继续巡检。更重要的处理是连续两次登录失败时站点自动进入“挂起”状态不再发起请求等待人工介入。否则一个站点登录失效会产生几十条无意义的告警把真正重要的通知淹没。5.3 动态 Token 造成全文指纹全部变化现象某个接口型页面的告警一小时响了 6 次但人工检查发现列表内容没有新增也没有删除。原因页面 HTML 里嵌了一个随机生成的 Session Token每次请求的值都不一样。关键区选择器选得太宽把它一并包含进来了导致每次指纹都不同。解决两个手段叠加。第一收窄选择器只选内容承载节点第二在strip_fields里把包含 Token 的节点排除掉。我之前的经验是很多“页面一直在变化”的假象都是把会话标识、统计脚本、浮动广告时间戳这类噪声纳入了比较范围。5.4 通知风暴一个站点多个区块同时变Webhook 被限流现象目标站做了大面积改版五个监控区块同时变化SiteMonitor 一次性推了 10 多条告警没过几分钟企业微信机器人的 Webhook 被限流了。原因通知渠道对单机器人每分钟的消息数有硬限制高频推送会触发流控。解决SiteMonitor 的通知层内置了聚合窗口。同一站点在 5 分钟内产生的多条变化事件合并成一条通知发送消息体里列出所有变化区块的 diff 摘要。聚合窗口的时间窗和冷却时间可以在通知配置里按站点调。我现在把所有站点的聚合窗口统一设成 2 分钟既能感知变化又不会触发流控。5.5 时区配置错误导致每天凌晨同一时间“假更新”现象某个资讯站每天早上 3 点左右固定出现一次“内容变化”告警点开 diff 看内容几乎没变只是日期文本从 1 月 9 日变成了 1 月 10 日。原因目标站页面里显示了“今天是 1 月 10 日”这类时间文本而服务端容器的时区没设置默认 UTC。UTC 时间的 0 点对应北京时间早上 8 点所以每天到了 UTC 跨日时刻时间字段变化被判定为内容变化。解决先把容器环境变量TZ设置为Asia/Shanghai然后在站点的strip_fields里排除发布时间、更新日期这一类字段。SiteMonitor 还有一个更精细的策略对列表页启动“列表项数量 自有文本”的联合指纹也就是只看列表里“有哪些条目、每个条目的文本是什么”忽略条目内的纯时间信息。从那以后这种跨日误报就再也没出现过。6. 验证与进阶端到端冒烟测试与误报调优6.1 用临时站点做一次端到端自检改完配置最怕的不是代码报错而是配置不生效、通知没发出看起来一切正常实际是静默失败。我给 SiteMonitor 写了一个冒烟脚本用本地 HTTP 服务模拟一个目标页面跑两轮巡检断言告警链路是通的。#!/usr/bin/env bash set -euo pipefail out_dir$(mktemp -d) python3 -m http.server 8123 --directory $out_dir /dev/null 21 server_pid$! trap kill $server_pid 2/dev/null || true EXIT echo htmlbodydiv idmainV1_CONTENT/div/body/html $out_dir/index.html sitemonitor check --site demo --url http://127.0.0.1:8123/index.html --selector #main --interval 0 --once sleep 1 echo htmlbodydiv idmainV2_CONTENT/div/body/html $out_dir/index.html sitemonitor check --site demo --url http://127.0.0.1:8123/index.html --selector #main --interval 0 --once sitemonitor log --site demo --latest | grep -q V2_CONTENT echo smoke test passed脚本先起一个临时 HTTP 服务写入两个版本的 HTML分别触发巡检最后检查最新状态里是否包含第二版内容。--interval 0 --once表示单次执行、不进入调度循环。这个脚本的价值在于选择器、抓取器、指纹保存、日志写入这几层任何一个环节断了grep 都会失败问题当场暴露。6.2 误报调优的三个顺序优先级真正跑起来之后误报调优要按顺序做不能一上来就加规则。第一步打开告警里的 diff 摘要确认变化的是内容还是噪声。第二步如果是噪声优先在strip_fields里排除对应节点而不是改大指纹算法阈值。第三步如果噪声分布没有固定规律再考虑把站点切换成 SimHash 指纹允许小范围文本差异不触发告警。SiteMonitor 支持按站点声明关键词规则只在 diff 命中某些词时才推送。alert_rules: - include_keywords: [停服, 价格调整, 版本回滚]这个规则的语义是页面变化了但如果 diff 里不包含规则内关键词通知只写入历史记录不推送。适合那种滚动更新频繁、但只有特定动作才需要立刻处理的页面。6.3 把监控状态做成轻量仪表盘SiteMonitor 每次巡检的结果都写入 SQLite所以可以用很小的成本做状态统计。一张表结构类似check_history(site_name, result, checked_at)就能撑起按天聚合。统计脚本不算复杂能帮你在短时间内看到“哪些站点一直在变、哪些站点经常抓取失败”。import sqlite3 conn sqlite3.connect(/data/sitemonitor/sitemonitor.sqlite3) cur conn.execute( SELECT site_name, COUNT(*) AS total, SUM(CASE WHEN result changed THEN 1 ELSE 0 END) AS changed_cnt FROM check_history WHERE checked_at datetime(now, -24 hours) GROUP BY site_name ) for row in cur: print(row)checked_at字段统一存本地时间配合TZ环境变量统计结果不会出现时区偏移。完整的站点配置模板、通知聚合策略和自检脚本都整理在随资源附带的工程包里了。从那以后我每次给新站点上线监控都强制走一遍“选关键区 → 跑三天灰度 → 人工看一次 diff”的流程误报率基本能压到每周一条以内希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
