多站点健康监控器

概述

多站点健康监控器技能可自动持续监控 10 至 100+ 个网站，支持可配置的健康检查、智能告警路由与自动事件升级。该生产级监控解决方案集成了 Slack、PagerDuty、Datadog、Google Sheets 和 WordPress，为您的数字基础设施提供实时可见性。

为何重要

• 防止收入损失：秒级发现服务中断，而非数小时后才察觉
• 降低告警疲劳：通过智能阈值与去重机制，避免通知过载
• 自动化事件响应：自动重启失败服务，并升级至待命团队
• 多通道告警：将关键问题路由至 PagerDuty，警告发送至 Slack，指标同步至 Datadog
• 历史分析能力：追踪正常运行时间趋势、识别规律、生成合规报告

核心集成能力

• Slack：实时告警、事件专用频道、状态仪表板
• PagerDuty：自动创建事件、待命人员升级、事件全生命周期跟踪
• Datadog：指标采集、自定义仪表板、异常检测
• Google Sheets：自动化报表、SLA 追踪、审计日志
• WordPress：监控插件健康状态、主题更新、核心漏洞
• AWS/Azure：自动重启 EC2 实例、触发 Lambda 函数、动态扩缩容基础设施

快速入门

立即尝试以下示例提示：

示例 1：监控 5 个关键站点并发送 Slack 告警

每 5 分钟监控以下站点，任一失败即向 Slack 发送告警：
- https://api.example.com/health
- https://app.example.com/status
- https://cdn.example.com/ping
- https://wordpress.example.com/wp-json/health
- https://db.example.com/check

告警规则：
- 关键（页面不可用）：发送至 Slack #incidents + PagerDuty
- 警告（响应耗时 >3 秒）：发送至 Slack #alerts
- 信息（SSL 证书剩余有效期 <30 天）：记录至 Google Sheets 日志

示例 2：自动重启失败服务

每 2 分钟监控 https://payment-service.example.com/health。
若连续失败 3 次，则执行：
1. 向 https://restart-api.example.com/restart-payment-service 发送 POST 请求
2. 向 PagerDuty 发送告警，事件标题为 “Payment Service Down”
3. 向 Slack #critical-incidents 发送通知
4. 将时间戳、错误详情及重启状态记录至 Google Sheets

响应超时：10 秒  
预期响应：HTTP 200，且响应体为 {"status":"healthy"}

示例 3：WordPress 多站点监控

监控以下 WordPress 站点的健康与安全状态：
- https://site1.example.com/wp-json/wp/v2/health-check
- https://site2.example.com/wp-json/wp/v2/health-check
- https://site3.example.com/wp-json/wp/v2/health-check

检查项包括：
- 核心版本更新可用（若距上次更新 >1 周则发出警告）
- 插件存在已知漏洞（任意一个即视为关键）
- 数据库连接状态（断连即视为关键）
- SSL 证书到期时间（剩余有效期 <30 天则发出警告）

告警目标：
- 关键：发送至 PagerDuty + Slack #wordpress-critical
- 警告：发送至 Slack #wordpress-alerts
- 信息：记录至 Google Sheets #monitoring-log

示例 4：性能阈值监控

每 10 分钟监控 https://api.example.com/metrics。
当满足以下任一条件时触发告警：
- 响应时间 > 2000ms（警告）或 > 5000ms（关键）
- 错误率 > 1%（警告）或 > 5%（关键）
- CPU 使用率 > 70%（警告）或 > 90%（关键）
- 内存使用率 > 80%（警告）或 > 95%（关键）

将指标推送至 Datadog，附带标签：env:prod, service:api, team:backend

功能特性

1. 多协议健康检查

支持通过以下协议监控端点：

• HTTP/HTTPS：支持 GET、POST、HEAD 请求及自定义请求头
• TCP：端口连通性检查（例如数据库端口 3306、5432）
• DNS：域名解析验证、DNS 传播状态确认
• SSL/TLS：证书有效性、过期预警、证书链完整性校验
• Ping/ICMP：基础设施节点基础连通性检测

示例：使用自定义认证监控 API 健康状态

端点：https://api.example.com/health  
方法：POST  
请求头：  
  Authorization: Bearer YOUR_API_KEY  
  User-Agent: MultiSiteMonitor/1.0.0  
期望状态码：200  
期望响应体：{"status":"healthy","version":"2.1.0"}  
超时时间：10 秒

2. 智能告警路由

• 按严重程度路由：关键 → PagerDuty + Slack + 短信；警告 → 仅 Slack；信息 → 记录至 Sheets
• 告警去重：5 分钟时间窗口内抑制重复告警
• 升级规则：关键问题持续未解决超过 30 分钟后自动升级
• 自定义阈值：按端点设置灵敏度（例如 API 端点比博客更严格）
• 静默时段：在维护窗口期间屏蔽非关键告警

3. 自动事件响应

• Webhook 触发：向自定义端点发送 POST 请求（用于重启服务、扩缩容等）
• AWS 集成：自动重启 EC2 实例、触发 Lambda 函数
• 服务重启：通过 SSH 在远程服务器上执行 Shell 命令
• 回滚触发：健康检查失败时自动回退部署
• 通知动作：在 Jira、GitHub Issues 或 Linear 中创建工单

4. 性能指标与趋势分析

• 响应时间追踪：在性能问题演变为关键故障前及时发现
• 正常运行时间计算：实时 SLA 追踪（99.9%、99.95%、99.99%）
• 错误率监控：追踪 HTTP 4xx、5xx 及超时错误
• Datadog 集成：推送自定义指标以供仪表板展示与告警使用
• 历史报表：生成月度正常运行时间报告、SLA 合规文档

5. WordPress 专属监控

• 核心更新：检测 WordPress 核心更新是否可用
• 插件漏洞：比对 WordPress 漏洞数据库进行扫描
• 主题安全：监控是否存在过期或存在漏洞的主题
• 数据库健康：监控 wp_options 表、数据表完整性、查询性能
• 用户活动：追踪可疑登录行为、新管理员账户创建
• 备份验证：确认备份任务是否成功完成

6. 合规性与审计日志

• Google Sheets 集成：自动记录所有检查、告警与操作行为
• 审计轨迹：完整记录谁在何时触发了何种操作，以及结果如何
• SLA 报告：按月/季度生成合规报告（含 99.9% 正常运行时间证明）
• 变更追踪：带时间戳记录所有配置变更
• 导出格式：支持 CSV、JSON、PDF 格式，便于提交合规材料

配置说明

必需的环境变量

# Slack 通知
export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
export SLACK_CHANNEL="#incidents"  # 或 #alerts、#monitoring 等

# PagerDuty 事件创建
export PAGERDUTY_API_KEY="YOUR_PAGERDUTY_API_KEY"
export PAGERDUTY_SERVICE_ID="YOUR_SERVICE_ID"

# Datadog 指标采集
export DATADOG_API_KEY="YOUR_DATADOG_API_KEY"
export DATADOG_APP_KEY="YOUR_DATADOG_APP_KEY"
export DATADOG_SITE="datadoghq.com"  # 或 datadoghq.eu

# Google Sheets 日志记录
export GOOGLE_SHEETS_ID="YOUR_SPREADSHEET_ID"
export GOOGLE_SERVICE_ACCOUNT_JSON="/path/to/service-account.json"

# AWS 自动重启（可选）
export AWS_ACCESS_KEY_ID="YOUR_AWS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_AWS_SECRET"
export AWS_REGION="us-east-1"

# SSH 远程服务重启（可选）
export SSH_PRIVATE_KEY="/path/to/private/key"
export SSH_USER="deploy"

配置文件格式（YAML）

# monitors.yaml
monitors:
  - name: "Production API"
    url: "https://api.example.com/health"
    interval: 300  # 秒
    timeout: 10
    method: "GET"
    expected_status: 200
    expected_body_contains: "healthy"
    alert_rules:
      critical:
        - slack_channel: "#critical-incidents"
        - pagerduty_severity: "critical"
      warning:
        - slack_channel: "#alerts"
    auto_restart:
      enabled: true
      command: "systemctl restart api-service"
      max_retries: 3
      retry_delay: 60

  - name: "WordPress Site"
    url: "https://wordpress.example.com/wp-json/wp/v2/health-check"
    interval: 600
    timeout: 15
    method: "GET"
    headers:
      Authorization: "Bearer YOUR_WP_TOKEN"
    checks:
      - type: "wordpress_core_updates"
        alert_if: "available"
        severity: "warning"
      - type: "plugin_vulnerabilities"
        alert_if: "found"
        severity: "critical"
      - type: "ssl_certificate"
        expires_in_days: 30
        severity: "warning"
    alert_rules:
      critical:
        - pagerduty_severity: "critical"
        - slack_channel: "#wordpress-critical"
      warning:
        - slack_channel: "#wordpress-alerts"
        - google_sheets: true

  - name: "Database Health"
    url: "https://db-monitor.example.com/health"
    interval: 120
    timeout: 20
    method: "POST"
    headers:
      Content-Type: "application/json"
      Authorization: "Bearer YOUR_DB_TOKEN"
    body: '{"check":"full"}'
    expected_status: 200
    performance_thresholds:
      response_time_ms: 2000
      error_rate_percent: 1.0
    alert_rules:
      critical:
        - pagerduty_severity: "critical"
        - datadog_metric: "db.health.critical"
      warning:
        - datadog_metric: "db.health.warning"
        - slack_channel: "#database-alerts"

配置步骤

1. 创建监控配置：将上述 YAML 保存为 monitors.yaml
2. 设置环境变量：通过 .env 文件加载所有必需的 API 密钥
3. 初始化 Google Sheets：新建电子表格，并将其共享给服务账号邮箱
4. 测试端点：运行 multi-site-health-monitor --validate 验证所有 URL 是否可正常响应
5. 部署运行：作为 systemd 服务或 Docker 容器长期运行，实现持续监控

示例输出

Slack 告警（关键级别）

🚨 CRITICAL: Production API Down  
服务：Production API (api.example.com/health)  
状态：HTTP 500 Internal Server Error  
响应时间：12.3 秒（超时阈值：10 秒）  
最近一次正常状态：2024-01-15 14:32:15 UTC  
事件持续时间：5 分钟 23 秒  
告警次数：连续失败 3 次  

自动重启状态：✅ 已触发（第 1/3 次尝试）  
PagerDuty 事件编号：INC-12345（已分配给 @oncall-backend）  

下次检查时间：2024-01-15 14:42:15 UTC  
升级策略：若 25 分钟内仍未解决，将升级至 #management 频道

Google Sheets 日志条目

时间戳              | 服务             | 状态 | 响应时间 | 错误         | 执行动作  
2024-01-15 14:37   | Production API | FAIL | 12300ms  | HTTP 500     | 已触发自动重启  
2024-01-15 14:32   | Production API | FAIL | 10100ms  | 超时         | 已发送告警  
2024-01-15 14:27   | Production API | OK   | 245ms    | -            | -  
2024-01-15 14:22   | WordPress Site | WARN | 3200ms   | 响应缓慢     | 已发送告警  
2024-01-15 14:17   | Database Health| OK   | 145ms    | -            | -

PagerDuty 事件

事件编号：INC-12345  
服务：Production API  
严重程度：Critical  
状态：Triggered  
标题：Production API Down - HTTP 500 (5min+ duration)  
描述：  
  端点：https://api.example.com/health  
  状态：HTTP 500 Internal Server Error  
  响应时间：12.3 秒  
  连续失败次数：3  
  最近一次正常状态：2024-01-15 14:32:15 UTC  
  自动重启：已触发（第 1/3 次尝试）  
  
指派对象：@oncall-backend  
创建时间：2024-01-15 14:37:00 UTC  
升级策略：Backend On-Call → Manager → VP Engineering

Datadog 推送的指标

multi_site_monitor.health_check.response_time:245ms (tags: service:api, env:prod)  
multi_site_monitor.health_check.status:200 (tags: service:api, env:prod)  
multi_site_monitor.health_check.availability:99.87 (tags: service:api, env:prod)  
multi_site_monitor.auto_restart.attempts:1 (tags: service:api, env:prod)

使用技巧与最佳实践

1. 推荐的检查间隔

• 关键 API：60–120 秒（可在 2–4 分钟内发现问题）
• 常规服务：300 秒（5 分钟，兼顾效率与负载）
• 非关键端点：600–900 秒（10–15 分钟，减少噪音）
• 批处理任务：1800+ 秒（30+ 分钟，降低监控频率）

2. 阈值调优

• 保守起步：初始采用宽松阈值，两周内逐步收紧
• 考虑波动性：响应时间阈值建议设为基线值的 2–3 倍
• 错误率：0.1–1% 设为警告，5%+ 设为关键（依各服务 SLA 调整）
• 阈值验证：主动使端点失效，验证告警路由逻辑是否生效

3. 降低告警疲劳

• 告警去重：5 分钟窗口内抑制相同告警
• 智能升级：仅当问题持续超过 30 分钟才升级
• 静默时段：凌晨 2 点至 6 点禁用非关键告警（按实际时区调整）
• 分级映射：并非所有问题都需标记为“关键”，轻微问题宜使用“警告”或“信息”等级

4. WordPress 专属最佳实践

• 核心更新检查频率：设为 604800 秒（7 天一次）
• 插件健康检查：每日检查插件漏洞与过期情况
• 数据库备份验证：在健康检查端点中返回备份完成状态
• 预发布环境监控：独立监控 staging 站点，在上线前捕获潜在问题
• 自定义健康端点：创建 /wp-json/custom/health，返回包含完整系统状态的 JSON

5. 成本优化策略

• 批量检查：尽可能将 5–10 项检查合并为单次 HTTP 请求
• Datadog 采样：每 5 分钟推送详细指标，每小时推送摘要指标
• Google Sheets：批量写入（单次最多 100 行），减少 API 调用次数
• PagerDuty：启用去重功能，避免触发重复事件

6. 安全加固措施

• API 密钥轮换：每月轮换全部 API 密钥
• VPC 监控：仅从私有子网内监控内部端点
• IP 白名单：限制健康检查端点的访问来源 IP