Cloudflare Workers 免费额度监控：基于 Telegram 自动化日报与告警通知

Cloudflare 作为“互联网大善人”。除了基础的域名解析（DNS）和 CDN 加速，它为个人开发者和折腾爱好者提供了极高价值的免费工具链。

我个人除了 CDN 之外，还使用了 Cloudflare Tunnel (零信任内网穿透)以及 Cloudflare Workers 服务，我利用 Workers 搭建了一个 Cloudflare Workers 免费额度用量监控系统，并且本博客通过 Blogger 平台搭建，所以顺便添加了简单的浏览量统计，并通过 Telegram 发送通知功能。

内容可能并不适合所有人，但可作为分析和提供思路，比如使用 Cloudflare Workers 搭建免费节点统计免费额度用量等。
代码可以利用 AI 进行优化调整或者根据个人需求进行修改。

Cloudflare Workers 介绍

Cloudflare Workers 是 Cloudflare 提供的一种 Serverless（无服务器） 计算平台，它让开发者能够在全球超过 300 个数据中心的边缘节点上运行代码。

简单来说，它就像是在浏览器和原始服务器之间安插了一个“超级大脑”，可以实时拦截、修改并处理网络请求。

Cloudflare Workers 免费额度限制

Workers 采用的是无服务器（Serverless）架构。它的免费额度非常慷慨，但有三个核心维度的限制：

个人使用背景及需求

我使用了 Cloudflare Workers 搭建了两个 Worker，一个作为博客的图片反向代理，一个作为博客的一些特定静态资源代理。但因为 Cloudflare Workers 有免费使用额度限制，所以我部署了这个 Cloudflare Workers 额度预警 免费额度监控通知系统。

主要包括：Cloudflare Workers 用量统计、关键 Worker 健康评估、Telegram 日报与告警推送、Telegram 按钮刷新、Blogger 浏览量统计、自检接口与状态接口。

报表样式示例

下面是日报大致样式示例，实际内容会根据你的真实数据渲染。

每日运营报告示例：

☁️ ZOIO.NET · 每日运营报告

报告生成： 2026-05-09 23:56 (北京时间)
CF 统计口： 2026-05-09 15:56 UTC
─────────────────

⚡️ WORKERS 用量总览

[🟢] 系统评分： 93/100  (运行正常)

全局请求 (免费上限 10万次/天)
[🟢] 今日已用： 1,249  (1.2%)
[🟢] 剩余额度： 98,751
[🟢] 预测全天： 5,551

核心性能 (单次上限 10ms)
[🟢] CPU P50： 0.74ms
[🟢] CPU P99： 3.78ms
[🟢] 全局错误率： 0.00%
[🟢] 全局延迟 P99： 0.20ms
[🟢] 总出站请求： 197 次

─────────────────

WORKER 详细数据

❶ 图片代理 🔸 · img-zoio-net
[🟢] 请求： 1,113 次  (账户占比 89.1%)
[🟢] CPU P50： 0.73ms
[🟢] CPU P99： 4.00ms
[🟢] CPU Max： 4.88ms
[🟢] 延迟 P50： 0.00ms
[🟢] 延迟 P99： 0.21ms
[🟢] 错误： 0 次  (0.00%)
[🟢] 外链： 192 次  (均 0.2/次)

❷ 静态资源 · cdn-zoio-net
[🟢] 请求： 135 次  (账户占比 10.8%)
[🟢] CPU P50： 0.76ms
[🟢] CPU P99： 2.87ms
[🟢] CPU Max： 3.04ms
[🟢] 延迟 P50： 0.00ms
[🟢] 延迟 P99： 0.12ms
[🟢] 错误： 0 次  (0.00%)
[🟢] 外链： 5 次  (均 0.0/次)

─────────────────

🖥️ ZOIO.NET 浏览量统计

今日浏览量： 1,245
过去 7 天： 8,920  (日均：1,274)
过去 30 天： 35,880  (日均：1,196)
历史总浏览： 385,201
流量趋势： +6.5%  [📈]

✅ 所有服务运行正常，无异常告警
⏰ 额度重置：8 小时 4 分后 (UTC 0:00 / 北京 08:00)
─────────────────

状态说明：
[🟢] 运行正常      [🟠] 性能退化
[🟡] 轻微波动      [🔴] 服务异常
─────────────────

告警报告示例:

🚨 ZOIO.NET · 紧急告警

2026-05-09 18:20 (北京时间)  |  10:20 UTC
系统评分：47/100 [🔴 服务异常]

当前问题
[🔴] 请求额度接近耗尽 
已用：92,800  剩余：7,200
预计 1.6 小时后触及上限

主网关 · api-gateway-prod
[🔴] CPU P99： 10.20ms 
[🔴] 错误率： 5.20% 
[🔴]延迟 P99： 2410.00ms 

额度重置：13 小时 40 分后 (UTC 0:00 / 北京 08:00)

部署自检报告示例

⚙ ZOIO.NET · 部署自检
2026-05-09 11:30 (北京时间)

检测结果
[🟢] CF GraphQL API：今日已采集 12,340 次请求
[🟢] Blogger API v3：历史总浏览 385,201 PV（OAuth 认证正常）
[🟢] KV 存储：读写正常（Blogger 今日浏览量 / 告警冷却 / 最新日报刷新依赖 KV）
[🟢] Telegram Webhook：已注册：https://worker.example.workers.dev/webhook
[🟢] Telegram Bot：测试消息已发送，请检查 TG 是否收到

所有模块正常，可以正式使用

部署准备

在开始之前，需要准备以下资源：

• 2 个 Cloudflare 账户：账户1 运行你主要的 Workers ，账户2 运行统计 Workers 及其他项目
• 一个 Telegram Bot，拿到 bot token，并知道目标群组或会话的 chat_id。
• 账户1 Cloudflare API Token，具备访问 Workers Analytics GraphQL 的权限
• 如果启用 Blogger 统计，还需要 Blogger Blog ID、Google OAuth Client、Client Secret、Refresh Token。（可选）

数据流向： 账户1 (生产) → Cloudflare GraphQL API → 账户2 (监控 Worker) → Telegram Bot。

网页版完整部署步骤

第一步：创建 KV 命名空间

1. 登录 Cloudflare Dashboard
2. 左侧菜单 → Workers 和 Pages → KV
3. 点击右上角「创建命名空间」
4. 名称填写 zoio-net，点击「添加」

第二步：创建 Worker

1. 左侧菜单 → Workers 和 Pages → 点击「创建」
2. 选择「创建 Worker」
3. Worker 名称填写 workers-monitor
4. 点击「部署」（从 Hello World！开始）
5. 部署完成后点击「编辑代码」
6. 将左侧编辑器内容全部清空，粘贴下方提供的完整 workers-monitor.js 代码
7. 点击右上角「部署」

第三步：绑定 KV 命名空间

1. 进入 Worker 详情页 → 顶部「设置」选项卡
2. 找到「绑定」→「KV 命名空间」→ 点击「添加绑定」
3. 变量名称填写：KV（必须大写，与代码中 env.KV 一致）
4. 选择刚才创建的 zoio-net 命名空间
5. 点击「保存」

第四步：添加环境变量

• 普通文本变量（可明文）：不涉及密钥泄露风险的配置。
• 机密变量（必须 Secret）：任何令牌、密码、OAuth 凭据、手动触发口令都应作为 Secret 保存。

同在「设置」→「变量和机密」，点击「添加变量」，依次添加以下变量：

必填变量

强烈建议配置

Blogger 可选变量

Blogger 统计依赖 Google API，需在 Google Cloud Console 开启 Blogger API 并配置 OAuth2。由于使用 Blogger 博客的属于小众，这里就不赘述获取步骤了，有需要的可以联系我获取。

WORKERS_CONFIG 示例

[
  {
    "name": "img",
    "alias": "图片代理",
    "critical": true
  },
  {
    "name": "cdn",
    "alias": "静态资源",
    "critical": false
  }
]

• name：真实的 workers 名称
• alias：在通知中显示的中文别名
• critical：是否参与关键服务离线判断

代码会解析 name、alias 和 critical 三个字段；critical: true 的 Worker 会参与关键服务离线判断与更严格的健康压分逻辑。

第五步：配置 Cron 触发器

1. Worker 详情页 → 「设置」→「触发器」
2. 「Cron 触发器」→ 点击「添加 Cron 触发器」
3. 添加：*/5 * * * *
4. 点击「保存」

代码中 scheduled() 配置要求 Cron 至少每 5 分钟运行一次，因为每日报告的发送窗口是“北京时间 23:55~23:59”。如果你的 Cron 太低频，可能错过日报发送窗口。

• 这会让 Worker 每 5 分钟执行一次计划任务。
• 当北京时间落在 23:55 以后时，代码会识别为“发送日报”模式。
• 其他时间段则主要用于告警检查与离线监控。

第六步：注册 Telegram Webhook

代码支持 Telegram 按钮刷新，需要 Telegram 把回调 POST 到的 Worker /webhook 路径，并在启用时携带 TG_WEBHOOK_SECRET 作为验签头。

打开浏览器，直接访问以下 URL（替换尖括号内容）：

https://api.telegram.org/bot<你的TG_BOT_TOKEN>/setWebhook?url=https://你的-worker域名/webhook&secret_token=<你的TG_WEBHOOK_SECRET>

部署后可以通过 type=verify 检查 Webhook 是否已注册成功。

部署完成。

HTTP 手动触发端点

所有手动触发端点都要求在 URL 中附带 ?token=<MANUAL_TOKEN>，否则代码会返回 401 Unauthorized

1. 每日报表触发

https://你的-worker域名/?token=MANUAL_TOKEN&type=daily

作用：立即执行一轮完整日报发送，按北京时间生成报表，推送到 Telegram。

2. 告警检测触发

https://你的-worker域名/?token=MANUAL_TOKEN&type=alert

作用：立即执行一轮告警检查；若达到 warning 或 critical 阈值，则向 Telegram 发送告警，否则不发送。

3. 部署自检

https://你的-worker域名/?token=MANUAL_TOKEN&type=verify

作用：检查 Cloudflare GraphQL、Blogger API、KV、Telegram Webhook、Telegram Bot 等模块是否可用，并发送一条自检消息到 Telegram。

4. 状态 JSON

https://你的-worker域名/?token=MANUAL_TOKEN&type=status

作用：返回一份 JSON 状态快照，包含 reportDateBj、quotaDateUtc、health、CF 总览、Worker 明细、Blogger 状态和统计窗口信息。

健康状态说明

代码中的系统健康分 health.score 是 0–100 的连续评分，主要由四个维度加权得出：错误率 40%、CPU 30%、延迟 15%、配额 15%

健康等级

关键指标阈值

关键 Worker 特殊逻辑

如果 critical: true 的 Worker 出现以下情况之一，系统会更严格处理：

• CPU P99 超过告警阈值
• 错误率超过告警阈值
• 延迟 P99 超过告警阈值
• 在 UTC OFFLINEUTCHOUR（默认 2 点）之后，请求数仍为 0，会触发疑似离线逻辑，并将健康分上限压到异常档

完整 workers-monitor.js 代码

代码进作为参考，请使用前先通过 AI 对代码进行分析检查，并根据自己需求进行修改调整。

代码链接：https://github.com/zoionet/Blogger/blob/main/workers-monitor.js

常见问题（FAQ）

1. 手动访问返回 401

通常是 MANUAL_TOKEN 未配置，或者 URL 中 ?token= 传值不正确。

2. Telegram 刷新按钮无效

优先检查：

• Webhook 是否注册到 /webhook。
• TG_WEBHOOK_SECRET 是否与 Telegram 设置的一致。
• 点击的是否是最新日报消息，而不是旧消息。

3. 报表没自动发出

优先检查 Cron 是否至少每 5 分钟运行一次；若 Cron 太稀疏，可能错过北京时间 23:55~23:59 的日报窗口。