轻量监控预警系统设计：从指标采集到告警降噪的工程实践

1. 项目思路与整体架构拆解

1.1 项目背景与核心目标

PLFM_RADAR 是我在维护多个线上业务平台时沉淀出来的一个监控预警项目。当时的情况比较典型：手上有三套业务系统、五台云服务器、两套自建中间件，分别跑着订单服务、消息推送和报表任务，每次出问题都是用户先反馈，我再被动定位。真正让人头疼的不是故障本身，而是故障总是以分散、零碎的方式抵达——某台机器 CPU 飙了、某个接口响应变慢了、某条消息积压了，这些信号如果单独看，都只是普通的资源波动，但放在一起往往就是一次业务故障的前兆。

PLFM_RADAR 这个名字拆开来看很直白，PLFM 可以理解成 Platform，RADAR 则是雷达，合在一起就是一套面向平台运行状态的监测雷达系统。它要解决的核心问题是：把分散在服务器、应用、中间件和网络链路中的运行指标汇聚到同一个视图中，通过多维度的状态扫描和阈值判定，在故障影响业务之前发出预警。做这个项目之前我也评估过现成的开源监控方案，比如 Prometheus 加 Grafana、Zabbix 这类组合，功能确实全面，但有两个问题不太贴合我的场景：一是太重，对于只有几台服务器的小团队来说，光是维护监控系统本身就成了额外负担；二是默认的告警能力偏弱，往往需要配置大量规则才能达到我想要的效果。PLFM_RADAR 走的是轻量路线——采集端只部署一个二进制代理，服务端用轻量的时序数据库存储，前端用雷达图加指标卡片做可视化，整体架构足够小，小到一台 2 核 4G 的机器就能全部跑起来。

这个项目适合三类读者参考：正在做基础设施监控选型的中小团队、想自建轻量监控系统的独立开发者，以及刚接触可观测性、想弄明白指标采集和告警链路到底怎么运作的运维新手。我分享的内容会聚焦在实际踩坑和设计决策上，大部分代码和配置都能直接改改拿去用。

1.2 "雷达"这个隐喻带来的设计启发

很多人听到 RADAR，第一反应就是那种一圈一圈扫描的雷达屏。我在设计 PLFM_RADAR 的可视化时，刻意保留了这种意象——但不仅仅是视觉上的还原，而是让"雷达扫描"这个隐喻贯穿到监控逻辑里去。

真实雷达的工作原理是发射脉冲、接收回波、通过回波的延迟和方向判断目标的位置和移动。PLFM_RADAR 的扫描逻辑类似：每隔固定时间向各个监测点发起探测请求，拉取系统指标或主动上报的数据，然后对回传数据做解析和判定，判断是否存在超出阈值的异常指标。我在数据采集频率上选了 15 秒一个周期，这是基于实际场景的折中——对于 CPU、内存这类动态指标，15 秒的粒度足够捕捉到大多数异常波峰，同时不会给采集代理和存储层带来过大的写入压力。如果用 1 秒的粒度，在指标数量多的时候会产生大量的时序数据写入，存储占用和查询耗时会成倍上升，而实际收益并不明显。

雷达图在可视化层的应用也做了思考。传统的折线图适合看单个指标的时间趋势，但当一个平台涉及多个维度时，用雷达图来展示"当前整体状态"反而更直观——每个轴代表一个指标维度（CPU 使用率、内存占用、磁盘 IO、网络流量、服务响应时间、错误率），轴的半径代表指标的健康程度，越靠近中心说明越紧张。这样整个平台的运行状态在一张图上就能扫出来，和雷达的直觉完全一致。实际使用中，我把雷达图放在监控大屏的中心区域，再配合侧边的指标明细列表，需要快速判断"现在到底哪里有问题"的时候，扫一眼雷达图比逐个看一堆折线图快得多。

1.3 技术选型与方案对比

在技术选型上，我最初列过三个候选方案：完全自研、基于开源组件拼装、半自研半开源。完全自研意味着采集器、存储、可视化全都要自己写，工作量太大，而且时序存储这种基础组件自己写很难达到成熟产品的稳定性，所以直接排除了。基于开源组件拼装是最省力气的选择，但前面说过，Prometheus + Grafana 这套组合的分工非常明确——前者做采集和存储，后者做展示和告警——但带来的问题是组件多、配置复杂，中间任意一环连接出问题，排查链路会特别长。最终的方案是半自研：用 Go 写一个轻量采集代理，用 SQLite 配合定时聚合表做存储，前端用 Vue 加 ECharts 做雷达图和指标卡片。三部分之间有清晰的接口边界，每一层都能独立替换。

下面是几个关键选型的对比表格，方便你按自己的场景来取舍：

这套选型的核心思路是：在指标规模可控的前提下，优先降低运维复杂度。如果你管理的服务器数量超过 20 台、指标量达到每秒数万条写入，SQLite 的方案会明显吃力，那时候建议把存储层替换成 Prometheus 或 VictoriaMetrics，前端的查询接口做兼容适配就行。我在设计存储层接口时特意隔离了一层，就是为了后续替换存储引擎时不至于动到上层逻辑。

2. 数据采集层的核心实现与细节

2.1 采集器的工作机制

PLFM_RADAR 的采集器是整套系统里最容易被低估的部分。表面上它做的事情很简单——每隔 15 秒收集一次 CPU、内存、磁盘、网络等系统指标，然后发送到服务端——但实际做下来有很多细节需要处理。

采集器用 Go 编写，主要利用 gopsutil 库来获取系统指标。相比直接在命令行里解析 top、free 这类命令的输出，gopsutil 在跨平台一致性和性能上都要好很多。在 Linux 上它通过读取 /proc 文件系统来获取数据，内存分配和系统调用次数都做了优化，实测采集一次全量系统指标（CPU 每核使用率、内存详细分配、磁盘分区读写字节数、网络接口收发字节数、进程列表 TOP10）大约耗时 30 毫秒左右，CPU 占用几乎可以忽略。

采集器不是单纯地发一次数据就完事，它内部有一个上报协议。每轮采集完成后，采集器把指标按 JSON 格式封装，通过 HTTP POST 请求发送到服务端的 /api/ingest 接口。服务端返回 200 后采集器继续下一轮采集，如果返回 429（服务端处理不过来）或者超时，采集器会把当轮数据写入本地磁盘的缓冲文件里，下轮采集时再重新上报。这个缓冲机制非常关键，它保证在服务端短暂不可用的情况下（比如重启、网络抖动），采集端不会丢数据。我在项目里把缓冲文件按天滚动存储，默认保留 7 天，超过 7 天会自动清理，避免磁盘被写满。

// 采集器核心循环逻辑（简化版） func collectAndReport() { for { metrics := collectSystemMetrics() // 采集 CPU/内存/磁盘/网络指标 payload := buildPayload(metrics) // 组装 JSON 数据包 err := reportToServer(payload) // 上报到 PLFM_RADAR 服务端 if err != nil { bufferToLocalDisk(payload) // 写本地缓冲文件 } time.Sleep(15 * time.Second) // 等 15 秒执行下一轮 } }

上面这段代码是采集器的核心主循环，实际项目中 collectSystemMetrics 函数内部会读取每个 CPU 核心的使用率并计算整体均值，磁盘部分特殊处理了根分区和其他数据分区——因为某些机器会把数据盘挂在独立分区上，单独看整机磁盘使用率容易漏掉局部磁盘满的问题。这个细节是我在实际运维中踩到过的坑：有个数据分区写满了才发现，当时检查整机磁盘使用率还不到 60%。

2.2 服务端接入层的设计

服务端接收入口用 Go 的 net/http 标准库实现，并没有引入特别重的框架。接收端的逻辑需要考虑一个问题：如果采集代理发来指标数据时服务端正在做其他耗时操作（比如生成聚合报表），接收接口不能阻塞，否则采集器会大量超时。

我用的处理方式是异步接收加内存队列。HTTP handler 接收到指标数据后，先快速校验数据的格式和时间戳合法性，然后写入一个容量为 10000 条的环形队列，真正的入库操作由后台消费者协程从队列中取出数据批量写入。这样做的好处是吞吐量高，即使数据写入速度突然增加（比如瞬时大量采集器同时上报），也只是队列积压，不会把 HTTP 接口拖垮。队列积压超过容量时，服务端会返回 429 状态码，采集器收到后就会走本地缓冲逻辑。

这里有一个容易踩的坑——指标数据的格式设计。最开始我把每个指标都作为一个独立的 JSON 字段上报，后来发现写 SQLite 时要逐字段解析，代码又长又容易错。后来改成了统一的指标数组结构：每条记录包含指标名称、取值、采集时间戳和维度标签（比如 host、ip、instance），无论系统指标还是应用自定义指标，都走同一套格式。这个改造之后，接入层的代码量减少了一半，而且新增指标类型时完全不用改接入逻辑。

{ "agent_id": "host-01", "timestamp": 1710000000, "metrics": [ {"name": "cpu_usage", "value": 23.5, "labels": {"core": "0"}}, {"name": "mem_usage_percent", "value": 67.8, "labels": {}}, {"name": "disk_used_percent", "value": 82.1, "labels": {"mount": "/data"}} ] }

注意看上面的 JSON 结构，每条指标都带有 labels 字段。这个设计让同一个指标名称可以携带不同的维度信息，比如 disk_used_percent 指标通过 labels 区分不同挂载点，网络指标通过 labels 区分不同网卡。在写查询时，就可以像"查主机 host-01 上挂载点为 /data 的磁盘使用率"这样精确筛选。

2.3 指标采集的常见误区

采集层做久了，我发现有几个问题是很多人都会遇到的。第一个是 CPU 使用率的计算方式。如果直接用 CPU 时间片的增量去算，不处理主机重启或 CPU 频率变化的情况，会出现超过 100% 或者负数这种诡异的数值。gopsutil 库已经封装好了这块逻辑，但如果你是自己读 /proc/stat，一定要先取两次采样值的差值，再除以间隔时间得到使用率，单次采样值是没有意义的。

第二个是采集频率的选择。有些朋友为了"实时性"，把采集间隔压到 2 秒甚至 1 秒，结果就是数据库的写入量暴涨，查询性能变差，最后反而连正常的告警都延迟了。以我的经验，系统指标 15 秒间隔足够，业务指标（比如订单量、请求量）可以短一些，5 秒到 10 秒之间，但要配合批量写入和定期聚合的策略，否则存储迟早会成为瓶颈。

第三个是数据精度问题。SQLite 存储浮点数时，如果直接存 float64 类型，查询出来可能会有很长的小数尾巴，展示时还要做四舍五入。我在存储层统一把指标值乘以 100 后转成整数存储，展示时再除以 100，这样既避免了浮点精度问题，又意外地压缩了存储空间——整数在 SQLite 中占的字节更少。这个看起来不起眼的优化，在积累了上百万条指标后，效果还是挺明显的。

3. 存储与告警引擎的设计与实现

3.1 数据模型与聚合策略

PLFM_RADAR 的存储层用的是 SQLite，很多人第一反应是"SQLite 能撑住监控数据的写入吗"。说实话，如果你的指标量一天只有几十万条，SQLite 完全没压力。但如果每秒写入几千条、长时间持续跑，SQLite 的单写者模型就会出现锁竞争，写入速度明显下滑。

我在设计时用了两个方法规避这个问题。第一个是批量写入，采集代理上报到服务端后，服务端不是逐条插入，而是攒够 100 条或者每隔 1 秒批量执行一次 INSERT 事务。这样把随机写变成了顺序写，SQLite 的写入吞吐量提升非常大。第二个是数据分级存储，原始指标明细写入 metrics_detail 表，只保留 24 小时；同时后台每隔 5 分钟执行一次聚合任务，把原始数据按 5 分钟窗口聚合，生成均值、最大值、最小值，写入 metrics_5m 表，这张表保留 30 天。

-- 聚合任务核心 SQL（每 5 分钟执行一次） INSERT INTO metrics_5m (metric_name, host, labels, avg_value, max_value, min_value, window_start) SELECT metric_name, host, labels, AVG(value) AS avg_value, MAX(value) AS max_value, MIN(value) AS min_value, strftime('%s', 'now') / 300 * 300 AS window_start FROM metrics_detail WHERE timestamp >= strftime('%s', 'now') - 300 GROUP BY metric_name, host, labels, window_start;

这个聚合查询我已经在项目里实际跑过，300 万条明细数据执行一次大约 1.2 秒，完全在接受范围内。5 分钟粒度对于查看半小时到一周的趋势图都够用，只有排查最近 24 小时内的突发问题时，才会去查原始明细表的秒级数据。这种分层设计有一个明显的好处：查询近期趋势时走 metrics_5m 表，扫描行数少了两个数量级，加载速度自然快；查询实时数据时只用看最近 15 秒写进来的明细，范围很小，延迟也低。如果 SQLite 未来扛不住，平滑迁移到时序数据库时，这种明细加聚合的双表模型也能直接平移过去。

3.2 告警规则引擎的规则模型

告警是 PLFM_RADAR 的核心能力之一，规则引擎的设计直接决定了它能不能在故障发生前及时提醒你。我把告警规则设计成了一张规则表，每条规则包含指标名称、比较条件、阈值、持续时间、通知模板这几个核心字段。比较条件支持大于、小于、大于等于、小于等于四种，持续时间的概念很重要——比如 CPU 使用率超过 90% 持续 5 分钟才告警，这样可以过滤掉瞬时尖峰造成的误报。

规则表的结构大概是这样的：

CREATE TABLE alert_rules ( id INTEGER PRIMARY KEY, rule_name TEXT NOT NULL, metric_name TEXT NOT NULL, condition TEXT NOT NULL, -- gt/lt/gte/lte threshold REAL NOT NULL, duration_seconds INTEGER DEFAULT 300, notify_channel TEXT DEFAULT 'webhook', enabled INTEGER DEFAULT 1, created_at INTEGER );

告警引擎每 15 秒运行一次，扫描最近一个窗口内的指标数据，和所有启用的规则做匹配。匹配逻辑不是简单地把当前值拿出来比较就完了，而是检查"持续了多久"。我实现的方式是在内存里维护一个状态对象，记录每条规则在当前指标上的连续触发次数。比如持续时间设定 300 秒、判定频率 15 秒一次，那么连续 20 次判定都超过阈值，才会真正触发告警。一旦某次判定恢复正常，连续计数清零，不会把中断的异常延续下去。

在告警恢复的通知上，我也加了一个"恢复通知"逻辑：当一条规则从触发状态回到正常状态时，会发送一条恢复消息，说明异常已经解除。这样整个告警生命周期是闭环的——触发时通知、恢复时也通知，不会出现告警风暴之后静默无声的情况，你在群里看到一条告警，心里会有个预期，等恢复消息来了就确认故障处理完了。

3.3 告警降噪：防止告警风暴

告警降噪是最能体现工程经验的地方。我刚上线 PLFM_RADAR 的时候，因为没有降噪机制，第一天就收到了 278 条告警，整个工作群被刷爆。后来我加了三个层面的降噪机制：

第一层是持续时间过滤，这个前面提到过，把瞬时抖动排除在外。但要注意持续时间不能设得太长，否则真正的问题也会被延迟通知。我通常建议 CPU、内存这类系统指标设 3 到 5 分钟，业务指标（比如接口错误率、订单积压量）设 1 到 2 分钟，因为业务指标直接关联用户体验，响应要更快。

第二层是告警聚合。同一台机器上同时出现 CPU 高和内存高，这两条告警如果独立发送，人会觉得很吵闹。我在告警引擎里加了聚合维度，默认按主机聚合，也就是同一台机器在 10 分钟内产生的所有告警合并成一条消息，消息里列出具体触发了几条规则、当前指标值是多少。对于跨多台机器的批量异常，可以按业务分组聚合，比如"订单服务集群 3 台机器同时 CPU 高"，这样运维人员在一条消息里就能判断这是集群级故障还是单机异常。

第三层是静默期。当一个告警规则触发后，同一规则的再次告警会进入 30 分钟的静默期，避免故障恢复前的反复横跳产生重复消息。30 分钟这个值是我调过好几轮的结果——太短没有降噪效果，太长可能漏掉真正的二次故障。如果你的业务告警要求特别实时，可以缩短到 15 分钟，但不要低于 10 分钟，否则告警疲劳很快就会出现。

3.4 告警规则配置的实操写法

实际配置告警规则时，我用的是 JSON 配置文件。这样做的原因很简单：规则变化频繁，用配置文件就不用每次改代码重新部署。下面是一个实际的规则配置示例，我直接贴出来供参考：

[ { "rule_name": "CPU 使用率过高", "metric_name": "cpu_usage", "condition": "gte", "threshold": 90, "duration_seconds": 300, "notify_channel": "webhook", "labels_match": {"host": "web-server-01"} }, { "rule_name": "磁盘剩余空间不足", "metric_name": "disk_free_percent", "condition": "lte", "threshold": 15, "duration_seconds": 600, "notify_channel": "webhook", "labels_match": {"mount": "/data"} } ]

注意第一个和第二个规则的差异：CPU 规则只需要看整体数值，所以不需要额外匹配标签；磁盘规则匹配了 mount 标签为 /data 的数据分区，因为在生产机器上系统盘和数据盘必须要分开盯，只设一个磁盘使用率规则会漏掉数据盘满的问题。labels_match 字段让规则可以精确指定要看哪些维度的指标，这个设计在排查特定分区、特定网卡问题时特别有用。

收到告警后的处理流程也应该提前想好。PLFM_RADAR 的告警消息里附带了一个查询链接，点击后可以直接跳到 PLFM_RADAR 对应指标的时间范围页面，省去手动搜索的步骤。这个细节虽然不起眼，但在实际故障处理时能节省很多时间，尤其是当你同时收到两三条告警、需要在短时间内定位原因的时候。

4. 可视化层：雷达图、趋势图与监控大屏

4.1 雷达图的维度设计与实现

可视化层的核心是雷达图。在 ECharts 中实现雷达图不算复杂，难点在于如何定义"健康程度"这个指标。我采用的方案是一个打分机制：每个监控维度先设定一个最大值和最小值（比如 CPU 使用率的范围是 0 到 100），然后根据当前值线性映射到一个 0 到 100 的健康分。这样雷达图的所有轴就统一到了同一个量纲上，可以直观地比较不同维度之间的紧张程度。

维度选择上，系统级别的雷达图设计为六个轴：CPU 使用率、内存使用率、磁盘使用率、网络带宽使用率、服务响应时间、错误率。前四个是资源维度，后两个是业务品质维度。前四个针对的是基础设施的健康状况，后两个则直接反映服务质量和用户体验。六轴雷达图在视觉上足够丰富，又不至于因为轴太多而难以辨认。

雷达图的具体实现涉及两块：ECharts 配置和前端取数逻辑。配置部分生成雷达图的方式并不复杂，关键是取数逻辑要去查询聚合表：

// Vue 组件中的雷达图取数与更新逻辑 async function updateRadarChart() { const host = this.selectedHost; // 当前选中的主机 const res = await fetch(`/api/snapshot?host=${host}&window=1m`); const data = await res.json(); const indicators = [ { name: 'CPU', max: 100 }, { name: '内存', max: 100 }, { name: '磁盘', max: 100 }, { name: '网络', max: 100 }, { name: '响应时间', max: 100 }, { name: '错误率', max: 100 } ]; const seriesData = [ { value: [ data.cpu_usage.healthScore, data.mem_usage.healthScore, data.disk_usage.healthScore, data.network_usage.healthScore, data.response_time.healthScore, data.error_rate.healthScore ] } ]; radarChart.setOption({ indicators, series: [{ type: 'radar', data: seriesData }] }); }

这个接口返回的是一个快照，"一分钟内的最新指标值换算出的健康分"。健康分的计算逻辑是：如果实际值小于最大值的 60%，算健康区间，得分从 100 线性下降；超过 60% 之后下降速度加快，到 100% 时得分归零。这样做的好处是，雷达图上的区域变化在平时不会太敏感，但接近危险值时视觉上的收缩会非常明显，符合"雷达发现异常"的第一直觉。

前端的数据刷新频率我设的是 15 秒，和采集周期保持一致。每次刷新时取最新快照重绘雷达图，不抖动、不闪烁。用 ECharts 的 setOption 做增量更新时需要注意一个细节：必须传入 notMerge 参数为 true，否则旧的 series 数据可能残留，导致图形重叠。

4.2 趋势图的查询优化

趋势图是雷达图的重要补充。雷达图看当下，趋势图看过去，两者结合起来才能判断一个异常到底是突发还是持续演进。PLFM_RADAR 的趋势图展示用的是 ECharts 折线图，但实现过程中我踩过查询优化的坑。

最开始的实现方式很直接：用户选择时间范围后，前端直接把所有原始明细数据拉到浏览器里绘制。结果在 24 小时范围下，CPU 指标就有 24 × 60 × 4 = 5760 个数据点（15 秒一个点），如果有 6 个指标，那就是 3 万多条数据，加载速度尚可；但如果时间粒度再密、范围扩展到 7 天，数据点数量会膨胀到几十万条，浏览器渲染直接卡死。

后来我改成了后端聚合查询的方案。前端请求趋势数据时，会根据时间范围自动计算合适的聚合窗口：比如看 1 小时内的数据，直接用原始粒度；看 24 小时内的数据，用 1 分钟均值；看 7 天内的数据，用 5 分钟均值。聚合窗口和查询范围的映射关系如下：

聚合窗口的调整大大降低了数据量，也让浏览器的渲染压力变得可控。实际使用中，24 小时范围的趋势图在浏览器里渲染约 1440 个点，完全流畅。这个分组聚合的实现方式很简单，用一个动态 SQL 根据参数拼出 GROUP BY 的窗口大小即可，但带来的体验提升非常明显。

4.3 监控大屏的实战配置

PLFM_RADAR 还带有一个监控大屏模式，适合挂在办公室的电视或副屏上。大屏布局分成三个区域：中间是雷达图，展示当前所有主机的整体健康状态；左侧是最近 24 小时的 TOP 10 异常指标列表；底部是一行滚动的实时事件流，展示新触发的告警和恢复信息。

大屏模式有一个专门的数据通道，每 10 秒请求一次全量快照接口，而不是像普通页面那样需要登录才能查看。因为挂在公共区域的大屏需要自动播放，会话过期也不能弹登录框。为了保障安全，大屏接口不暴露任何配置修改能力，只提供只读快照，并且绑定了独立的访问 token，仅当大屏需要时才在配置中开启。

如果用 Grafana 做监控大屏，也能实现类似的效果，但你需要自己装配很多插件和依赖。PLFM_RADAR 的大屏功能全部在项目代码里实现，没有引入额外依赖，部署一套就能直接用。如果你有自定义大屏布局的需求，Vue 的组件化结构改起来也比较灵活，我后来就把雷达图从圆形改成了半圆形布局，适配了壁挂屏的尺寸比例。

以下是大屏快照接口的简化返回结构，方便理解这个接口的用途：

{ "timestamp": 1710000120, "hosts": [ {"name": "web-server-01", "health_score": 78.5, "alerts_count": 1, "top_issue": "disk_used_percent=82%"}, {"name": "db-server-01", "health_score": 95.2, "alerts_count": 0, "top_issue": ""} ], "recent_alerts": [ {"rule_name": "磁盘使用率超过 80%", "host": "web-server-01", "value": 82.1, "created_at": 1710000090} ] }

大屏接口的数据量很小，每台主机只汇总几条关键信息，所以 10 秒刷新一次对服务端来说几乎没有任何压力。你可以在接口端看到每台主机的 health_score，这个分数是前面各个维度健康分的加权平均，权重可以调整——我默认把磁盘使用率的权重调高了，因为磁盘满导致的故障往往最严重且恢复最慢。

5. 部署实操与踩坑记录

5.1 完整部署流程（30 分钟上线）

下面是我的实际部署步骤，照着操作基本能在半小时内把整套系统跑起来。部署环境假设是一台 Ubuntu 22.04 的服务器，2 核 4G 内存，已经安装了 Docker 和 Docker Compose。如果你不想用 Docker，也可以直接编译二进制后 systemd 托管，原理一样。

第一步，克隆代码仓库并进入项目目录。项目根目录下提供了 docker-compose.yml，里面定义了四个服务：radar-server（服务端）、radar-web（前端静态页面）、radar-agent（采集器，默认作为容器运行）、radar-scheduler（调度任务容器，负责聚合和告警扫描）。

git clone https://github.com/yourname/plfm-radar.git cd plfm-radar docker-compose up -d

执行完 docker-compose 后，可以用 docker ps 检查一下四个容器是否都健康运行。如果 radar-server 容器反复重启，大概率是配置文件里的数据库路径权限不对，给数据目录加上写权限即可：

chmod 755 ./data

第二步，修改 agent 配置。agent 的配置文件位于 conf/agent.yaml，需要修改 server_addr 指向服务端的 IP 或域名，然后启动 agent。如果是第一次部署，先用一条命令手动启动 agent 看日志输出是否正常：

./radar-agent -config conf/agent.yaml

看到日志中出现 "connection established" 之后，按 Ctrl+C 停掉，然后注册为 systemd 服务，用 systemctl enable 设置开机自启。agent 的 systemd 配置我放在项目里了，直接复制到 /etc/systemd/system/ 目录就能用。

第三步，登录前端页面。浏览器访问 http://服务器IP:8080，默认账号 admin / admin123，首次登录会强制要求修改密码。登录后进入"主机管理"页面，如果能看到 agent 上报上来的主机列表和实时的指标曲线，那说明链路已经通了。

第四步，配置告警规则。进入"告警规则"页面，按照前面给出的 JSON 规则格式，把至少三条核心规则配置进去：CPU 使用率过高、内存使用率过高、磁盘余量不足。我这里建议第一次先配这三条，跑通告警链路再逐步增加更精细的规则，因为一开始就配几十条规则，出问题时反而是规则本身在干扰判断。

部署完毕之后，用下面几个接口做一次"体检"来判断系统健康度：

5.2 高频问题实录与排查思路

我把部署和使用过程中遇到频率最高的问题整理成了速查表，下面这些问题每一行都是我在真实环境中踩过的。

问题一：agent 上报数据正常，但前端页面没有数据

这个问题的典型特征是 agent 日志显示 200 响应，但前端图表全部空白。我的排查思路是逐步缩小范围——先用 curl 直接调服务端查询接口，看有没有数据返回；如果有，问题一定出在前端；如果没有，说明是存储层写入失败。最终我定位到一次场景，是 SQLite 的数据目录权限发生了变化，导致服务端写不进去，但 HTTP 接口仍然返回 200，因为错误被吞掉了。修复方式是给数据目录配置定时 chmod 和日志告警，保证任何写入异常都能在日志中暴露。

问题二：告警延迟超过 10 分钟

告警延迟的排除思路优先怀疑告警扫描周期和规则持续时间。我遇到过一种特殊情况是规则里持续时间设置的是 900 秒，也就是 15 分钟，但自己忘了，导致告警总是"迟到"。另一个常见原因是监控大屏的 10 秒刷新循环占用了服务端的事件循环，导致扫描任务被阻塞。解决办法是把扫描任务放到独立的 goroutine 中执行，和 HTTP 请求处理分开。升级之后，扫描延迟从分钟级降低到了秒级。

问题三：SQLite 数据库体积持续膨胀

SQLite 文件一直变大的根本原因是写入了大量原始明细数据，而清理任务没跑起来。我在部署文档里也强调过，清理任务依赖调度容器正常执行，如果调度容器因为时区问题没有按预期时间触发，数据就一直积压着。后来我明确设置了容器的 TZ 环境变量为 Asia/Shanghai，并且把清理 SQL 放到聚合任务后面统一执行，确保每次聚合完成后立刻清理过期明细。现在数据库体积稳定在 500MB 以下，完全可控。

问题四：前端雷达图在某些机器上不显示

这通常是 ECharts 版本兼容性问题。项目里用的 ECharts 5.4 版本，如果你用的是 vue-echarts 插件且版本过低，可能会出现 canvas 初始化失败。我最后直接改用 echarts 的原生实例 API，放弃了 vue-echarts 的封装，反而更稳定，也减少了依赖层级。

5.3 性能调优与容量规划经验

PLFM_RADAR 的性能瓶颈最开始出现在 SQLite 写入，后来经过批量写入优化，瓶颈转移到了查询聚合上。我压测过三台 agent、每台每秒上报约 100 条指标的负载，服务端 CPU 稳定在 30% 以下，内存占用约 200MB。这个负载对于一台 2 核 4G 机器足够日常使用。

容量规划方面，我提供一个估算思路：假设 1 台主机 50 个指标，15 秒采集一次，一天的明细数据量是 50 × 4 × 60 × 24 = 28.8 万条，每条按 100 字节计算约 30MB，保留 24 小时明细加 30 天聚合数据，总存储量不超过 1GB。按这个比例，单台服务器管理 10 台主机、保留 30 天数据，SQLite 完全可以承受。如果扩展到 20 台以上主机，建议快速迁移到时序数据库，同时把 agent 的上报频率从 15 秒放宽到 30 秒，写入压力会直接减半。

在这个性能调优的过程中，我意识到一个容易被忽略的点：指标采集本身也是有代价的。agent 频繁调用系统接口、解析 /proc 文件，在高密度指标的机器上会消耗少量 CPU。部署之前最好在目标机器上用 top 实测一下 agent 进程的 CPU 占用，如果超过 5%，可以考虑降低采集频率。我自己在低配云服务器上测过，PLFM_RADAR 的 agent 全部指标采集一轮的 CPU 占用约在 0.3% 到 0.8% 之间，算得上轻量。

6. 项目扩展思路与其他应用场景

PLFM_RADAR 虽然最初的定位是平台监控，但我在实际使用中发现这套架构可以非常自然地延伸到其他场景，稍微改动一下接入层就又能派上新用场。

第一种扩展是把它变成端口探测与公网可用性监测工具。agent 每隔 15 秒采集系统指标的同时，也可以对指定域名或 IP 的端口发起 TCP 连接探测，比如检测网站 443 端口是否开放、数据库端口是否可达、第三方 API 的连通性是否正常。探测结果会作为独立指标上报，规则引擎可以直接对端口探测的失败次数设定告警阈值。我这样改造之后，PLFM_RADAR 就同时承担了"内网监控"和"外网探测"两个职责，不用再单独部署 UptimeRobot 或者 Cronitor 之类的服务。

第二种扩展是自定义业务指标的接入。项目提供了 HTTP JSON 上报接口，任何语言都可以通过简单的 POST 请求上报业务指标，然后在平台上设置告警规则。比如在订单创建、支付成功、用户注册等关键业务节点埋点上报离散计数，让平台监控"订单量在 5 分钟内下降超过 30%"这种业务级别的异常。这种扩展对研发团队很有价值，因为它让监控不再停留在基础设施层面，而是直接关联到业务核心流程。

第三种扩展是搭配自动化的自愈操作。告警触发的 Webhook 不仅能够推送到 IM 工具，还可以把消息转发到自动化脚本服务，触发一些预定义的操作，比如重启异常服务、清理磁盘垃圾文件、扩容容器实例。我在部署文档里给出了一个简单的 Go 脚本示例，它监听某个接口的告警回调，执行 shell 命令来处理常见故障。这种联动还需要考虑安全性和权限管控，我建议在生产环境先只允许执行幂等性高的操作，比如清理临时文件、重启自研服务，不要一开始就开放任意 shell 的权限。

最后再说一个我在实际运维中喜欢用的小技巧：把 PLFM_RADAR 的雷达图快照自动截取下来，在每天早上的晨会里花三十秒分享给团队。不需要准备 PPT，也不需要打开监控系统操作，页面右上角一个"截图当前状态"按钮就能一键把当前雷达图导出为图片。大家可以直观地看到整个平台在 24 小时内的状态变化，哪个服务的健康分在下降、哪个集群的资源消耗增长过快，一眼就清楚了。这个习惯坚持了一个月之后，团队对监控数据的敏感度有了很大的提升，很多问题在告警触发之前就已经被主动处理掉了。

PLFM_RADAR 这个项目教会我最重要的一件事是：监控系统的价值不在于你收集了多少数据、画了多少漂亮的图表，而在于它能不能在关键的时候把最有效的信号以最直接的方式传递到对的人手里。雷达图、告警消息、趋势曲线，这些都只是手段，最终的目的是让你在面对一个快速变化、信息嘈杂的分布式环境时，依然能保有清晰的判断力。如果你也在搭建自己的监控体系，我建议先从小而完整的闭环开始——一个 agent、一台服务器、一条告警规则，等这个闭环运转顺畅了，再慢慢向外扩展，比一开始就追求大而全要实用得多。