痛点：等用户投诉，你才知道服务挂了

上周有个接口半夜挂了，运维群里一片安静，直到第二天早上业务同事在群里甩了一张「502 Bad Gateway」的截图，我们才知道——线上已经裸奔了 6 个小时。

这不是个例。大多数中小团队的接口监控还停留在「人工巡检」：要么靠人肉打开网页看一眼，要么压根没监控，全靠用户当「免费测试员」。等发现的时候，故障已经变成事故，复盘会上所有人都在问同一个问题：「为什么没人早点说？」

：要搭 Prometheus、要配 Grafana、要写 exporter……一整套下来，一周就搭进去了。可我们只是想在某个接口挂掉时，第一时间收到一条消息而已。

其实这件事用 WorkBuddy 半小时就能落地，而且不需要任何重型组件。

方案架构：一个脚本 + 一个调度

WorkBuddy 在这个架构里扮演「调度大脑」的角色：它不用 7×24 一直挂着，而是用定时任务每 5 分钟跑一次探活脚本，正常时静默，异常时才「出声」。这就把「重型监控平台」压缩成了「一个 shell 脚本 + 一个定时任务」。

┌─────────────┐   curl 探活   ┌──────────────┐
│ WorkBuddy   │ ───────────▶ │  目标 API     │
│ 定时任务     │ ◀─────────── │ 状态码/延迟   │
│ (每5分钟)    │   判定+推送   └──────────────┘
└──────┬──────┘
       │ 异常才通知
       ▼
   企业微信/邮件


复制即用的核心脚本：health_check.sh

下面这个脚本可以直接拿走用。它接收一个 URL，先打一次，失败就隔 10 秒再打一次，只有

才判定为故障并退出码 1（成功退出码 0）。

#!/usr/bin/env bash
# health_check.sh <url> [timeout_seconds] [max_latency_ms]
URL="${1:?用法: health_check.sh <url>}"
TIMEOUT="${2:-5}"
MAX_LATENCY="${3:-3000}"   # 超过 3 秒也算异常

check_once() {
  local start end cost code
  start=$(date +%s%3N)
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time "$TIMEOUT" "$URL" 2>/dev/null)
  end=$(date +%s%3N)
  cost=$((end - start))

  if [ "$code" != "200" ]; then
    echo "FAIL http_code=$code"
    return 1
  fi
  if [ "$cost" -gt "$MAX_LATENCY" ]; then
    echo "FAIL latency=${cost}ms > ${MAX_LATENCY}ms"
    return 1
  fi
  echo "OK http_code=$code latency=${cost}ms"
  return 0
}

# 连续两次失败才告警，过滤抖动
if check_once; then
  exit 0
fi
sleep 10
if check_once; then
  echo "第一次失败但第二次恢复，视为抖动，忽略"
  exit 0
fi

echo "连续两次探活失败，确认故障: $URL"
exit 1


把告警动作接到脚本后面就行，比如推企业微信机器人：

bash health_check.sh "https://api.yoursite.com/health" || \
  curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的KEY" \
  -H "Content-Type: application/json" \
  -d '{"msgtype":"text","text":{"content":"⚠️ 接口探活连续失败，请立即排查！"}}'


WorkBuddy 调度：让它每 5 分钟替你跑

脚本写好了，剩下就是「谁去定时执行」。在 WorkBuddy 里我会建一个定时任务，把上面这段命令包进任务的 prompt 里，设定 

关键 Prompt 设计（复制可用）：

：99% 的正常心跳你根本不该看到，只有那 1% 的真故障才会打破安静。既不会被告警轰炸，又不会漏掉真问题。

踩坑：别被「假死」骗去半夜爬起来

第一个版本我没加「连续两次失败」这个缓冲，结果某天上午骨干网轻微抖动，单点 curl 超时，告警瞬间炸了，我冲到电脑前一看接口好好的——白慌一场。

效果实测：从「小时级」到「30 秒内」

把这个方案接上之后，我做了一次真实故障演练：手动把测试接口停掉。

而且因为静默设计，日常完全无感，不会像某些监控那样「绿灯也疯狂弹窗」。一个月下来，真告警 2 次全是真实故障，误报 0 次。

回头看，这件事最大的价值不是「省了一个 Prometheus」，而是把「等出事才知情」变成了「出事前 30 秒就提醒」。监控的意义从来不是好看的大屏，而是

在问题变成事故之前，给你那关键的半小时

 脚本加 WorkBuddy 定时调度，就能把接口故障的发现时间从「小时级」压到「30 秒」，而且正常时它比你还安静。

本文是「WorkBuddy 实战笔记」系列之一。

API 又挂了才知道？用 WorkBuddy 做健康监控：30 秒自动告警

痛点：等用户投诉，你才知道服务挂了 上周有个接口半夜挂了，运维群里一片安静，直到第二天早上业务同事在群里甩了一张「502

云计算

人工智能

前端

用WorkBuddy加一个shell脚本，5分钟探活一次接口，连续两次失败才推送企业微信告警，故障发现从小时级缩短到30秒内，误报率归零，无需部署重型监控平台。

WorkBuddy 

JSON

2026上云采购 | AI焕新·智启新局

tcmg

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

API 又挂了才知道？用 WorkBuddy 做健康监控：30 秒自动告警

API 又挂了才知道？用 WorkBuddy 做健康监控：30 秒自动告警

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐