PLFM_RADAR 这个名字我第一次看到时第一反应是雷达硬件或者信号处理方向的东西。等把需求翻完才反应过来——这是个纯软件项目核心是“平台动态监测”。PLFM 是 Platform 的缩写RADAR 并不是真的电磁波雷达而是一套隐喻像雷达一圈圈扫描空域那样去反复扫描目标平台的公开页面、接口和动态把新出现的信号及时捞出来分级分类推给需要知道的人。这个项目适合谁如果你是那种需要盯着竞品公告、平台文档更新、社区热榜变化的人每天手动刷新十几次还担心漏掉关键信息如果你已经写过一次性爬虫脚本、但发现它跑完就完事没法持续监控如果你想把“监测”从临时脚本变成一套能长期运行、自动告警的小服务——PLFM_RADAR 值得参考。它解决的就是三个非常具体的问题人肉盯梢效率低、单次脚本不可持续、原始数据噪音大没法直接用。我把它从零搭了一遍顺手做了个有扫描动画的雷达仪表盘这文章把整个思路和踩坑过程完整记录下来。1. 核心思路拆解为什么用“雷达”来建模平台监测1.1 雷达扫描逻辑如何映射到平台监测雷达系统的经典工作流程是发射脉冲、接收回波、在噪声中识别目标、持续跟踪轨迹。这套逻辑搬到平台监测上几乎可以一一对应这也是 PLFM_RADAR 最核心的设计出发点。发射脉冲对应定时巡检。雷达不会只扫一次它按固定周期转圈监测系统也一样用定时任务反复去请求目标平台每次巡检就是一次“脉冲发射”。接收回波对应抓取快照。页面 HTML、接口 JSON、RSS 输出都是平台“反射”回来的信号里面既有我们关心的信息也有大量噪声。在噪声中识别目标对应指纹与规则引擎。原始页面里时间戳、浏览量、随机推荐位每天都在变但真正值得关注的可能是某个公告标题、某个文档版本号、某条热帖的排名变化。我们要做的就是从噪声里分离出“有效信号”。持续跟踪轨迹对应状态记录。雷达会记录目标移动轨迹判断它是靠近还是远离监测系统同样维护每个目标的历史状态当状态发生迁移时才触发告警而不是每次抓取都大呼小叫。这套隐喻不只是一个命名包装它直接影响代码结构。比如“目标”在雷达里是有坐标和航迹的在 PLFM_RADAR 里就是一个带标识符的监测对象带着自己的历史指纹库比如“回波识别”强调在噪声中提取特征所以代码里不能只做简单的“页面变了没变”必须先做归一化再做差异分析。可以说理解了这套映射后面每一行代码都有了解释。1.2 技术选型Python、轻量存储、Webhook 的理由选定 Python 没什么悬念。监测类项目对代码迭代速度要求远高于运行性能requests 发请求、BeautifulSoup 和 lxml 做解析、difflib 做文本差异对比这些都是现成的轮子。更关键的是Python 的异常处理生态很适合爬取场景网络超时、解析失败、编码混乱这类问题用 Python 写容错逻辑比用编译型语言舒服得多这个项目后续改起来也方便。存储层我选了 SQLite 起步没有一上来就上 MySQL 或者 MongoDB。“雷达”要存的数据形态其实很固定每个目标一条当前指纹、一份历史状态表、一堆告警记录。这个体量 SQLite 完全够用单文件自带事务备份就是拷走一个文件部署成本极低。等到目标数量上了几千、单日抓取几十万次再考虑迁移到 PostgreSQL 也不迟代码里我做了数据访问封装切换存储层不需要改业务逻辑。告警通道我优先盯 Webhook因为现在主流办公 IM 都支持入群机器人发一条 JSON POST 请求就能把消息推到群里比调邮件 API 简单很多也不用维护 SMTP 配置。邮件保留作为降级通道一旦 Webhook 连续失败超过阈值自动切到邮件兜底。这个取舍后面在实操部分会看到具体实现。1.3 监测边界和合规意识只守不攻这里必须多说几句。PLFM_RADAR 的定位是监测“你有权访问的公开信息”不是抓取私密数据更不是用来对平台发起高频请求。我在做目标巡检时坚持几个底线只请求公开页面和开放接口遵守目标平台 robots.txt 里的语义请求频率保持人类手工刷新的节奏比如单目标每分钟最多一次碰到报错退避而不是立刻重试。理由很简单监测系统要长期运行稳定压倒一切。你高频请求把对方服务器打崩或者因为滥用被封了 IP丢的不只是这个数据源整个监测体系都会跟着失效。一个成熟的雷达不会为了看清一个目标而烧掉整个频段这个道理放到平台监测上同样成立。2. 五层架构设计从信号到情报的流水线2.1 信号源接入层定义“要盯什么”PLFM_RADAR 的第一层是信号源接入层解决“雷达要扫描哪些空域”的问题。我用一个 YAML 文件来声明所有目标好处是新增一个监测目标不需要改代码只要往配置里加一条记录。targets: - name: dev_docs_announce url: https://example.com/announcements type: html selector: div.announcement-item fields: [title, date, content] check_interval: 60 - name: community_hotlist url: https://example.com/api/hotlist?limit50 type: json json_path: $.data.list fields: [rank, title, heat] check_interval: 300 - name: official_blog_rss url: https://example.com/rss type: rss fields: [title, link, pubDate] check_interval: 600这里有个设计细节值得展开type字段决定了解析策略。HTML 类型依赖 CSS selector 提取结构化字段JSON 类型直接走json_path从开放接口里拿数据RSS 类型用标准 feed 解析器。三种数据源统一抽象成“给定一个 URL返回一份字段化的记录列表”下游完全不关心数据是从哪个平台、哪种格式来的。这种抽象让我后面加监测源非常快遇到一个纯文本页面加一个text类型写一个解析函数就接进去了。目标对象除了 URL 和解析方式还要定义check_interval。不同平台变化频率差异很大公告页可能一天更新一次热榜每几分钟就翻新。给每个目标单独配置间隔既保证监测密度又不浪费资源这也对应雷达对不同空域采用不同扫描周期。2.2 前端处理层归一化是重中之重采集到原始页面只是第一步真正决定监测质量的是“前端处理层”——把原始报文清洗成适合识别的形态。我见过太多项目卡在这里拿全文 hash 做指纹结果页面底部一个“今日访问量”的计数器跳了一下整条链路就误报一次一小时内告警刷屏几十条。归一化要解决的就是这个。我的处理流程分五步去掉 HTML 标签只留可见文本压缩连续空白字符把多换行、多空格统一成单个空格剔除时间戳和纯数字噪声公告日期、浏览量这类高频变动信息在指纹阶段要排除掉但它可以单独作为字段保留用来展示时间线去掉纯装饰节点比如页脚的备案号、广告位预留的占位文案对中文内容做全半角统一避免因为标点符号不同造成误判。import re import hashlib def normalize(raw_text: str) - str: text re.sub(r[^], , raw_text) text re.sub(r\s, , text) text re.sub(r\d{4}-\d{2}-\d{2}[\sT]?\d{0,2}:?\d{0,2}:?\d{0,2}, , text) text re.sub(r[\u4e00-\u9fa5], , text) return text.strip() def fingerprint(normalized: str) - str: return hashlib.sha256(normalized.encode(utf-8)).hexdigest()要注意的是归一化和字段提取是两条线。字段提取负责把你的目标信息变成结构化数据供展示和通知使用归一化负责生成一个稳定的指纹用于判断“变没变”。两个逻辑必须分开如果你为了归一化方便把结构化信息丢了后面想输出“这条公告是哪天发的”就抓瞎了。2.3 回波识别层指纹、相似度和规则引擎回波识别层解决“这个变化值不值得关心”。底层判断分两级先比指纹指纹不同说明内容确实变了再用相似度算法评估变化幅度幅度超过阈值才发告警。指纹比对用刚才的 64 位 SHA256碰撞概率在实际场景下可以忽略不计。判断逻辑是目标上次状态里存了一份指纹如果新指纹不一致说明检测到变化一致则说明内容稳定继续等待下一次巡检。相似度评估我用 Python 标准库 difflib 的 SequenceMatcher它在文本差异对比上足够快也足够准不需要额外安装第三方库。它返回一个 0 到 1 的比率1 表示完全一致。实际测试下来公告正文加了关键段落时相似度通常在 0.35 到 0.6 之间只是修正了一个错别字时在 0.8 到 0.95 之间。所以我给默认阈值定为 0.85高于这个值视为噪声变化不触发告警同时把差异片段打日志留痕。from difflib import SequenceMatcher def similarity(a: str, b: str) - float: return SequenceMatcher(None, a, b).ratio()规则引擎放在相似度之后给高级场景留了口子。比如限定只有标题命中“版本升级”“故障”“安全公告”等关键词时才告警或者指定某个 JSON 字段的数值变化跨过特定阈值才通知。规则是一组可插拔的 Python 函数每个函数接收解析后的结构化记录返回布尔值决定是否放行。2.4 目标追踪与告警分发层最后一层维护每个目标的“航迹”并负责告警分发。雷达里的航迹是目标位置的连续记录这里的航迹就是每个监测目标的指纹历史表这次指纹是什么上次是什么最近 24 小时变了几次上次告警是什么时间。告警分发的主要逻辑有三条防重复保险同一指纹在有效时间内只告警一次同告警类型在短时间内做聚合比如“热榜前三发生变化”只在每十分钟的窗口内汇总成一条消息告警消息里附上变化前后的关键字段差异而不是把整个页面原文塞进去。这样维护的人看一眼消息就知道发生了什么不用点开链接核对。分发通道默认走 Webhook我封装了一个统一的 sender 接口不同通道各自实现。钉钉/企业微信机器人接收 JSON 格式文本消息Telegram Bot 走它的 sendMessage 接口邮件走 SMTP 兜底。切换通道只需要改配置不用动业务代码。3. 实操过程从零跑通一套雷达系统3.1 项目骨架准备我建议把项目按功能拆成四个模块fetcher负责采集parser负责解析和归一化detector负责指纹比对和差异计算notifier负责告警分发。再加一个main.py做主流程调度config.yaml放所有目标配置。这个拆法坚持单一职责出了问题顺着模块名就能定位。环境方面只需要 Python 3.9第三方库装 requests、beautifulsoup4、lxml、PyYAML、APScheduler。前三个是采集解析标配PyYAML 读配置APScheduler 做定时调度。不需要装数据库驱动SQLite 是标准库自带的。3.2 核心流程采集、指纹、差异计算主流程我写成了一个可无限循环的巡检函数。每次巡检遍历所有目标根据每个目标的时间间隔决定是否需要本次抓取有变化就走差异分析和告警没变化就更新最后检查时间。import hashlib import time import random import requests from bs4 import BeautifulSoup class Target: def __init__(self, config): self.name config[name] self.url config[url] self.type config[type] self.selector config.get(selector) self.json_path config.get(json_path) self.fields config[fields] self.interval config.get(check_interval, 300) self.last_fingerprint None self.last_checked 0 def fetch(self): resp requests.get(self.url, timeout10, headers{User-Agent: Mozilla/5.0 PLFM_RADAR/1.0}) return resp.text def parse(self, raw): if self.type html: soup BeautifulSoup(raw, lxml) items soup.select(self.selector) return [self._extract_fields(item) for item in items[:20]] if self.type json: payload requests.get(self.url, timeout10).json() cur payload for key in self.json_path.strip($.).split(.): cur cur[key] return cur[:20] return []_extract_fields按 fields 配置逐个取文本内容取完后拼成一条字符串记录。指纹就在这条记录上生成。这里要注意字段拼接顺序必须固定不然同样的内容换个字段顺序就生成不同指纹那就会白白误报一次。差异计算要用新旧结构化数据对比不是直接对比整个网页。我保留上一次的结构化记录列表用名称或序号做匹配再对同一记录的新旧版本做相似度评估。比如热榜第 3 名从“A 内容”变成“B 内容”系统只针对这一条做差异提示输出格式是“热榜 第3名 标题变化旧 - 新”。3.3 告警接入Webhook 与邮件兜底Webhook 告警写起来很轻。拿企业微信群机器人举例只需要一个 POST 请求import requests def send_wecom_webhook(text: str, webhook_key: str): url fhttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?key{webhook_key} payload {msgtype: text, text: {content: text}} resp requests.post(url, jsonpayload, timeout10) if resp.status_code ! 200: raise RuntimeError(fwebhook send failed: {resp.text})Telegram Bot 是另一个通道代码几乎一样只是 URL 从企业微信改成api.telegram.org/bottoken/sendMessage参数从text改成chat_id加text。我写了一个 sender 分发层配置里写channel: wecom或channel: tg代码自动路由到对应实现。邮件兜底要在告警失败后启用。我设置了一个连续失败计数器Webhook 连续失败 3 次后切到 SMTP 发一封汇总邮件标题带WARNING: PLFM_RADAR webhook down内容带上最近五条待发送告警。这样既保证了消息不丢失又避免了反复请求已经失灵的 Webhook 浪费时间。3.4 雷达仪表盘可视化项目叫 PLFM_RADAR没有雷达扫描动画总觉得差点意思。我用 Flask 搭了个轻量可视化页面左侧一个模拟雷达屏幕以扫描线旋转的方式展示所有监测目标的“方位”目标按状态分三色——绿色稳定、黄色有变化待确认、红色告警触发过右侧是最近告警流按时间倒序显示底部是目标统计卡片。模拟雷达屏的核心是 CSS 动画加 JavaScript 定时请求。后台接口返回每个目标的状态和最后更新时间前端把目标坐标按名称 hash 映射到雷达盘的极坐标位置让每个目标的位置固定。扫描线用一段旋转的线性渐变色条模拟旋转周期 4 秒可以手动调。这在技术上没有难度但视觉效果非常直白老板或者同事走过来扫一眼就知道监测系统有没有异常。from flask import Flask, jsonify import sqlite3 app Flask(__name__) app.route(/api/radar) def radar_data(): con sqlite3.connect(radar.db) rows con.execute(SELECT name, status, updated_at FROM targets).fetchall() con.close() return jsonify([{name: r[0], status: r[1], updated_at: r[2]} for r in rows])前端轮询这个接口2 秒一次。这个频率很低不会对 Flask 造成压力。如果要再进一步可以加 WebSocket 推送但监测数据本身是分钟级的2 秒轮询完全足够没必要引入额外依赖。3.5 部署与定时调度生产环境我用 APScheduler 做进程内调度好处是不依赖系统 crontab单进程就能管所有目标。调度器用BackgroundScheduler给每个目标注册一个任务函数triggerinterval间隔取目标自己的check_interval。如果巡检一轮需要几分钟目标数量多了任务会跑出叠加所以加上max_instances1防止同一个任务并发执行。部署我用 systemd 管理写一个简单的 service 文件指定工作目录和 Python 路径Restartalways 保证挂了自动拉起。日志重定向到radar.out和radar.err方便用 journalctl 查问题。这里有个经验日志里必须带上每个目标的名称不然多个目标同时出错时你根本不知道哪条日志属于哪个目标。4. 常见问题与排查技巧实录4.1 误报和漏报的平衡误报是最先出现的问题。我一开始阈值设成 0.95结果页面改一个空白符都会告警。后来降到 0.5又发现真正重要的公告变化被淹没了。最后用一批历史变更数据做了校准把过去两个月的页面快照取出来逐一标注哪些变化是人会关心的再反推相似度的分界值。实测下来 0.85 这个阈值比较稳公告新增内容、热榜条目变化基本都能覆盖而浏览量、随机推荐位的波动基本被滤掉。漏报则主要来自归一化过度。有一次公告页改了版本号但因为我的归一化规则把所有纯数字都删了指纹居然没变导致漏掉一次重要更新。后来我调整策略数字不无脑删除而是把超高频变动的字段单独摘出来比如热榜的浏览量数字直接丢弃但公告里的版本号当成必留字段这样既滤噪又保住关键信号。4.2 目标站点改版解析器直接崩平台改版是监测类系统的宿命。最典型的现象是 CSS selector 匹配不到元素解析结果为空列表系统会一直告警“检测到空内容”真实变化反而被耽误。我加了结构自检如果某个目标连续三次解析结果为空自动进入“观察模式”只保留原始 HTML 到日志不再执行指纹对比和告警逻辑。另一个实用经验是双选择器策略。一个主选择器失效时自动启用备用选择器。比如公告列表用.article-list a匹配改版后变成.news-item a我在配置里加fallback_selector。解析器先尝试主选择器结果为空就尝试备用两个都失败才记为观察模式。这个机制让我平均缩短了至少半天的故障恢复时间。4.3 请求被限流的降级方案即使控制频率目标平台偶尔还是会限流。现象是请求返回 403、429或者频繁要求输入验证码。我的降级策略是分级的收到 429 时该目标强制退避 5 分钟期间不再发任何请求收到 403 时先换一个稳定的 User-Agent 重试一次还不行就停掉该目标等待人工介入连续三次网络超时自动把该目标标记为“不可达”状态仪表盘上变灰色停止无意义的重试。这里要强调的是我不做绕过验证码这类对抗操作。监测系统是在规则范围内做事碰上验证码说明对方的反爬机制认为这个请求有风险正确的做法是立刻收手而不是“技术上再想想办法”。这类问题上报给人工通过申请官方 API、加白名单之类的正规途径解决才是长期可持续的。4.4 看门狗监控系统自己也得被监控PLFM_RADAR 最尴尬的时刻是它自己挂了还不知道。我做了三层看门狗进程级、任务级、结果级。进程级由 systemd 的 Restartalways 保证崩溃自动拉起任务级在每个检测周期结束时写一条心跳记录超过 5 分钟没有新心跳外部健康检查接口就会返回 500结果级更关键——如果连续多次巡检没有任何目标发生变化也要发一条“静默通知”防止解析链路静默失效。所谓静默失效就是代码还在跑、进程还活着但解析逻辑已经坏了每条数据都解析成空列表系统看起来一切正常实际上什么都没监测到。这个坑特别隐蔽我第一次遇到时系统整整空转了三天。加上了静默通知后每当所有目标连续 6 个周期都零变化会有一条消息发到群里“雷达空域无信号请确认是否解析异常。”少了这条仪表盘再漂亮也是空中楼阁。现象可能原因快速处理办法告警刷屏指纹生成前未归一化检查是否剔除时间戳、纯数字、装饰文本漏报重要更新归一化误删了关键数字区分高频变化数字与业务关键数字后者保留解析结果为空目标站点改版查看原始 HTML 日志更新 selector 或启用备用选择器请求返回 429请求频率过高退避等待调大 check_interval请求返回 403反爬策略触发更换 UA停止攻击性行为走正规授权通道进程活着但零告警解析链路静默失效检查心跳记录确认解析器输出非空5. 一点实操体会PLFM_RADAR 整个项目做下来我最大的体会是“监测系统最难的不是抓数据而是决定什么值得通知人”。雷达再先进也不能把每只飞鸟都当成敌机报给指挥中心否则真正的威胁反而会被噪音淹没。这一层认知直接决定了架构形态我不追求抓取速度也不追求全量数据而是把所有精力放在归一化、指纹、相似度和规则这几个跟“判断力”有关的部分。另一个深刻的教训是任何网络数据源都不可靠平台改版、限流、宕机随时可能发生所以系统里所有容错路径都要走通一遍空解析怎么办连续超时怎么办告警通道失灵怎么办这些都要在正式上线前模拟一遍。即使这样上线后依然会有没预料到的意外所以心跳、静默通知、人工干预入口一个都不能少。如果你也想做一个类似的平台雷达我建议不要一上来就铺很大的目标面。找三四个真实关心、信息更新频繁的内容源先把采集、指纹、告警和可视化跑通让系统全天候运行一两周积累一批真实变化日志后再回头调阈值、加规则。到那个时候你对自己“到底需要感知哪些变化”的理解会比现在清晰得多做出的监测系统也才真正是为你服务的雷达。
PLFM_RADAR：像雷达一样构建平台动态监测系统
PLFM_RADAR 这个名字我第一次看到时第一反应是雷达硬件或者信号处理方向的东西。等把需求翻完才反应过来——这是个纯软件项目核心是“平台动态监测”。PLFM 是 Platform 的缩写RADAR 并不是真的电磁波雷达而是一套隐喻像雷达一圈圈扫描空域那样去反复扫描目标平台的公开页面、接口和动态把新出现的信号及时捞出来分级分类推给需要知道的人。这个项目适合谁如果你是那种需要盯着竞品公告、平台文档更新、社区热榜变化的人每天手动刷新十几次还担心漏掉关键信息如果你已经写过一次性爬虫脚本、但发现它跑完就完事没法持续监控如果你想把“监测”从临时脚本变成一套能长期运行、自动告警的小服务——PLFM_RADAR 值得参考。它解决的就是三个非常具体的问题人肉盯梢效率低、单次脚本不可持续、原始数据噪音大没法直接用。我把它从零搭了一遍顺手做了个有扫描动画的雷达仪表盘这文章把整个思路和踩坑过程完整记录下来。1. 核心思路拆解为什么用“雷达”来建模平台监测1.1 雷达扫描逻辑如何映射到平台监测雷达系统的经典工作流程是发射脉冲、接收回波、在噪声中识别目标、持续跟踪轨迹。这套逻辑搬到平台监测上几乎可以一一对应这也是 PLFM_RADAR 最核心的设计出发点。发射脉冲对应定时巡检。雷达不会只扫一次它按固定周期转圈监测系统也一样用定时任务反复去请求目标平台每次巡检就是一次“脉冲发射”。接收回波对应抓取快照。页面 HTML、接口 JSON、RSS 输出都是平台“反射”回来的信号里面既有我们关心的信息也有大量噪声。在噪声中识别目标对应指纹与规则引擎。原始页面里时间戳、浏览量、随机推荐位每天都在变但真正值得关注的可能是某个公告标题、某个文档版本号、某条热帖的排名变化。我们要做的就是从噪声里分离出“有效信号”。持续跟踪轨迹对应状态记录。雷达会记录目标移动轨迹判断它是靠近还是远离监测系统同样维护每个目标的历史状态当状态发生迁移时才触发告警而不是每次抓取都大呼小叫。这套隐喻不只是一个命名包装它直接影响代码结构。比如“目标”在雷达里是有坐标和航迹的在 PLFM_RADAR 里就是一个带标识符的监测对象带着自己的历史指纹库比如“回波识别”强调在噪声中提取特征所以代码里不能只做简单的“页面变了没变”必须先做归一化再做差异分析。可以说理解了这套映射后面每一行代码都有了解释。1.2 技术选型Python、轻量存储、Webhook 的理由选定 Python 没什么悬念。监测类项目对代码迭代速度要求远高于运行性能requests 发请求、BeautifulSoup 和 lxml 做解析、difflib 做文本差异对比这些都是现成的轮子。更关键的是Python 的异常处理生态很适合爬取场景网络超时、解析失败、编码混乱这类问题用 Python 写容错逻辑比用编译型语言舒服得多这个项目后续改起来也方便。存储层我选了 SQLite 起步没有一上来就上 MySQL 或者 MongoDB。“雷达”要存的数据形态其实很固定每个目标一条当前指纹、一份历史状态表、一堆告警记录。这个体量 SQLite 完全够用单文件自带事务备份就是拷走一个文件部署成本极低。等到目标数量上了几千、单日抓取几十万次再考虑迁移到 PostgreSQL 也不迟代码里我做了数据访问封装切换存储层不需要改业务逻辑。告警通道我优先盯 Webhook因为现在主流办公 IM 都支持入群机器人发一条 JSON POST 请求就能把消息推到群里比调邮件 API 简单很多也不用维护 SMTP 配置。邮件保留作为降级通道一旦 Webhook 连续失败超过阈值自动切到邮件兜底。这个取舍后面在实操部分会看到具体实现。1.3 监测边界和合规意识只守不攻这里必须多说几句。PLFM_RADAR 的定位是监测“你有权访问的公开信息”不是抓取私密数据更不是用来对平台发起高频请求。我在做目标巡检时坚持几个底线只请求公开页面和开放接口遵守目标平台 robots.txt 里的语义请求频率保持人类手工刷新的节奏比如单目标每分钟最多一次碰到报错退避而不是立刻重试。理由很简单监测系统要长期运行稳定压倒一切。你高频请求把对方服务器打崩或者因为滥用被封了 IP丢的不只是这个数据源整个监测体系都会跟着失效。一个成熟的雷达不会为了看清一个目标而烧掉整个频段这个道理放到平台监测上同样成立。2. 五层架构设计从信号到情报的流水线2.1 信号源接入层定义“要盯什么”PLFM_RADAR 的第一层是信号源接入层解决“雷达要扫描哪些空域”的问题。我用一个 YAML 文件来声明所有目标好处是新增一个监测目标不需要改代码只要往配置里加一条记录。targets: - name: dev_docs_announce url: https://example.com/announcements type: html selector: div.announcement-item fields: [title, date, content] check_interval: 60 - name: community_hotlist url: https://example.com/api/hotlist?limit50 type: json json_path: $.data.list fields: [rank, title, heat] check_interval: 300 - name: official_blog_rss url: https://example.com/rss type: rss fields: [title, link, pubDate] check_interval: 600这里有个设计细节值得展开type字段决定了解析策略。HTML 类型依赖 CSS selector 提取结构化字段JSON 类型直接走json_path从开放接口里拿数据RSS 类型用标准 feed 解析器。三种数据源统一抽象成“给定一个 URL返回一份字段化的记录列表”下游完全不关心数据是从哪个平台、哪种格式来的。这种抽象让我后面加监测源非常快遇到一个纯文本页面加一个text类型写一个解析函数就接进去了。目标对象除了 URL 和解析方式还要定义check_interval。不同平台变化频率差异很大公告页可能一天更新一次热榜每几分钟就翻新。给每个目标单独配置间隔既保证监测密度又不浪费资源这也对应雷达对不同空域采用不同扫描周期。2.2 前端处理层归一化是重中之重采集到原始页面只是第一步真正决定监测质量的是“前端处理层”——把原始报文清洗成适合识别的形态。我见过太多项目卡在这里拿全文 hash 做指纹结果页面底部一个“今日访问量”的计数器跳了一下整条链路就误报一次一小时内告警刷屏几十条。归一化要解决的就是这个。我的处理流程分五步去掉 HTML 标签只留可见文本压缩连续空白字符把多换行、多空格统一成单个空格剔除时间戳和纯数字噪声公告日期、浏览量这类高频变动信息在指纹阶段要排除掉但它可以单独作为字段保留用来展示时间线去掉纯装饰节点比如页脚的备案号、广告位预留的占位文案对中文内容做全半角统一避免因为标点符号不同造成误判。import re import hashlib def normalize(raw_text: str) - str: text re.sub(r[^], , raw_text) text re.sub(r\s, , text) text re.sub(r\d{4}-\d{2}-\d{2}[\sT]?\d{0,2}:?\d{0,2}:?\d{0,2}, , text) text re.sub(r[\u4e00-\u9fa5], , text) return text.strip() def fingerprint(normalized: str) - str: return hashlib.sha256(normalized.encode(utf-8)).hexdigest()要注意的是归一化和字段提取是两条线。字段提取负责把你的目标信息变成结构化数据供展示和通知使用归一化负责生成一个稳定的指纹用于判断“变没变”。两个逻辑必须分开如果你为了归一化方便把结构化信息丢了后面想输出“这条公告是哪天发的”就抓瞎了。2.3 回波识别层指纹、相似度和规则引擎回波识别层解决“这个变化值不值得关心”。底层判断分两级先比指纹指纹不同说明内容确实变了再用相似度算法评估变化幅度幅度超过阈值才发告警。指纹比对用刚才的 64 位 SHA256碰撞概率在实际场景下可以忽略不计。判断逻辑是目标上次状态里存了一份指纹如果新指纹不一致说明检测到变化一致则说明内容稳定继续等待下一次巡检。相似度评估我用 Python 标准库 difflib 的 SequenceMatcher它在文本差异对比上足够快也足够准不需要额外安装第三方库。它返回一个 0 到 1 的比率1 表示完全一致。实际测试下来公告正文加了关键段落时相似度通常在 0.35 到 0.6 之间只是修正了一个错别字时在 0.8 到 0.95 之间。所以我给默认阈值定为 0.85高于这个值视为噪声变化不触发告警同时把差异片段打日志留痕。from difflib import SequenceMatcher def similarity(a: str, b: str) - float: return SequenceMatcher(None, a, b).ratio()规则引擎放在相似度之后给高级场景留了口子。比如限定只有标题命中“版本升级”“故障”“安全公告”等关键词时才告警或者指定某个 JSON 字段的数值变化跨过特定阈值才通知。规则是一组可插拔的 Python 函数每个函数接收解析后的结构化记录返回布尔值决定是否放行。2.4 目标追踪与告警分发层最后一层维护每个目标的“航迹”并负责告警分发。雷达里的航迹是目标位置的连续记录这里的航迹就是每个监测目标的指纹历史表这次指纹是什么上次是什么最近 24 小时变了几次上次告警是什么时间。告警分发的主要逻辑有三条防重复保险同一指纹在有效时间内只告警一次同告警类型在短时间内做聚合比如“热榜前三发生变化”只在每十分钟的窗口内汇总成一条消息告警消息里附上变化前后的关键字段差异而不是把整个页面原文塞进去。这样维护的人看一眼消息就知道发生了什么不用点开链接核对。分发通道默认走 Webhook我封装了一个统一的 sender 接口不同通道各自实现。钉钉/企业微信机器人接收 JSON 格式文本消息Telegram Bot 走它的 sendMessage 接口邮件走 SMTP 兜底。切换通道只需要改配置不用动业务代码。3. 实操过程从零跑通一套雷达系统3.1 项目骨架准备我建议把项目按功能拆成四个模块fetcher负责采集parser负责解析和归一化detector负责指纹比对和差异计算notifier负责告警分发。再加一个main.py做主流程调度config.yaml放所有目标配置。这个拆法坚持单一职责出了问题顺着模块名就能定位。环境方面只需要 Python 3.9第三方库装 requests、beautifulsoup4、lxml、PyYAML、APScheduler。前三个是采集解析标配PyYAML 读配置APScheduler 做定时调度。不需要装数据库驱动SQLite 是标准库自带的。3.2 核心流程采集、指纹、差异计算主流程我写成了一个可无限循环的巡检函数。每次巡检遍历所有目标根据每个目标的时间间隔决定是否需要本次抓取有变化就走差异分析和告警没变化就更新最后检查时间。import hashlib import time import random import requests from bs4 import BeautifulSoup class Target: def __init__(self, config): self.name config[name] self.url config[url] self.type config[type] self.selector config.get(selector) self.json_path config.get(json_path) self.fields config[fields] self.interval config.get(check_interval, 300) self.last_fingerprint None self.last_checked 0 def fetch(self): resp requests.get(self.url, timeout10, headers{User-Agent: Mozilla/5.0 PLFM_RADAR/1.0}) return resp.text def parse(self, raw): if self.type html: soup BeautifulSoup(raw, lxml) items soup.select(self.selector) return [self._extract_fields(item) for item in items[:20]] if self.type json: payload requests.get(self.url, timeout10).json() cur payload for key in self.json_path.strip($.).split(.): cur cur[key] return cur[:20] return []_extract_fields按 fields 配置逐个取文本内容取完后拼成一条字符串记录。指纹就在这条记录上生成。这里要注意字段拼接顺序必须固定不然同样的内容换个字段顺序就生成不同指纹那就会白白误报一次。差异计算要用新旧结构化数据对比不是直接对比整个网页。我保留上一次的结构化记录列表用名称或序号做匹配再对同一记录的新旧版本做相似度评估。比如热榜第 3 名从“A 内容”变成“B 内容”系统只针对这一条做差异提示输出格式是“热榜 第3名 标题变化旧 - 新”。3.3 告警接入Webhook 与邮件兜底Webhook 告警写起来很轻。拿企业微信群机器人举例只需要一个 POST 请求import requests def send_wecom_webhook(text: str, webhook_key: str): url fhttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?key{webhook_key} payload {msgtype: text, text: {content: text}} resp requests.post(url, jsonpayload, timeout10) if resp.status_code ! 200: raise RuntimeError(fwebhook send failed: {resp.text})Telegram Bot 是另一个通道代码几乎一样只是 URL 从企业微信改成api.telegram.org/bottoken/sendMessage参数从text改成chat_id加text。我写了一个 sender 分发层配置里写channel: wecom或channel: tg代码自动路由到对应实现。邮件兜底要在告警失败后启用。我设置了一个连续失败计数器Webhook 连续失败 3 次后切到 SMTP 发一封汇总邮件标题带WARNING: PLFM_RADAR webhook down内容带上最近五条待发送告警。这样既保证了消息不丢失又避免了反复请求已经失灵的 Webhook 浪费时间。3.4 雷达仪表盘可视化项目叫 PLFM_RADAR没有雷达扫描动画总觉得差点意思。我用 Flask 搭了个轻量可视化页面左侧一个模拟雷达屏幕以扫描线旋转的方式展示所有监测目标的“方位”目标按状态分三色——绿色稳定、黄色有变化待确认、红色告警触发过右侧是最近告警流按时间倒序显示底部是目标统计卡片。模拟雷达屏的核心是 CSS 动画加 JavaScript 定时请求。后台接口返回每个目标的状态和最后更新时间前端把目标坐标按名称 hash 映射到雷达盘的极坐标位置让每个目标的位置固定。扫描线用一段旋转的线性渐变色条模拟旋转周期 4 秒可以手动调。这在技术上没有难度但视觉效果非常直白老板或者同事走过来扫一眼就知道监测系统有没有异常。from flask import Flask, jsonify import sqlite3 app Flask(__name__) app.route(/api/radar) def radar_data(): con sqlite3.connect(radar.db) rows con.execute(SELECT name, status, updated_at FROM targets).fetchall() con.close() return jsonify([{name: r[0], status: r[1], updated_at: r[2]} for r in rows])前端轮询这个接口2 秒一次。这个频率很低不会对 Flask 造成压力。如果要再进一步可以加 WebSocket 推送但监测数据本身是分钟级的2 秒轮询完全足够没必要引入额外依赖。3.5 部署与定时调度生产环境我用 APScheduler 做进程内调度好处是不依赖系统 crontab单进程就能管所有目标。调度器用BackgroundScheduler给每个目标注册一个任务函数triggerinterval间隔取目标自己的check_interval。如果巡检一轮需要几分钟目标数量多了任务会跑出叠加所以加上max_instances1防止同一个任务并发执行。部署我用 systemd 管理写一个简单的 service 文件指定工作目录和 Python 路径Restartalways 保证挂了自动拉起。日志重定向到radar.out和radar.err方便用 journalctl 查问题。这里有个经验日志里必须带上每个目标的名称不然多个目标同时出错时你根本不知道哪条日志属于哪个目标。4. 常见问题与排查技巧实录4.1 误报和漏报的平衡误报是最先出现的问题。我一开始阈值设成 0.95结果页面改一个空白符都会告警。后来降到 0.5又发现真正重要的公告变化被淹没了。最后用一批历史变更数据做了校准把过去两个月的页面快照取出来逐一标注哪些变化是人会关心的再反推相似度的分界值。实测下来 0.85 这个阈值比较稳公告新增内容、热榜条目变化基本都能覆盖而浏览量、随机推荐位的波动基本被滤掉。漏报则主要来自归一化过度。有一次公告页改了版本号但因为我的归一化规则把所有纯数字都删了指纹居然没变导致漏掉一次重要更新。后来我调整策略数字不无脑删除而是把超高频变动的字段单独摘出来比如热榜的浏览量数字直接丢弃但公告里的版本号当成必留字段这样既滤噪又保住关键信号。4.2 目标站点改版解析器直接崩平台改版是监测类系统的宿命。最典型的现象是 CSS selector 匹配不到元素解析结果为空列表系统会一直告警“检测到空内容”真实变化反而被耽误。我加了结构自检如果某个目标连续三次解析结果为空自动进入“观察模式”只保留原始 HTML 到日志不再执行指纹对比和告警逻辑。另一个实用经验是双选择器策略。一个主选择器失效时自动启用备用选择器。比如公告列表用.article-list a匹配改版后变成.news-item a我在配置里加fallback_selector。解析器先尝试主选择器结果为空就尝试备用两个都失败才记为观察模式。这个机制让我平均缩短了至少半天的故障恢复时间。4.3 请求被限流的降级方案即使控制频率目标平台偶尔还是会限流。现象是请求返回 403、429或者频繁要求输入验证码。我的降级策略是分级的收到 429 时该目标强制退避 5 分钟期间不再发任何请求收到 403 时先换一个稳定的 User-Agent 重试一次还不行就停掉该目标等待人工介入连续三次网络超时自动把该目标标记为“不可达”状态仪表盘上变灰色停止无意义的重试。这里要强调的是我不做绕过验证码这类对抗操作。监测系统是在规则范围内做事碰上验证码说明对方的反爬机制认为这个请求有风险正确的做法是立刻收手而不是“技术上再想想办法”。这类问题上报给人工通过申请官方 API、加白名单之类的正规途径解决才是长期可持续的。4.4 看门狗监控系统自己也得被监控PLFM_RADAR 最尴尬的时刻是它自己挂了还不知道。我做了三层看门狗进程级、任务级、结果级。进程级由 systemd 的 Restartalways 保证崩溃自动拉起任务级在每个检测周期结束时写一条心跳记录超过 5 分钟没有新心跳外部健康检查接口就会返回 500结果级更关键——如果连续多次巡检没有任何目标发生变化也要发一条“静默通知”防止解析链路静默失效。所谓静默失效就是代码还在跑、进程还活着但解析逻辑已经坏了每条数据都解析成空列表系统看起来一切正常实际上什么都没监测到。这个坑特别隐蔽我第一次遇到时系统整整空转了三天。加上了静默通知后每当所有目标连续 6 个周期都零变化会有一条消息发到群里“雷达空域无信号请确认是否解析异常。”少了这条仪表盘再漂亮也是空中楼阁。现象可能原因快速处理办法告警刷屏指纹生成前未归一化检查是否剔除时间戳、纯数字、装饰文本漏报重要更新归一化误删了关键数字区分高频变化数字与业务关键数字后者保留解析结果为空目标站点改版查看原始 HTML 日志更新 selector 或启用备用选择器请求返回 429请求频率过高退避等待调大 check_interval请求返回 403反爬策略触发更换 UA停止攻击性行为走正规授权通道进程活着但零告警解析链路静默失效检查心跳记录确认解析器输出非空5. 一点实操体会PLFM_RADAR 整个项目做下来我最大的体会是“监测系统最难的不是抓数据而是决定什么值得通知人”。雷达再先进也不能把每只飞鸟都当成敌机报给指挥中心否则真正的威胁反而会被噪音淹没。这一层认知直接决定了架构形态我不追求抓取速度也不追求全量数据而是把所有精力放在归一化、指纹、相似度和规则这几个跟“判断力”有关的部分。另一个深刻的教训是任何网络数据源都不可靠平台改版、限流、宕机随时可能发生所以系统里所有容错路径都要走通一遍空解析怎么办连续超时怎么办告警通道失灵怎么办这些都要在正式上线前模拟一遍。即使这样上线后依然会有没预料到的意外所以心跳、静默通知、人工干预入口一个都不能少。如果你也想做一个类似的平台雷达我建议不要一上来就铺很大的目标面。找三四个真实关心、信息更新频繁的内容源先把采集、指纹、告警和可视化跑通让系统全天候运行一两周积累一批真实变化日志后再回头调阈值、加规则。到那个时候你对自己“到底需要感知哪些变化”的理解会比现在清晰得多做出的监测系统也才真正是为你服务的雷达。
