做独立开发和产品运营这几年我手机里装过的监控类工具一只手数不过来盯竞品变动要刷应用商店评论区盯行业风向要逛技术社区盯用户反馈要翻论坛和群消息。麻烦的地方在于每个平台都要单独登录、单独刷信息散得跟撒了一地似的真正有价值的变化常常淹没在每天几百条更新里。后来我断断续续花了几周空余时间从零写了一个叫 PLFM_RADAR 的小系统把“每个平台都去看”这件事收敛成一套统一逻辑采集、清洗、分析、告警全部自动化。PLFM_RADAR 这个名字是按我的习惯拆的PLFM 是 Platform 的缩写RADAR 就是雷达。合起来的含义很直白——平台雷达专门用来扫描多个线上平台的关键信号识别值得关注的异常变化然后第一时间推送提示。它能处理的具体场景包括某个开源项目热度是不是开始降温技术社区里有没有人集中讨论你所在的方向竞品产品页是不是悄悄改了描述目标关键词在近几个小时的讨论量是不是突然抬头。如果你在做独立开发、内容运营、产品增长或者任何偏情报分析的工作这篇文章就是 PLFM_RADAR 从命名到落地的完整复盘。我会把架构设计、数据采集、信号打分、告警通道以及踩过的坑都摆出来方便你在自己的场景里直接改造复用。1. PLFM_RADAR 到底在解决什么问题1.1 先想清楚你缺的其实不是信息而是“信号”项目启动之前我给自己列过一张“每天要刷的清单”GitHub Trending、几个技术社区的讨论区、行业产品的更新日志、应用商店的用户评论、若干个关键词的搜索结果。真正执行起来才发现每天两小时都未必刷得完而且大部分时间是在重复翻看没有变化的内容。信息从来都不缺缺的是把“发生了某件事”从信息流里及时捞出来的能力。系统要做的事本质上是把“信息”转化成“信号”。信息是持续流动的原始数据信号则是其中值得你停下手里的事去关注的变化点。PLFM_RADAR 的思路就是模仿雷达的工作原理持续发射扫描请求接收各平台返回的“回波”过滤掉大量不变的背景噪声只把“新出现的、符合关注条件的对象”标记出来。这也是我决定不靠人工盯屏而是写一套自动化系统的最核心理由。另一个出发点是成本。市面上做情报监控的 SaaS 不是没有但要么按关键词数量收费、要么数据只存在于对方平台、要么定制一个字段就要等排期。对于个人开发者或者三五人的小团队来说自己搭一套轻量系统虽然前期要花一些时间但后续的每一处改动都掌握在自己手里数据模型、告警规则、展示维度都能按自己的需求生长。1.2 三种常见玩法信息雷达、信号雷达、运营雷达同一个 PLFM_RADAR 的框架放在不同人手里可以玩出不一样的效果。我把它总结成三种典型用法你可以对照自己的角色来选。玩法关注的核心信号适合人群典型输出信息雷达指定平台的新增内容、更新动态独立开发者、内容从业者每日新增列表、更新提醒信号雷达关键词异动、讨论热度突变、竞品变化产品经理、市场运营、研究员实时告警、趋势报告运营雷达用户反馈关键词、口碑变化、需求线索运营人员、客服负责人问题聚类、需求热度排行我做这套系统时优先覆盖的是“信号雷达”场景因为它的收益最直观不用再每天手动刷几十个页面系统会在我睡觉的时候盯着早上起来只推送那些真正有变化的条目。后来给一位做电商选品的朋友改了一套配置他把采集源换成了几个行业论坛和商品评论页关注词换成了品类词加痛点词就变成了一套完全不同的选品情报雷达。这说明核心代码其实高度通用差异主要在采集源的配置和打分规则上。2. 整体架构与方案选型解析2.1 分层架构采集层、清洗层、分析层、消费层PLFM_RADAR 的整体结构我一开始就定了四层没有多犹豫因为这种分层对应的是数据生命周期里最自然的四个阶段。采集层负责从各平台拉取原始数据统一封装成“源记录”不管来源是 API、RSS 还是页面解析对外暴露的接口是一样的。清洗层负责去重、补全、规范化把不同平台的字段统一成同一个 schema比如统一时间格式、统一作者字段、统一内容摘要。分析层是雷达的核心它把清洗后的数据放到规则引擎和打分模型里跑一遍判断哪些条目应该升级为“信号”哪些只是噪声。消费层负责信号的出口包括告警推送、可视化面板、每日摘要邮件和数据归档。用雷达来类比就很容易理解采集层是天线和收发机清洗层是回波信号的前端处理分析层是目标识别算法消费层是操作员面前那块显示屏。每一层之间只通过规定的数据格式通信所以替换任何一层都不会影响其他层。比如我后期把告警通道从邮件换成了 Webhook只动了消费层其他三层完全没改。2.2 技术选型Python SQLite Flask 这套组合的取舍技术栈的选择上我走的是一条“够用且好维护”的路线没有追逐复杂组件。核心组合是 Python、SQLite、Flask 加几个轻量库整套系统跑在一台 2 核 4G 的云主机上资源占用非常低。选 Python 基本不需要解释requests 做 HTTP 拉取、BeautifulSoup 做页面解析、schedule 做定时任务、pandas 做分析计算、Flask 做展示层一条链路都是成熟生态写起来快出问题也好查。SQLite 是很多人会纠结的点为什么不用 MySQL 或者 PostgreSQL我的判断是这个系统的数据量在单机场景下完全在 SQLite 的能力范围内。我跑了三个月累计几十万条原始记录、几万条信号SQLite 一个文件就能装下查询速度依然毫秒级而且备份就是拷贝一个文件省去了数据库运维的负担。如果你后续要上多节点采集或者要做复杂的并发分析和报表再迁到 PostgreSQL 也不迟因为数据模型已经设计好了迁移成本很低。Flask 承担的是可视化面板和 Webhook 接收端的角色。它足够轻一个进程就够不需要引入前后端分离的工程结构。展示层我只做了少数几个页面今日信号、趋势折线、雷达图、历史回看。后期有些朋友建议我用 Django但对我来说 Flask 的简洁性本身就是生产力多出的功能用不上反而是负担。2.3 为什么不用现成的监控工具在动手写代码之前我认认真真评估过一轮现成工具结论是不能满足我需要的那种“信号研判”。舆情监控类 SaaS 的功能通常很全但定价是按关键词数量和采集平台数量走的个人承担起来偏贵关键点是数据模型是黑盒它不会告诉你“这条信号为什么触发了”而 PLFM_RADAR 的分析层必须能解释每个信号的得分来源。另一个现实限制是数据主权采集结果放在第三方平台上想导出做自己的历史分析比较困难。开源的采集框架和自动化工具我也试过两三个它们擅长的是“触发-执行”型的流程编排比如检测到某个页面变了就执行一个爬虫任务、发一条通知。这类工具在规则简单时很好用但一旦涉及“多个维度加权打分”“滚动窗口均值对比”“信噪比调优”这些分析逻辑就明显力不从心了。它们缺的是一个以“信号”为中心的数据模型所以我最终决定自己搭这套系统把数据模型和分析权利都握在自己手里。3. 数据采集层实操从零接入多平台信号3.1 采集源分类先把数据来源梳理清楚采集层是所有后续环节的原料入口这一层如果设计得乱后面清洗和分析都会很痛苦。我采用的分类方式是按数据获取方式区分因为不同获取方式决定了采集代码的写法、更新频率以及出错处理策略。直接 API 型源平台提供公开 API返回结构化 JSON。典型包括 GitHub API、Hacker News API、Product Hunt API。这类源最容易处理解析稳定、字段完整是首选的采集方式。结构化订阅型源平台提供 RSS/Atom 订阅虽然不是官方 API但同样是标准格式用 feedparser 解析非常方便。很多技术博客、社区公告、更新日志都保留了 RSS 输出可以直接利用。页面解析型源平台没有 API 也没有 RSS只能请求页面后用解析器提取关键信息比如产品介绍页的修改时间、商店评论区的最新评论。这类源需要额外小心后续我会专门说限制问题。分类完以后我维护了一张源配置表每条源记录包含源名称、类型、请求 URL、解析规则、更新频率、是否启用。解析规则用 JSON 存字段有 selector、attribute、regex 等几种类型。这样新增一个采集源时不需要改代码只要往配置表里加一行再写一个对应解析函数或者写一个通用的解析模板就可以。3.2 采集频率和增量策略怎么定采集频率是个看起来很随便、实际上很有讲究的参数。频率太高会被源站限流频率太低又会错过信号的时效性。我的经验不是一刀切而是按源的重要性和数据更新速度分别设置。GitHub 相关源每 6 小时一次快照因为仓库热度和趋势本来就是日级别的波动没必要每小时刷。Hacker News 这类活跃社区每 1 小时采集一次标题和分数变化是小时级别的。产品页、落地页每 4 小时拉一次同时记录响应体哈希值如果哈希没变就不入库这样能显著减少无效数据。应用商店评论、论坛新帖每天拉一次新增条目因为这类内容不追求分钟级告警更看重完整性。增量策略的核心是“增量游标”。API 型源通常返回 id 或 updated_at 字段我记录了每个源当前处理到的最大游标下次采集只取大于游标的数据。RSS 型源用条目的发布时间做过滤窗口只处理最近 24 小时内的新条目。页面解析型源用内容哈希做判断页面没变就不存页面变量再解析差异。这套策略跑下来重复数据量能压掉八成以上入库压力小了很多。3.3 限流、反爬与合规边界这几个坑绕不开采集层最容易翻车的地方不是代码而是对源平台的规则缺乏敬畏。我自己的原则有三条只采公开数据不做任何绕过登录态的采集严格遵守每个源公开的速率限制对源站的 robots 约定保持基本的尊重。以 GitHub 为例它的 API 对普通请求有每小时 5000 次的限制这个额度对监控场景来说完全充裕我实际只用到几百次。但如果不做任何节流直接高并发请求还是会触发 403。代码里我用了一个简单的限速器每个源请求之间至少间隔一个固定秒数并且加随机抖动避免出现准点齐射式的请求特征。同时也给每个请求设置了合法的 User-Agent标注到项目地址这样如果源站管理员看到日志也知道我是正常的监控用途。这个部分一定不能省。我见过有人在一个小型论坛上每分钟抓一次页面结果 IP 被封连正常访问都受影响。PLFM_RADAR 的价值是让它“持续、安静、不出格”地运行而不是给自己惹麻烦。3.4 数据表结构设计一个可以扛三个月演进的设计采集层的数据模型我用了四张核心表实际运行下来改动很少说明这个设计站得住。sources 表源配置字段包括 id、name、type、url、parse_rule、interval_minutes、enabled。raw_items 表原始数据统一 schema字段包括 id、source_id、external_id、title、content、author、url、published_at、created_at。seen 表去重表记录已经处理过的外部条目标识字段就两个external_key 和 first_seen_at配合唯一索引使用。signals 表分析层输出的信号字段包括 id、raw_item_id、keyword、rule_id、score、signal_type、created_at。schema 设计的关键点是 raw_items 表尽量用“宽表加 JSON 扩展”的方式核心字段全部显式建列方便检索和统计各平台特有字段统一塞进一个 extra 字段存 JSON避免频繁加列。seen 表是去重的关键external_key 用“源名 : 外部ID”拼接保证不同平台之间不会误判为同一条内容。4. 信号分析层把采集回来的噪音变成可执行的情报4.1 关键词规则与信号分类采集层解决的是“有没有新东西”分析层解决的是“新东西值不值得你看”。PLFM_RADAR 的分析层围绕规则引擎和打分模型展开这是整个系统里最值得花时间调优的部分。规则引擎我用的是“关键词规则表”加“评分算子”的组合。关键词规则表长这样每条规则包含关键词、作用域title、content、author 任意组合、运算方式包含、正则匹配、组合匹配、权重分。比如我配置过这样几条规则——关键词“PLFM_RADAR”作用域是 title 和 content权重 2.0关键词“竞品名 改版”是组合匹配要求两者同时出现在同一篇文章里权重 3.0关键词“用户反馈 闪退”是正则匹配权重 4.0用于抓质量问题信号。信号分类我分了三档情报型信号比如新项目发布、产品改版用来了解行业动向预警型信号比如关键词讨论量暴涨、质量反馈集中出现需要立刻关注常规型信号比如指定的博客更新了属于低优先级信息。分类决定了告警通道的差异预警型走即时推送情报型走日报汇总常规型基本只在面板里展示。4.2 热度打分模型用一套可解释的公式计算为了让信号优先级可量化我设计了一个热度打分模型核心思路是“不要只看单条内容还要看它在窗口期内的整体表现”。综合分由三个子分加权而成。权重分由规则引擎计算反映单条内容与你的关注方向的匹配程度取值范围 0 到 5。热度分统计同一个关键词在时间窗口内出现的次数经过归一化处理反映了这个话题最近的整体活跃度。来源可信度每个采集源有一个可信度系数比如官方 API 源 1.0普通论坛解析源 0.6避免低质量来源的噪声被过度放大。综合分 0.6 乘权重分 0.3 乘热度分 0.1 乘来源可信度。举个例子某技术社区一小时内有三个帖子包含关键词“自动化监控”每个帖子的权重分都是 1.5热度分归一化以后是 0.8来源可信度 0.8那么每条内容的综合分就是 0.6 乘 1.5 加 0.3 乘 0.8 加 0.1 乘 0.8等于 1.22。如果只出现一条孤立帖子权重分相同但热度分只有 0.2综合分就只有 1.04优先级明显降低。用这套公式可以把“偶尔有人提”和“突然很多人提”明确区分开。4.3 异常检测别被绝对值骗了要看相对变化打分模型解决的是存量信号的优先排序但还有一个更重要的场景是“这件事相较于平常是不是异常地多”。我最初的版本只设置了绝对阈值比如某个关键词一天出现 5 次就告警结果很快被噪声淹没。后来改成基于滚动窗口的异常检测效果好了很多。方法是维护每个关键词近 3 天的日出现次数序列计算均值和标准差然后用 Z-score 算法判断当天的情况是否显著偏离正常区间。比如某个关键词平时日均出现 2 次标准差 1.2今天突然出现 8 次Z-score 就是8 减 2除以 1.2 等于 5远大于告警线立刻触发预警。这个方法的优势是阈值自动适应不同关键词的流量特征热门大词和冷门精准词不需要分别拍脑袋定参数。给这个模块设置了一个保底机制如果关键词的历史数据太少日均不到 3 次就直接用绝对阈值兜底比如超过 5 次就告警避免小样本下 Z-score 波动过于剧烈导致频繁误报。自上线以来这套动态阈值比固定阈值的准确率高出一大截告警里真正值得看的比例明显上升。5. 告警与可视化落地让信号真正触达你5.1 告警通道配置选择 Webhook 作为标准出口信号只有触达人才有价值所以我给消费层设计了一个统一的告警出口Webhook。为什么选 Webhook 而不是邮件或短信因为它的适配性最强公司群、自建协作工具、甚至个人手机的推送服务都能通过 Webhook 接入而且配置起来就是发一个 HTTP POST 请求的事。推送模板我用的是 JSON核心字段包括信号类型、标题、内容摘要、URL、综合分、触发规则。实际推送时再根据通道不同做轻微调整比如群机器人类通道会附带 所有人的选项个人通道则不会。为了避免告警轰炸我实现了一个 15 分钟的聚合窗口同一关键词在同一窗口内只推一次重复信号只更新摘要里的次数字段。这个改动非常关键否则一个话题集中爆发时手机能在一小时里收到几十条几乎一样的内容。5.2 轻量雷达面板Flask 加 ECharts 做可视化可视化面板我选择了 Flask 提供后端接口、ECharts 负责前端图表渲染的组合。面板一共有三个页面今日信号列表、趋势总览、信号详情。今日信号列表是最常看的页面展示最近 24 小时产生的所有信号按综合分降序排列每条信号直接给出触发原因和来源链接。趋势总览里放了两张图一张是各采集源的数据量折线图用来观察不同平台活跃度变化另一张是信号数量的柱状图按天聚合方便看有没有异常峰值。信号详情页则针对单条信号展示原始内容、命中的关键词、各项子分。雷达图我放在趋势总览的角落用五个维度来评估系统的运行状态及时性、覆盖面、信噪比、可解释性、可行动性。每个维度的得分是最近 7 天相关指标的汇总归一化结果。这张图的用意是让我自己快速看出系统在哪方面偏科比如信噪比偏低就说明规则太宽需要提高关键词权重或者收紧分类阈值。5.3 数据归档与周报回看打分量和信号数据如果只用于实时查看就浪费了积累的价值。我在消费层里加了一个归档任务每天凌晨把前一天的所有原始数据和信号写进一张按日分区的快照表。每周一早上系统会生成一份周报包含本周信号总数、触发最多的话题关键词 Top 10、综合分最高的信号 Top 5以 HTML 邮件发送到指定邮箱。这份周报的价值在复盘时体现得非常明显。比如我通过周报发现某类信号连续三周占比上升但实时看的时候完全没有体感。归档数据也为我后续做更复杂的数据分析留出了空间比如训练一个简单的分类模型来替代部分人工规则这在最早期设计时就已经考虑进去了。6. 常见问题与排查技巧实录6.1 高频问题速查表运行这套系统半年多遇到的不少问题其实有很高的重复性整理成速查表方便自己排查也方便你直接套用。问题现象可能原因解决办法采集数据大量重复增量游标没记录或去重键设计错误检查 seen 表 external_key 是否带源前缀重新初始化游标告警半夜持续轰炸阈值过低 / 热度分计算方法不合理提高 Z-score 告警线给夜间时段加静默开关某个源返回 403请求频率过高或 User-Agent 被识别降低频率更换合法 UA检查是否需要使用官方 APISQLite 写入冲突采集任务和分析任务同时写库使用单线程写队列或用 WAL 模式减少锁等待信号打分普遍虚高权重分配不合理来源可信度没起作用调小权重分系数拉大不同来源的可信度差异面板一直无数据采集任务没启动或源配置被禁用检查 schedule 任务列表和 sources 表 enabled 字段6.2 几个我反复踩的深坑第一个坑是时区问题。最初我把采集时间统一存成本地时区结果每次部署到不同机器历史数据的时序都乱掉一段。后来统一改成 UTC 存储展示层再转换成本地时间这个问题彻底消失。所有时间字段一律存 UTC这是我在这个项目里学会的最重要的一条约定。第二个坑是采集重放机制。系统运行久了以后我偶尔需要重新跑某一天的采集来修复历史数据缺口。一开始以为直接把采集函数再跑一遍就行结果发现源站点会拒绝同样的高频请求而且数据重复率极高。后来我给每个采集批次都写成一条日志记录开始时间、结束时间、获取条数、新增条数、耗时并且把采集函数做成“可重放但幂等”重放时自动跳过 seen 表里已有的条目标识只补充缺失的部分。第三个坑是阈值漂移。动态阈值不是一次设置就能长期躺平的。某类关键词的讨论量会随行业热度变化三个月前还算正常的波动区间三个月后可能变成异常低点。我的解决办法是每个月给动态阈值模块重新计算一次历史基线并且把基线计算的输出也记录到数据库里方便追溯每次阈值调整的原因。系统不是石器时代刻好的石碑它应该跟行业一起生长。按照这套思路把 PLFM_RADAR 搭起来之后我自己最大的变化是盯屏时间大幅减少真正花在判断上的时间反而多了。以前每天刷几十个页面大部分是在确认“没变化”现在系统只推送“有变化”而我只需要做决策。如果你也想搭一套类似的平台雷达我的建议是别一上来就追求功能齐全先跑通一个采集源加一条告警规则的最小闭环等真正用起来以后再根据你遇到的痛点逐步加模块。这套东西最难的部分从来不是代码而是清楚自己到底要盯哪些信号、信号从哪里来、以及看到信号之后要做什么。把这些想明白了PLFM_RADAR 对你来说就是一层窗户纸。 
长河君 · 2026/11/2 10:33:36 · 阅读 1.2k 从零搭建跨平台信号监控系统：PLFM_RADAR 实战复盘
做独立开发和产品运营这几年我手机里装过的监控类工具一只手数不过来盯竞品变动要刷应用商店评论区盯行业风向要逛技术社区盯用户反馈要翻论坛和群消息。麻烦的地方在于每个平台都要单独登录、单独刷信息散得跟撒了一地似的真正有价值的变化常常淹没在每天几百条更新里。后来我断断续续花了几周空余时间从零写了一个叫 PLFM_RADAR 的小系统把“每个平台都去看”这件事收敛成一套统一逻辑采集、清洗、分析、告警全部自动化。PLFM_RADAR 这个名字是按我的习惯拆的PLFM 是 Platform 的缩写RADAR 就是雷达。合起来的含义很直白——平台雷达专门用来扫描多个线上平台的关键信号识别值得关注的异常变化然后第一时间推送提示。它能处理的具体场景包括某个开源项目热度是不是开始降温技术社区里有没有人集中讨论你所在的方向竞品产品页是不是悄悄改了描述目标关键词在近几个小时的讨论量是不是突然抬头。如果你在做独立开发、内容运营、产品增长或者任何偏情报分析的工作这篇文章就是 PLFM_RADAR 从命名到落地的完整复盘。我会把架构设计、数据采集、信号打分、告警通道以及踩过的坑都摆出来方便你在自己的场景里直接改造复用。1. PLFM_RADAR 到底在解决什么问题1.1 先想清楚你缺的其实不是信息而是“信号”项目启动之前我给自己列过一张“每天要刷的清单”GitHub Trending、几个技术社区的讨论区、行业产品的更新日志、应用商店的用户评论、若干个关键词的搜索结果。真正执行起来才发现每天两小时都未必刷得完而且大部分时间是在重复翻看没有变化的内容。信息从来都不缺缺的是把“发生了某件事”从信息流里及时捞出来的能力。系统要做的事本质上是把“信息”转化成“信号”。信息是持续流动的原始数据信号则是其中值得你停下手里的事去关注的变化点。PLFM_RADAR 的思路就是模仿雷达的工作原理持续发射扫描请求接收各平台返回的“回波”过滤掉大量不变的背景噪声只把“新出现的、符合关注条件的对象”标记出来。这也是我决定不靠人工盯屏而是写一套自动化系统的最核心理由。另一个出发点是成本。市面上做情报监控的 SaaS 不是没有但要么按关键词数量收费、要么数据只存在于对方平台、要么定制一个字段就要等排期。对于个人开发者或者三五人的小团队来说自己搭一套轻量系统虽然前期要花一些时间但后续的每一处改动都掌握在自己手里数据模型、告警规则、展示维度都能按自己的需求生长。1.2 三种常见玩法信息雷达、信号雷达、运营雷达同一个 PLFM_RADAR 的框架放在不同人手里可以玩出不一样的效果。我把它总结成三种典型用法你可以对照自己的角色来选。玩法关注的核心信号适合人群典型输出信息雷达指定平台的新增内容、更新动态独立开发者、内容从业者每日新增列表、更新提醒信号雷达关键词异动、讨论热度突变、竞品变化产品经理、市场运营、研究员实时告警、趋势报告运营雷达用户反馈关键词、口碑变化、需求线索运营人员、客服负责人问题聚类、需求热度排行我做这套系统时优先覆盖的是“信号雷达”场景因为它的收益最直观不用再每天手动刷几十个页面系统会在我睡觉的时候盯着早上起来只推送那些真正有变化的条目。后来给一位做电商选品的朋友改了一套配置他把采集源换成了几个行业论坛和商品评论页关注词换成了品类词加痛点词就变成了一套完全不同的选品情报雷达。这说明核心代码其实高度通用差异主要在采集源的配置和打分规则上。2. 整体架构与方案选型解析2.1 分层架构采集层、清洗层、分析层、消费层PLFM_RADAR 的整体结构我一开始就定了四层没有多犹豫因为这种分层对应的是数据生命周期里最自然的四个阶段。采集层负责从各平台拉取原始数据统一封装成“源记录”不管来源是 API、RSS 还是页面解析对外暴露的接口是一样的。清洗层负责去重、补全、规范化把不同平台的字段统一成同一个 schema比如统一时间格式、统一作者字段、统一内容摘要。分析层是雷达的核心它把清洗后的数据放到规则引擎和打分模型里跑一遍判断哪些条目应该升级为“信号”哪些只是噪声。消费层负责信号的出口包括告警推送、可视化面板、每日摘要邮件和数据归档。用雷达来类比就很容易理解采集层是天线和收发机清洗层是回波信号的前端处理分析层是目标识别算法消费层是操作员面前那块显示屏。每一层之间只通过规定的数据格式通信所以替换任何一层都不会影响其他层。比如我后期把告警通道从邮件换成了 Webhook只动了消费层其他三层完全没改。2.2 技术选型Python SQLite Flask 这套组合的取舍技术栈的选择上我走的是一条“够用且好维护”的路线没有追逐复杂组件。核心组合是 Python、SQLite、Flask 加几个轻量库整套系统跑在一台 2 核 4G 的云主机上资源占用非常低。选 Python 基本不需要解释requests 做 HTTP 拉取、BeautifulSoup 做页面解析、schedule 做定时任务、pandas 做分析计算、Flask 做展示层一条链路都是成熟生态写起来快出问题也好查。SQLite 是很多人会纠结的点为什么不用 MySQL 或者 PostgreSQL我的判断是这个系统的数据量在单机场景下完全在 SQLite 的能力范围内。我跑了三个月累计几十万条原始记录、几万条信号SQLite 一个文件就能装下查询速度依然毫秒级而且备份就是拷贝一个文件省去了数据库运维的负担。如果你后续要上多节点采集或者要做复杂的并发分析和报表再迁到 PostgreSQL 也不迟因为数据模型已经设计好了迁移成本很低。Flask 承担的是可视化面板和 Webhook 接收端的角色。它足够轻一个进程就够不需要引入前后端分离的工程结构。展示层我只做了少数几个页面今日信号、趋势折线、雷达图、历史回看。后期有些朋友建议我用 Django但对我来说 Flask 的简洁性本身就是生产力多出的功能用不上反而是负担。2.3 为什么不用现成的监控工具在动手写代码之前我认认真真评估过一轮现成工具结论是不能满足我需要的那种“信号研判”。舆情监控类 SaaS 的功能通常很全但定价是按关键词数量和采集平台数量走的个人承担起来偏贵关键点是数据模型是黑盒它不会告诉你“这条信号为什么触发了”而 PLFM_RADAR 的分析层必须能解释每个信号的得分来源。另一个现实限制是数据主权采集结果放在第三方平台上想导出做自己的历史分析比较困难。开源的采集框架和自动化工具我也试过两三个它们擅长的是“触发-执行”型的流程编排比如检测到某个页面变了就执行一个爬虫任务、发一条通知。这类工具在规则简单时很好用但一旦涉及“多个维度加权打分”“滚动窗口均值对比”“信噪比调优”这些分析逻辑就明显力不从心了。它们缺的是一个以“信号”为中心的数据模型所以我最终决定自己搭这套系统把数据模型和分析权利都握在自己手里。3. 数据采集层实操从零接入多平台信号3.1 采集源分类先把数据来源梳理清楚采集层是所有后续环节的原料入口这一层如果设计得乱后面清洗和分析都会很痛苦。我采用的分类方式是按数据获取方式区分因为不同获取方式决定了采集代码的写法、更新频率以及出错处理策略。直接 API 型源平台提供公开 API返回结构化 JSON。典型包括 GitHub API、Hacker News API、Product Hunt API。这类源最容易处理解析稳定、字段完整是首选的采集方式。结构化订阅型源平台提供 RSS/Atom 订阅虽然不是官方 API但同样是标准格式用 feedparser 解析非常方便。很多技术博客、社区公告、更新日志都保留了 RSS 输出可以直接利用。页面解析型源平台没有 API 也没有 RSS只能请求页面后用解析器提取关键信息比如产品介绍页的修改时间、商店评论区的最新评论。这类源需要额外小心后续我会专门说限制问题。分类完以后我维护了一张源配置表每条源记录包含源名称、类型、请求 URL、解析规则、更新频率、是否启用。解析规则用 JSON 存字段有 selector、attribute、regex 等几种类型。这样新增一个采集源时不需要改代码只要往配置表里加一行再写一个对应解析函数或者写一个通用的解析模板就可以。3.2 采集频率和增量策略怎么定采集频率是个看起来很随便、实际上很有讲究的参数。频率太高会被源站限流频率太低又会错过信号的时效性。我的经验不是一刀切而是按源的重要性和数据更新速度分别设置。GitHub 相关源每 6 小时一次快照因为仓库热度和趋势本来就是日级别的波动没必要每小时刷。Hacker News 这类活跃社区每 1 小时采集一次标题和分数变化是小时级别的。产品页、落地页每 4 小时拉一次同时记录响应体哈希值如果哈希没变就不入库这样能显著减少无效数据。应用商店评论、论坛新帖每天拉一次新增条目因为这类内容不追求分钟级告警更看重完整性。增量策略的核心是“增量游标”。API 型源通常返回 id 或 updated_at 字段我记录了每个源当前处理到的最大游标下次采集只取大于游标的数据。RSS 型源用条目的发布时间做过滤窗口只处理最近 24 小时内的新条目。页面解析型源用内容哈希做判断页面没变就不存页面变量再解析差异。这套策略跑下来重复数据量能压掉八成以上入库压力小了很多。3.3 限流、反爬与合规边界这几个坑绕不开采集层最容易翻车的地方不是代码而是对源平台的规则缺乏敬畏。我自己的原则有三条只采公开数据不做任何绕过登录态的采集严格遵守每个源公开的速率限制对源站的 robots 约定保持基本的尊重。以 GitHub 为例它的 API 对普通请求有每小时 5000 次的限制这个额度对监控场景来说完全充裕我实际只用到几百次。但如果不做任何节流直接高并发请求还是会触发 403。代码里我用了一个简单的限速器每个源请求之间至少间隔一个固定秒数并且加随机抖动避免出现准点齐射式的请求特征。同时也给每个请求设置了合法的 User-Agent标注到项目地址这样如果源站管理员看到日志也知道我是正常的监控用途。这个部分一定不能省。我见过有人在一个小型论坛上每分钟抓一次页面结果 IP 被封连正常访问都受影响。PLFM_RADAR 的价值是让它“持续、安静、不出格”地运行而不是给自己惹麻烦。3.4 数据表结构设计一个可以扛三个月演进的设计采集层的数据模型我用了四张核心表实际运行下来改动很少说明这个设计站得住。sources 表源配置字段包括 id、name、type、url、parse_rule、interval_minutes、enabled。raw_items 表原始数据统一 schema字段包括 id、source_id、external_id、title、content、author、url、published_at、created_at。seen 表去重表记录已经处理过的外部条目标识字段就两个external_key 和 first_seen_at配合唯一索引使用。signals 表分析层输出的信号字段包括 id、raw_item_id、keyword、rule_id、score、signal_type、created_at。schema 设计的关键点是 raw_items 表尽量用“宽表加 JSON 扩展”的方式核心字段全部显式建列方便检索和统计各平台特有字段统一塞进一个 extra 字段存 JSON避免频繁加列。seen 表是去重的关键external_key 用“源名 : 外部ID”拼接保证不同平台之间不会误判为同一条内容。4. 信号分析层把采集回来的噪音变成可执行的情报4.1 关键词规则与信号分类采集层解决的是“有没有新东西”分析层解决的是“新东西值不值得你看”。PLFM_RADAR 的分析层围绕规则引擎和打分模型展开这是整个系统里最值得花时间调优的部分。规则引擎我用的是“关键词规则表”加“评分算子”的组合。关键词规则表长这样每条规则包含关键词、作用域title、content、author 任意组合、运算方式包含、正则匹配、组合匹配、权重分。比如我配置过这样几条规则——关键词“PLFM_RADAR”作用域是 title 和 content权重 2.0关键词“竞品名 改版”是组合匹配要求两者同时出现在同一篇文章里权重 3.0关键词“用户反馈 闪退”是正则匹配权重 4.0用于抓质量问题信号。信号分类我分了三档情报型信号比如新项目发布、产品改版用来了解行业动向预警型信号比如关键词讨论量暴涨、质量反馈集中出现需要立刻关注常规型信号比如指定的博客更新了属于低优先级信息。分类决定了告警通道的差异预警型走即时推送情报型走日报汇总常规型基本只在面板里展示。4.2 热度打分模型用一套可解释的公式计算为了让信号优先级可量化我设计了一个热度打分模型核心思路是“不要只看单条内容还要看它在窗口期内的整体表现”。综合分由三个子分加权而成。权重分由规则引擎计算反映单条内容与你的关注方向的匹配程度取值范围 0 到 5。热度分统计同一个关键词在时间窗口内出现的次数经过归一化处理反映了这个话题最近的整体活跃度。来源可信度每个采集源有一个可信度系数比如官方 API 源 1.0普通论坛解析源 0.6避免低质量来源的噪声被过度放大。综合分 0.6 乘权重分 0.3 乘热度分 0.1 乘来源可信度。举个例子某技术社区一小时内有三个帖子包含关键词“自动化监控”每个帖子的权重分都是 1.5热度分归一化以后是 0.8来源可信度 0.8那么每条内容的综合分就是 0.6 乘 1.5 加 0.3 乘 0.8 加 0.1 乘 0.8等于 1.22。如果只出现一条孤立帖子权重分相同但热度分只有 0.2综合分就只有 1.04优先级明显降低。用这套公式可以把“偶尔有人提”和“突然很多人提”明确区分开。4.3 异常检测别被绝对值骗了要看相对变化打分模型解决的是存量信号的优先排序但还有一个更重要的场景是“这件事相较于平常是不是异常地多”。我最初的版本只设置了绝对阈值比如某个关键词一天出现 5 次就告警结果很快被噪声淹没。后来改成基于滚动窗口的异常检测效果好了很多。方法是维护每个关键词近 3 天的日出现次数序列计算均值和标准差然后用 Z-score 算法判断当天的情况是否显著偏离正常区间。比如某个关键词平时日均出现 2 次标准差 1.2今天突然出现 8 次Z-score 就是8 减 2除以 1.2 等于 5远大于告警线立刻触发预警。这个方法的优势是阈值自动适应不同关键词的流量特征热门大词和冷门精准词不需要分别拍脑袋定参数。给这个模块设置了一个保底机制如果关键词的历史数据太少日均不到 3 次就直接用绝对阈值兜底比如超过 5 次就告警避免小样本下 Z-score 波动过于剧烈导致频繁误报。自上线以来这套动态阈值比固定阈值的准确率高出一大截告警里真正值得看的比例明显上升。5. 告警与可视化落地让信号真正触达你5.1 告警通道配置选择 Webhook 作为标准出口信号只有触达人才有价值所以我给消费层设计了一个统一的告警出口Webhook。为什么选 Webhook 而不是邮件或短信因为它的适配性最强公司群、自建协作工具、甚至个人手机的推送服务都能通过 Webhook 接入而且配置起来就是发一个 HTTP POST 请求的事。推送模板我用的是 JSON核心字段包括信号类型、标题、内容摘要、URL、综合分、触发规则。实际推送时再根据通道不同做轻微调整比如群机器人类通道会附带 所有人的选项个人通道则不会。为了避免告警轰炸我实现了一个 15 分钟的聚合窗口同一关键词在同一窗口内只推一次重复信号只更新摘要里的次数字段。这个改动非常关键否则一个话题集中爆发时手机能在一小时里收到几十条几乎一样的内容。5.2 轻量雷达面板Flask 加 ECharts 做可视化可视化面板我选择了 Flask 提供后端接口、ECharts 负责前端图表渲染的组合。面板一共有三个页面今日信号列表、趋势总览、信号详情。今日信号列表是最常看的页面展示最近 24 小时产生的所有信号按综合分降序排列每条信号直接给出触发原因和来源链接。趋势总览里放了两张图一张是各采集源的数据量折线图用来观察不同平台活跃度变化另一张是信号数量的柱状图按天聚合方便看有没有异常峰值。信号详情页则针对单条信号展示原始内容、命中的关键词、各项子分。雷达图我放在趋势总览的角落用五个维度来评估系统的运行状态及时性、覆盖面、信噪比、可解释性、可行动性。每个维度的得分是最近 7 天相关指标的汇总归一化结果。这张图的用意是让我自己快速看出系统在哪方面偏科比如信噪比偏低就说明规则太宽需要提高关键词权重或者收紧分类阈值。5.3 数据归档与周报回看打分量和信号数据如果只用于实时查看就浪费了积累的价值。我在消费层里加了一个归档任务每天凌晨把前一天的所有原始数据和信号写进一张按日分区的快照表。每周一早上系统会生成一份周报包含本周信号总数、触发最多的话题关键词 Top 10、综合分最高的信号 Top 5以 HTML 邮件发送到指定邮箱。这份周报的价值在复盘时体现得非常明显。比如我通过周报发现某类信号连续三周占比上升但实时看的时候完全没有体感。归档数据也为我后续做更复杂的数据分析留出了空间比如训练一个简单的分类模型来替代部分人工规则这在最早期设计时就已经考虑进去了。6. 常见问题与排查技巧实录6.1 高频问题速查表运行这套系统半年多遇到的不少问题其实有很高的重复性整理成速查表方便自己排查也方便你直接套用。问题现象可能原因解决办法采集数据大量重复增量游标没记录或去重键设计错误检查 seen 表 external_key 是否带源前缀重新初始化游标告警半夜持续轰炸阈值过低 / 热度分计算方法不合理提高 Z-score 告警线给夜间时段加静默开关某个源返回 403请求频率过高或 User-Agent 被识别降低频率更换合法 UA检查是否需要使用官方 APISQLite 写入冲突采集任务和分析任务同时写库使用单线程写队列或用 WAL 模式减少锁等待信号打分普遍虚高权重分配不合理来源可信度没起作用调小权重分系数拉大不同来源的可信度差异面板一直无数据采集任务没启动或源配置被禁用检查 schedule 任务列表和 sources 表 enabled 字段6.2 几个我反复踩的深坑第一个坑是时区问题。最初我把采集时间统一存成本地时区结果每次部署到不同机器历史数据的时序都乱掉一段。后来统一改成 UTC 存储展示层再转换成本地时间这个问题彻底消失。所有时间字段一律存 UTC这是我在这个项目里学会的最重要的一条约定。第二个坑是采集重放机制。系统运行久了以后我偶尔需要重新跑某一天的采集来修复历史数据缺口。一开始以为直接把采集函数再跑一遍就行结果发现源站点会拒绝同样的高频请求而且数据重复率极高。后来我给每个采集批次都写成一条日志记录开始时间、结束时间、获取条数、新增条数、耗时并且把采集函数做成“可重放但幂等”重放时自动跳过 seen 表里已有的条目标识只补充缺失的部分。第三个坑是阈值漂移。动态阈值不是一次设置就能长期躺平的。某类关键词的讨论量会随行业热度变化三个月前还算正常的波动区间三个月后可能变成异常低点。我的解决办法是每个月给动态阈值模块重新计算一次历史基线并且把基线计算的输出也记录到数据库里方便追溯每次阈值调整的原因。系统不是石器时代刻好的石碑它应该跟行业一起生长。按照这套思路把 PLFM_RADAR 搭起来之后我自己最大的变化是盯屏时间大幅减少真正花在判断上的时间反而多了。以前每天刷几十个页面大部分是在确认“没变化”现在系统只推送“有变化”而我只需要做决策。如果你也想搭一套类似的平台雷达我的建议是别一上来就追求功能齐全先跑通一个采集源加一条告警规则的最小闭环等真正用起来以后再根据你遇到的痛点逐步加模块。这套东西最难的部分从来不是代码而是清楚自己到底要盯哪些信号、信号从哪里来、以及看到信号之后要做什么。把这些想明白了PLFM_RADAR 对你来说就是一层窗户纸。