ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

执行机监控,就该这么轻:5MB 探针 + 零依赖 Server 的 Pulse 方案

2026/9/29 9:42:54 拓冰建站 浏览量
执行机监控,就该这么轻:5MB 探针 + 零依赖 Server 的 Pulse 方案 给执行机集群把脉Pulse 如何用两个 Go 单文件替代重型监控栈摘要执行机集群裸跑出了事只能等投诉。Pulse 用 Agent Server 两个 Go 单文件撑起集群监控全指标采集、10 秒上报、离线与阈值告警、可视化面板零外部依赖5 分钟接入。一、问题执行机集群的可观测真空CI/CD 构建机、自动化测试机、批处理执行机——这类集群有个共同特征机器多、生命周期短、资源波动大。它们和线上服务集群不一样。服务集群有 APM、有链路追踪、有 P99 告警而执行机往往只有一句话的交代“跑不动了就重启一下。”于是所有的排查都靠人肉任务挂了 →ssh上去 →top/free/df -h/iostat挨个看 → 猜。问题在于滞后等你登上去现场可能已经消失了浪费几十台机器逐个登纯体力活无感机器假死进程在、上报断根本发现不了兜底方案通常是上 Prometheus Grafana。但这套栈本身有成本exporter 要装、配置要写、面板要调、内存要吃。对于内网、无外网、机器量大的执行机场景投入产出比常常不划算。Pulse 的思路是用尽可能小的东西解决看得见这一个核心问题。二、设计Agent 上报 Server 接收 面板展示Pulse 由两个独立二进制构成数据流是单向的执行机 → ServerServer 不主动采集、不反向控制机器。Agent执行机侧Go 交叉编译的单文件二进制几 MB无任何运行时依赖每10 秒采集一次指标HTTP POST 上报通过PULSE_SERVER环境变量指定上报地址以 systemd 托管开机自启、崩溃自动重启Server中心侧纯 Go 标准库零外部依赖内存态维护hostname:ip→ 最近一次指标对外提供四个接口接口方法用途/GETWeb 监控面板go:embed内嵌无需单独部署前端/reportPOSTAgent 上报入口/statusGET全量状态 JSON面板轮询用/healthGET健康检查关键设计Dashboard 用go:embed直接编进 Server 二进制。不需要 Nginx、不需要前端构建产物、不需要单独的静态目录——一个二进制跑起来页面就能访问。这是单文件交付理念的延伸。三、采集的指标覆盖执行机日常巡检全维度类别指标看点CPU使用率任务是否把机器跑满内存总量 / 已用 / 使用率是否接近 OOMSwap总量 / 已用 / 使用率持续偏高 物理内存不足磁盘根分区总量 / 已用 / 使用率构建产物是否把盘撑满负载1 / 5 / 15 分钟 Load看趋势不看瞬时运行时长Uptime骤降 机器刚重启过网络累计流量 实时速率是否在疯狂拉包磁盘 I/O累计量 实时速率瓶颈是不是在磁盘在途 IO未完成的 I/O 请求数磁盘堵不堵的直接指标进程数进程总数异常突增可能是 fork 炸弹几个指标的选择是刻意为之Swap 而非只看内存内存 90% 在跑任务的机器上很常见但 Swap 长期被频繁读写说明物理内存真的不够了——这是更硬的信号。Uptime结合最后上报时间一眼判断机器是重启了还是网络断了。在途 IO 进程数这两个指标平时不动异动往往就是故障前兆I/O 积压、fork 炸弹。采集的健壮性任何单个指标采集失败只记日志、保留零值其余指标照常上报。某台机器缺/proc/loadavg不会导致整台机器失联。部分可见永远优于完全不可见。速率的正确算法网络/磁盘 I/O 底层是单调递增的累计计数器。Agent 保存上一轮采样值与时间戳求差除以间隔得到 bytes/s。首轮采样、或机器重启导致计数器归零回绕时本轮速率记 0只重建基线绝不出现负值或天文数字。四、告警只在该响的时候响告警机制的设计目标很明确信息量最大化噪音最小化。离线判定超过 30 秒未上报 → 标记offline。阈值告警全部可用环境变量覆盖无需改代码类型默认阈值含义CPU90%持续跑满内存90%物理内存吃紧磁盘85%根分区接近打满Swap50%频繁换页物理内存不足进程数2000异常突增疑似 fork 炸弹告警去重——这是体验上差异最大的一点。常规做法是每轮检查超阈值就打日志结果是一台机器超阈值 10 分钟日志被刷几百行真正的异常反而被淹没。Pulse 的做法是维护一个告警状态机按「主机 告警类型」记录当前状态只在两个状态跳变的时刻输出⚠️ ALERT [worker-01]: CPU CPU过高: 92.3% ⚠️ ALERT [worker-02]: OFFLINE (last seen 45s ago) ✅ RECOVER [worker-01]: CPU 已恢复正常一台机器长期超阈值 → 只在你需要知道的时候告诉你一次恢复了 → 明确通知。静默本身就是一种信息日志里没有新 ALERT就说明一切照旧。五、几个工程细节1. 上报 IP 以 TCP 来源为准Agent 自报的 IP 不采信Server 从r.RemoteAddr解析真实来源地址。多网卡、NAT、容器网络下都更准确安全上也更稳——Agent 被篡改也伪造不了来源。2. 上报失败指数退避重试网络抖动、Server 重启Agent 按 1s → 2s → 4s 退避重试最多 3 次。避免一次网络瞬断丢掉一批数据。3. 阈值判定的单一实现/status查询和告警协程共用同一个阈值判定函数。这看着不起眼但踩过坑的人都懂判定逻辑写两遍改阈值时漏改一处就会出现面板显示正常、告警在疯狂刷的诡异现象。4. 单请求 panic 隔离Server 的 handler 统一包了一层 recover单个请求 panic 不会带崩整个服务。六、怎么用起来Server1 台# 交叉编译 AgentCGO_ENABLED0GOOSlinuxGOARCHamd64 go build-ldflags-s -w-opulse-agent ./agent# 编译并启动 Servergo build-ldflags-s -w-opulse-server ./serverexportCPU_THRESHOLD90DISK_THRESHOLD85# 按需覆盖阈值./pulse-serverAgent每台执行机一行命令curl-fsSLhttp://server-ip:8123/resources/install-pulse.sh|bash-s--\http://server-ip:8123/report脚本自动完成下载二进制 → 写 systemd 服务 → 启动 → 验证is-active。失败会提示去看journalctl -u pulse-agent。装完之后开机自启、崩溃 5 秒自愈、上报每 10 秒一次。然后就可以忘掉它了。看板浏览器打开http://server-ip:8080/首页是集群总览在线/离线/告警数 列表支持按主机名/IP 实时搜索、表头排序、分页点任意一行详情展开该机器的全部指标卡片。七、适用边界什么时候该用它Pulse 适合执行机 / 构建机 / 测试机集群的日常健康巡检内网、无外网、无法引入重型监控栈的环境只想解决机器状态可见性、不想背监控运维负担的团队Pulse 不适合需要长期指标存储和复杂查询Pulse 是内存态重启即清空需要多租户 / RBAC / 权限体系需要业务指标QPS、延迟分布、错误率——Pulse 只管机器不管业务如果你的需求落在下面这栏Prometheus Grafana 依然是更正确的选择。Pulse 的定位是**够用就好的轻量可观测**而不是大而全的监控平台。八、小结两个 Go 单文件 10 秒上报 智能告警去重 内嵌可视化面板 执行机集群的脉搏。它不试图解决所有监控问题只把执行机现在怎么样这一件事做扎实部署轻、开销小、告警不吵、状态一眼可见。对一片正在裸奔的执行机集群来说这已经是从 0 到 1 的一步。#监控 #执行机 #Golang #轻量可观测 #健康巡检 #CICD