监控大屏在凌晨三点弹出一条告警东方仙盟的登录网关连续三次探活失败可登上去一看进程活着、端口也通着。这种“看着没死实际进不去”的故障相信不少运维都遇到过。我给的解决办法不是什么高深框架而是用 Node 写一个极简单的伪请求pseudo http探针代替 ping 和端口检测直接假装成玩家在应用层发起真实访问把链路、超时、返回码全部量出来。这篇文章就完整拆解这套思路从原理到可上线的代码都放出来适合正被误报折腾、又想少引依赖的运维朋友。1. 伪请求到底在“伪”什么从一次凌晨误报警说起先说清楚我这里的“伪请求”不是安全领域常说的 CSRF、抓包伪造而是运维探活里的一种 L7 探测手段程序不经过浏览器、不经过 curl自己按 HTTP 协议组装一个请求发出去然后检查服务器返回的结果。它“伪”在一个地方——它表现的像是真实用户流量实际上是一段很轻的监控脚本。东方仙盟这套服务外部入口是 Nginx 网关后端是 Node 业务集群再往下是 MySQL 和 Redis。之前凌晨那次误报警就是典型的“下层活着、上层死了”登录进程还在端口也能连上但后端的连接池已经占满真正发起登录请求时直接 504。传统的 ping 只能测网络通不通nc -vz只能测端口开不开它们完全看不到应用层发生了什么。当时我做了个对照测试结果非常直观检测方式检测层次能发现连接池打满吗能发现 504 吗能否判断业务返回码pingICMP 网络层不能不能不能nc -vzTCP 传输层不能不能不能curlHTTP 应用层部分可以可以可以Node 伪请求HTTP 应用层可编程可以可以可以curl 其实也能完成这一步但它停留在“手动敲命令”的阶段没法一转常驻也没法把每次探测的耗时、返回码、响应体落库。伪请求的价值在于它是用代码写的“探针”可以定时执行、失败重试、自动告警还能按业务要求做断言。此后东方仙盟的告警策略全部换成这套伪请求探针误报率直接降了一截。不过把探针做出来只是第一步更麻烦的是让它稳定跑在线上不误报、不漏报、不把自己变成事故源头。后面几个章节我会按这个顺序展开。2. 为什么探针要选 Node 而不是 curl三个让人服气的理由很多人第一反应是“用 curl crontab 不就行了吗”确实能跑但我实际用过之后发现它有三个解决不了的问题这也是我最终用 Node 重写探针的直接原因。第一个理由curl 单发容易做序列化探测和退避重试很别扭。假设计划失败后再等 2 秒、4 秒、8 秒重试用 shell 写要叠一堆变量加上要记录每次请求的 TTFB、状态码、返回体脚本会越写越脏。Node 里一个for循环加sleep就解决了代码可读性和可维护性好得多。第二个理由Node 原生http模块几乎零依赖非常符合生产环境的安全要求。线上服务器经常不建议随便npm install一旦引入第三方包就多了供应链风险。而探针本体用到的http、net、dns全是 Node 内置模块单文件放到机器上就能跑不涉及任何外部依赖。第三个理由伪请求不能只是“通就行”还得贴近真实业务。东方仙盟登录后要带 Session Cookie部分管理接口要带签名 Header还有一些接口要 POST JSON。Node 脚本可以做到“先请求一次登录接口拿 token再用 token 请求下一个业务接口”这是 curl 单命令很难优雅表达的多阶段探测。这里也顺带说一句环境问题探针对 Node 版本不挑剔但我建议用 LTS也就是 18 以上。有些老机器装的是 Node 12、14跑fetch可能报未定义代码里我只能用https.request封装。如果你手头服务器多推荐用 nvm 管理版本安装和切换都干净别为探针单独折腾源码编译。综合看下来Node 的定位非常适合这种低频、长驻、偏协议层的探针任务。要说缺点也就是脚本本身需要一点点编码能力但下面给出的代码可以直接照搬。3. 手写第一个伪请求从原生 http 到裸 TCP 报文这一章我给出两个版本的实现第一个用http.request够用也安全第二个用net模块手工组报文适合想真正理解 HTTP 协议、或者要在极老环境里绕开 http 客户端限制的场景。3.1 基于 http.request 的最简探针http.request是 Node 内置模块不需要任何安装。核心逻辑是创建一个请求对象监听响应事件把状态码和响应体收回来同时记录耗时。const http require(http); const options { hostname: game.dongfangxianmeng.local, port: 8080, path: /healthz, method: GET, headers: { User-Agent: pseudo-http-probe/1.0, Host: game.dongfangxianmeng.local }, timeout: 3000 }; const start Date.now(); const req http.request(options, (res) { let chunks []; res.on(data, (chunk) chunks.push(chunk)); res.on(end, () { const body Buffer.concat(chunks).toString(); console.log(JSON.stringify({ status: res.statusCode, ttfb: res.ttfb || -1, total: Date.now() - start, body: body.slice(0, 200) })); }); }); req.on(timeout, () { req.destroy(new Error(request timeout)); }); req.on(error, (err) { console.error(probe error:, err.message); }); req.end();这段代码有两点要注意第一timeout选项设置的是 socket 空闲超时不是说 3 秒后请求一定会被杀死所以要在timeout事件里主动req.destroy()第二ttfb首字节时间默认不会自动给你算要自己在响应流的data事件第一次触发时记录时间戳。3.2 用 net 模块组装 Raw TCP 报文如果哪天你手头只有一台老机器Node 版本低到http模块行为都有偏差或者你想彻底搞明白“HTTPS 之前的 HTTP 到底长什么样”可以退一步直接用net模块往服务器写一段原始报文。const net require(net); const socket net.createConnection({ host: game.dongfangxianmeng.local, port: 80, family: 4 }, () { const rawRequest [ GET /healthz HTTP/1.1, Host: game.dongfangxianmeng.local, User-Agent: pseudo-http-probe/raw-tcp, Connection: close, , ].join(\r\n); socket.write(rawRequest); }); let responseData ; const ttfbStart Date.now(); let ttfb -1; socket.on(data, (chunk) { if (ttfb -1) { ttfb Date.now() - ttfbStart; } responseData chunk.toString(); }); socket.on(end, () { const [headerBlock, body] responseData.split(\r\n\r\n); const statusLine headerBlock.split(\r\n)[0]; console.log({ statusLine, ttfb, bodySize: body ? body.length : 0 }); socket.end(); }); socket.on(error, (err) { console.error(tcp probe error:, err.message); });原始报文的关键在于结尾的\r\n\r\n。HTTP 协议规定每一行以回车换行结束头部和正文之间要有空行所以数组里[, ]拼出来就是两个连续换行相当于空行。如果这里漏掉一个\n服务器会一直等你的请求头最终超时。另外Connection: close一定要加否则 HTTP/1.1 默认是 keep-alive服务器发完响应后不会主动关闭连接你的end事件可能永远不触发。3.3 响应解析和超时控制无论是http.request还是裸 TCP响应解析都遵循同一个套路先取状态行再取响应头最后取响应体。有现成模块时当然不用手写但探针场景最大的坑不在解析而在超时。我给探针加了三层超时保护第一层是 socket idle timeout超过阈值没有任何收包就销毁连接第二层是整体耗时上限启动一个定时器超过总预算强制失败第三层是 DNS 解析超时这一步最容易被忽略内网域名偶尔出现解析卡顿会直接把探针拖死。这三层都加到代码里之后探针才算有基本的生产可用性。4. 上线版本常驻探针、失败退避与值班机器人告警单次探针写好后要让它真正替你看门还需要三样东西定时循环、失败重试、告警上报。下面是我在东方仙盟环境里实际跑的完整结构。4.1 完整探针主流程我把探针逻辑封装成probeOnce()外层是一个setInterval定时器。每次探测失败后按 1 秒、2 秒、4 秒做指数退避三次都失败才触发告警。这里的“失败”不只是网络连不上还包括 HTTP 状态码不是 200 或返回体不符合预期。const http require(http); const https require(https); const PROBE_INTERVAL 30 * 1000; const MAX_RETRY 3; function probeOnce() { return new Promise((resolve, reject) { const start Date.now(); let ttfb -1; const req http.request({ hostname: game.dongfangxianmeng.local, port: 8080, path: /healthz, method: GET, headers: { User-Agent: pseudo-http-probe/1.0 }, timeout: 5000 }, (res) { let chunks []; res.on(data, (chunk) { if (ttfb -1) ttfb Date.now() - start; chunks.push(chunk); }); res.on(end, () { const body Buffer.concat(chunks).toString(); const ok res.statusCode 200 body.includes(code:0); resolve({ ok, status: res.statusCode, ttfb, total: Date.now() - start, body: body.slice(0, 300) }); }); }); req.on(timeout, () req.destroy(new Error(socket timeout))); req.on(error, reject); req.end(); }); } function sleep(ms) { return new Promise(resolve setTimeout(resolve, ms)); } async function probeWithRetry() { let lastErr null; for (let i 0; i MAX_RETRY; i) { try { const result await probeOnce(); console.log(${new Date().toISOString()} status${result.status} ttfb${result.ttfb}ms total${result.total}ms); if (result.ok) return; lastErr new Error(bad status or body: ${result.status}); } catch (err) { lastErr err; console.error(${new Date().toISOString()} probe failed: ${err.message}); } await sleep(1000 * Math.pow(2, i)); } await notifyAlert(东方仙盟 healthz 探测失败${lastErr.message}); } setInterval(() { probeWithRetry(); }, PROBE_INTERVAL); probeWithRetry();4.2 用 PM2 常驻和切分日志探针脚本不能裸跑在前台我习惯用 PM2 守护。PM2 的配置写在ecosystem.config.js里这样重装机器后一条命令就能恢复。module.exports { apps: [ { name: dfxm-http-probe, script: ./probe.js, instances: 1, autorestart: true, max_memory_restart: 200M, env: { NODE_ENV: production, PROBE_INTERVAL: 30000 } } ] };日志方面PM2 默认把console.log写到~/.pm2/logs不管的话文件会越滚越大。建议执行pm2 install pm2-logrotate然后把max_size设为20Mretain设为7保留一周足够排查问题。这个插件装一次后对所有应用生效算是投入产出比很高的小配置。4.3 把异常推到值班机器人告警推送我用的是通用的 webhook JSON 格式无论你的值班机器人是自建还是商业产品基本都兼容。Node 18 以上可以直接用全局fetch老旧版本需要https.request封装我这儿写的是兼容写法。function notifyAlert(message) { const data JSON.stringify({ msgtype: text, text: { content: [pseudo-http探针] message } }); const url new URL(https://your-webhook.example.com/hooks/receive); const request https.request({ hostname: url.hostname, port: 443, path: url.pathname, method: POST, headers: { Content-Type: application/json, Content-Length: Buffer.byteLength(data) } }, (res) { res.on(data, () {}); }); request.on(error, (err) console.error(notify failed:, err.message)); request.write(data); request.end(); }整套上线后观察了一周效果很稳。真正的故障五秒内就收到通知平时没有误报日志大小也控制得住。5. 被伪请求坑过的五个细节上线前先对照自查探针看着简单真放到生产环境会遇到不少奇怪问题。我把踩过的坑整理成五个自查项每条都是真实教训。5.1 timeout 不是万能的之前我以为设置了timeout: 3000就能保证三秒内结束后来发现根本不是。Node 文档里的 timeout 是“socket 空闲超时”意思是连接在指定时间内没有任何数据交互才触发。如果服务器一个字节都不回那确实能触发但更常见的场景是服务器不断发一小段数据、然后卡住空闲超时永远不触发。所以最稳妥的做法是在外层再加一个整体耗时上限比如启动一个setTimeout5 秒到了直接销毁请求并记录失败。5.2 Connection: close 和 keep-alive 的取舍用裸 TCP 写探针时Connection: close必须显式加上。HTTP/1.1 默认 keep-alive不加的话服务器发完响应后连接保持打开客户端要一直等 EOF 才能确认“这次请求结束了”这会让探针误以为是超时。用http.request时底层会处理但如果想测“多路复用”“连接复用”这类指标又要专门开 keep-alive两种策略适用于不同目的别混着用。5.3 内网域名的 IPv6/IPv4 解析坑东方仙盟的网关在系统里有个内网域名某天探针突然频繁超时排查发现本机 DNS 解析把域名解析成了::1而 Nginx 只监听了 IPv4。Node 的http.request和net都支持family选项直接指定family: 4可以绕过这个坑。如果你不想在代码里写死可以在/etc/gai.conf里调整地址解析顺序但那样影响机器上所有进程我是更倾向于探针代码里显式声明。5.4 别把探针当压测工具上线初期我把探测间隔调成了 5 秒一次想着“多探几次更保险”结果某天下午仙盟有个接口刚好在做缓存重建探针每次发起请求都会触发一次耗时的冷启动直接放大了业务延迟。这不是探针本身的错是我把它用成了并发压力源。伪请求的核心是“验证可用性”不是“压测性能”建议普通接口间隔 30 秒以上并发永远保持 1。真要做压测请用专业的压测工具而不是探针。5.5 状态码 200 不等于业务正常只看返回码是最容易漏报的。东方仙盟的healthz接口曾经在数据库连接池耗尽时依然返回 200因为接口外层用try/catch包住了异常时返回一个空 JSON。后来我在探针里加了业务断言必须body里包含约定的code:0才算健康。建议每个核心接口都要定义自己的“健康口径”探针按口径断言而不是只判断 HTTP 状态码。6. 从探针到流量模拟东方仙盟的下一步玩法探针稳定运行之后我开始把它往“伪流量模拟”方向扩展思路其实是一致的既然可以伪一次请求就可以伪一套完整业务流程。最实用的是多阶段探测。比如先请求登录接口拿到 token再用 token 去请求玩家信息接口和充值回调接口所有阶段串在同一个探针里。这样一旦登录服务出问题探针能立刻定位到具体是哪一环失败告警信息里直接带上阶段名值班同事不用再登服务器翻日志。我还给探针加过随机抖动每次执行间隔在 25 到 35 秒之间波动避免所有探针在同一秒发请求形成人为的流量毛刺。这点在做多实例部署时特别重要三台探针机器如果都是固定 30 秒整点请求恰好赶上同一时刻网关会收到三倍瞬时请求虽然量不大但没必要。如果你们有 CI/CD 平台还可以在发布后自动跑一次伪请求断言。比如 Jenkins 或 GitLab CI 里执行node probe.js --assert探针返回失败就中断上线流程。这基本上等于给业务接口加了一层自动化冒烟测试。pseudo http这东西听起来有点抽象但落到运维上本质就是“用最小代价模拟真实用户访问验证整条链路是否健康”。探针的代码量不大但它替代的是过去靠人肉登服务器、敲 curl、看日志的繁琐流程。现在东方仙盟的告警群安静了很多值班同事也终于不用在半夜被误报叫醒。你若也想在监控体系里加入这一层建议直接拿第二章的代码先跑通再按第五章的五个坑逐个自查准能少走一段弯路。