实用脚本能自动监控网站可用性吗？

wen 实用脚本 2026-07-22 3

实用脚本能自动监控网站可用性吗？深度拆解+零成本搭建指南

目录导读

核心问题：为什么网站可用性监控是刚需？
脚本监控原理：从“手动F5”到“自动化告警”
五大实战脚本方案（附代码解析）
常见陷阱：为什么你的脚本“监测不准”？
Q&A：关于脚本监控的7个高频疑问
进阶建议：脚本+第三方工具的黄金组合

核心问题：为什么网站可用性监控是“隐形救命工具”？

实测数据说话：根据Pingdom统计，网站每宕机1分钟，电商平台平均损失$4,700（2023年行业报告），而WordPress插件漏洞、CDN节点故障、DNS解析延迟等问题，往往在用户投诉后才被发现。

实用脚本能自动监控网站可用性吗？

隐性成本：搜索引擎爬虫无法访问时，会降低网站权重，导致自然流量流失长达3-7天。

脚本的价值：一个仅20行的Shell脚本，就能实现每分钟检查一次HTTP状态码，并通过Telegram/邮件推送告警——比商用方案节省99%的成本。

脚本能实现什么？

持续验证：200/301/302/404/500状态码区分
性能采样：响应时间超过3秒自动标记“亚健康”
多节点模拟：在多个云服务器同时发起检测（防单点故障）

脚本监控原理：从“手动F5”到“自动化告警”

核心逻辑（伪代码示例）：

循环开始：
  发起HTTP请求→ 获取响应状态码+响应时间
  如果状态码≠200 AND 状态码≠301：
    触发告警（邮件/短信/Webhook）
  记录日志到CSV文件
  等待60秒
循环结束

关键技术点：

超时处理：用timeout命令（Linux）或setTimeout（Node.js）防止僵尸请求
重试机制：连续3次失败才确认宕机（避免网络抖动误报）
分布式检查：通过curl -H "User-Agent: MonitorBot/1.0" 模拟真实浏览器

五大实战脚本方案（附代码解析）

方案1：Shell+curl 极简监控（适合Linux）

#!/bin/bash
URL="https://example.com"
while true; do
  STATUS=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 10 $URL)
  TIME=$(curl -o /dev/null -s -w "%{time_total}" $URL)
  if [ "$STATUS" != "200" ] && [ "$STATUS" != "301" ]; then
    echo "⚠️ 宕机！状态码:$STATUS 耗时:${TIME}s" | mail -s "网站异常" admin@example.com
  fi
  echo "$(date) | $STATUS | $TIME" >> /var/log/site_monitor.log
  sleep 60
done

优点：零依赖，5分钟部署
缺点：单节点易误报，需配合nohup后台运行

方案2：Python+Requests+Telegram通知（跨平台）

import requests, time, logging
from telegram import Bot
TOKEN = "你的Bot Token"
CHAT_ID = "你的Chat ID"
def check_site(url):
    try:
        r = requests.get(url, timeout=10)
        if r.status_code == 200:
            return "正常"
        else:
            return f"异常-状态码:{r.status_code}"
    except Exception as e:
        return f"连接失败:{str(e)}"
def send_alert(msg):
    Bot(token=TOKEN).send_message(chat_id=CHAT_ID, text=f"⚠️ {msg}")
while True:
    status = check_site("https://example.com")
    if "异常" in status:
        send_alert(status)
    logging.info(f"{time.ctime()} | {status}")
    time.sleep(60)

改造建议：用requests.Session()复用连接，减少握手延迟

方案3：Node.js+Playwright 模拟浏览器监控（防SPA单页应用陷阱）

const { chromium } = require('playwright');
(async () => {
    while (true) {
        const browser = await chromium.launch({ headless: true });
        const page = await browser.newPage();
        try {
            await page.goto('https://example.com', { timeout: 15000 });
            const title = await page.title();
            if (title.includes('404') || !title) {
                await sendSMSAlert('页面加载异常');
            }
        } catch (e) {
            await sendSMSAlert(`错误: ${e.message}`);
        }
        await browser.close();
        await sleep(60000); // 每分钟检查一次
    }
})();

场景：Vue/React首屏渲染、动态加载内容时，curl无法获取真实渲染状态

方案4：多节点分布式脚本（Docker+Redis队列）

# docker-compose.yml
version: '3'
services:
  monitor-node1:
    image: curlimages/curl:latest
    command: ["sh", "/scripts/monitor.sh"]
  monitor-node2:
    image: curlimages/curl:latest
    command: ["sh", "/scripts/monitor.sh"]
  alarm-central:
    image: python:3
    volumes:
      - ./central.py:/app/central.py
    command: python /app/central.py

核心逻辑：每个节点将状态写入Redis，中央处理脚本统计“多数节点确认宕机”后才告警，防止单节点误报。

方案5：Windows PowerShell+事件日志（适合企业内网）

$url = "https://example.com"
while ($true) {
    try {
        $response = Invoke-WebRequest -Uri $url -TimeoutSec 10
        if ($response.StatusCode -ne 200) {
            Write-EventLog -LogName Application -Source "SiteMonitor" -EventId 1001 -EntryType Error -Message "状态码: $($response.StatusCode)"
        }
    } catch {
        Write-EventLog -LogName Application -Source "SiteMonitor" -EventId 1002 -EntryType Error -Message "连接失败: $($_.Exception.Message)"
    }
    Start-Sleep -Seconds 60
}

优势：集成Windows事件查看器，方便企业日志审计。

常见陷阱：为什么你的脚本“监测不准”？

忽略CDN缓存：静态页面被CDN缓存后，你检测的可能是200，但真实用户遭遇503。
→ 解决：在URL后加随机参数 ?t=$(date +%s) 绕过缓存
单节点黑洞：如果脚本所在服务器正好与目标站处于同一机房，网络中断时一同躺平。
→ 解决：至少部署3个地理位置分散的监控节点
状态码误判：有些网站用302重定向做A/B测试，脚本应识别302为“可用”但标记“需人工审核”
响应时间陷阱：脚本监控到响应时间2.5秒，但用户实际受DNS解析、网络延迟影响更大。
→ 解决：在脚本中加入 curl -w "connect_time:%{time_connect},total_time:%{time_total}" 细粒度分析

Q&A：关于脚本监控的7个高频疑问

Q1：脚本会消耗大量服务器资源吗？
A：一个curl请求约占用0.1% CPU（单核），200ms内存，300个站点每分钟检查一次的脚本，相当于多开了一个网页后台。

Q2：能否用手机接收告警？
A：通过Telegram Bot（见方案2）、Pushover（iOS/Android）、或IFTTT Webhook，不建议用Gmail SMTP——手机通知延迟可达15分钟。

Q3：脚本监控覆盖不了海外用户怎么办？
A：租用3-5个低价海外VPS（如DigitalOcean $5/月节点），运行同一脚本并将状态推送到中央数据库，免费方案：Cloudflare Worker每分钟发起请求（每月10万次免费）。

Q4：如何检测“部分可用”？比如支付接口挂了，首页却正常。
A：脚本追加多个检查点：

for page in "/v1/payment" "/v1/login" "/v1/api/health"; do
  curl -I "https://example.com$page"
done

Q5：免费监控工具有哪些？
A：UptimeRobot（每月5站点监控+状态页），Better Uptime（邮件+Slack集成），但都存在“检查间隔最短5分钟”的延迟——付费用户才支持1分钟间隔，这恰恰是脚本的最大优势。

Q6：脚本版本管理需要注意什么？
A：使用Git管理监控脚本，每次修改后自动运行 git diff 并发送变更摘要到安全邮箱，防止恶意篡改。

Q7： 什么情况下脚本不如付费监控？
A：需要全局CDN节点覆盖（如Akamai）、WebSocket实时监控、Kubernetes集群健康检查时，脚本代码量会暴增数百行，此时商业方案（如Datadog、New Relic）更高效。

进阶建议：脚本+第三方工具的黄金组合

需求	脚本实现方式	推荐补充工具
实时告警	邮件/Telegram推送	PagerDuty（支持电话报警）
历史可视化	写入InfluxDB时序数据库	Grafana仪表盘
避免误报	多节点投票机制	Better Uptime记录网络抖动
自动恢复	脚本调用云平台API重启服务	Jenkins Pipeline
复杂场景检测（如登录流程）	Puppeteer模拟用户操作	Selenium Grid

最终建议：用脚本实现基础监控（每分钟检查+Telegram告警），再配合免费层级有限的UptimeRobot作为备用验证——这比单买任何付费方案都划算。

文章总结：实用脚本不仅能自动监控网站可用性，而且能根据业务需求无限定制，从初级的curl一行命令，到分布式的Python+Redis架构，脚本覆盖了从个人博客到电商平台的完整监控场景，容易犯的错误是忽略多节点和超时处理——但只要遵循本文的陷阱应对方案，脚本监控的安全性和及时性甚至超过部分商业工具，对于不要特别复杂的SLA需求，请优先尝试脚本体系；对于大型企业的全球监控，则用脚本做个性化补充即可。