VPSKnow

VPS 运行监控与宕机报警完全指南

中级
35分钟

监控不是一块好看的大屏,而是“发现异常、通知到人、保留证据、确认恢复”的闭环。至少从另一台机器或托管探针检查真实业务路径,再用主机指标解释原因;监控系统本身也需要外部心跳、配置备份和定期通知演练。

👀 为什么需要监控?

🚨

故障秒级感知

网站打不开?数据库挂了?监控系统能在 1 分钟内通过 Telegram 发警报到您手机——比用户投诉早几小时。

📈

容量与性能预警

硬盘用了 90%?内存持续爆满?提前发现瓶颈,在系统彻底卡死前进行清理或扩容。

📊

SLA 历史复盘

记录 VPS 真实在线率(Uptime)。服务商频繁断网?有数据截图才能申请退款或换机。

⚖️ 主流监控方案对比

监控至少包含两层:从故障域之外验证 DNS、TLS、HTTP 内容和真实操作是否可用,以及在服务器内部采集资源与应用指标解释原因。两层应分开部署并互相补充。

工具 类型 内存占用 核心优势 适合场景
Uptime Kuma 外部可用性监控 按实例实测
  • HTTP/TCP/DNS/关键字检测
  • 支持状态页与通知
  • 可监控定时任务心跳
网站/API/证书与任务心跳
哪吒探针 (Nezha) 服务器集群监控 ~30MB
  • 多台 VPS 同屏展示资源
  • 内置 WebSSH 和文件管理
  • 支持流量/CPU/内存/硬盘全指标
拥有多台 VPS 的玩家
Prometheus + Grafana 企业级时序监控 ~500MB+
  • 图表最丰富,数据精度最高
  • 告警规则极其灵活
  • 开源生态最完整(Node Exporter 等)
企业生产环境/大型系统
Shell 脚本 + Cron 本机补充检查 接近零常驻
  • 逻辑可审阅
  • 适合特定业务检查
  • 可接入现有通知
低配 VPS 的补充与应急

💡 最小可用搭配: 把 Uptime Kuma 或托管探针放在不同故障域,检查 HTTPS 状态、响应内容、证书和关键任务心跳;业务机安装哪吒 Agent 或 Node Exporter 查看资源指标。状态页可以与内部管理面分开,避免公开敏感主机信息。

🟢 实战:Uptime Kuma 部署与配置

Uptime Kuma 被誉为"自托管版 UptimeRobot",UI 极具现代感,支持 HTTP/TCP/DNS/关键字等多种检测方式,可以生成公开的状态页面(如 status.yourdomain.com)供用户查看服务状态。

Docker Compose 部署

/opt/uptime-kuma/docker-compose.yml
# 文件路径:/opt/uptime-kuma/docker-compose.yml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:${KUMA_VERSION} # .env 固定已复核版本,如 2.3.2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"     # 只绑定本地,配合 Nginx 反代
    volumes:
      - ./kuma-data:/app/data      # 必须使用本地文件系统,不使用 NFS
    environment:
      - TZ=Asia/Shanghai           # 时区设置,确保日志时间正确

Nginx 反代配置(开启 HTTPS + WebSocket)

/etc/nginx/conf.d/status.conf
# 文件路径:/etc/nginx/conf.d/status.conf
# 将 Uptime Kuma 暴露为 status.yourdomain.com

server {
    listen 443 ssl;
    http2 on;
    server_name status.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/status.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.yourdomain.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_http_version 1.1;
        # WebSocket 支持(Uptime Kuma 实时推送依赖 WS)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 86400;   # 长连接超时
    }
}

server {
    listen 80;
    server_name status.yourdomain.com;
    return 301 https://$host$request_uri;
}

⚙️ 登录后首要配置步骤

  1. 访问 https://status.yourdomain.com,首次访问创建管理员账号
  2. 点击"添加新的监控"→ 类型选 HTTP(s),填入您的网站 URL
  3. 设置检测间隔(建议 60 秒),连续失败次数(建议 3 次才告警,避免误报)
  4. 在"设置 → 通知"中配置 Telegram 告警(见本文第6章)
  5. 在"状态页"中创建公开页面,分享给用户查看实时状态

👦 实战:哪吒探针多机监控

当您的 VPS 超过 3 台时就需要哪吒探针了。它分为面板端(Panel)(一台机器,负责展示和管理)和探针端(Agent)(每台被监控的机器,负责采集数据上报)。

面板端部署

哪吒面板端安装
# ── 面板端部署(选择一台专用机器作为控制中心)──────────────────────────────
# 前提:在 GitHub 创建 OAuth App(Settings → Developer settings → OAuth Apps)
# Homepage URL: https://nezha.yourdomain.com
# Callback URL: https://nezha.yourdomain.com/oauth2/callback

# 一键安装脚本
curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh   -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh
# 选择 [1] 安装面板端,按提示输入:
# - GitHub OAuth Client ID 和 Client Secret
# - 管理员 GitHub 用户名

# 安装完成后面板访问:https://nezha.yourdomain.com
# 默认不需要密码,用 GitHub 账号登录即是管理员

被控端 Agent 部署

每台被监控服务器执行
# ── 被控端 Agent 部署(在每台需要被监控的服务器上执行)──────────────────
# 在哪吒面板后台:服务器 → 添加服务器,系统会生成一条安装命令,如:

curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh   -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh
# 选择 [8] 安装 Agent
# 输入面板域名:nezha.yourdomain.com
# 输入 Agent 密钥:面板后台生成的密钥(每台机器独立)

# Agent 安装后会自动注册,在面板上实时显示:
# CPU 占用率、内存使用、磁盘剩余、网络流入/流出、进程数等

⚠️ 架构建议: 面板端机器最好专用,不要跑高负载应用——如果面板机器挂了,所有被控端的状态都看不到了。可以选一台低配但稳定的 VPS(如 $3/月 的小鸡)专门跑哪吒面板。

🌸 实战:Komari 探针轻量部署

Komari 是近年来备受关注的新一代服务器监控探针,由国人开发,界面简洁美观,部署极其简单。相比哪吒探针,Komari 的 Agent 更轻量,面板端无需 GitHub OAuth 认证,配置门槛更低,非常适合只想快速上手的用户。

哪吒探针

  • 功能最完整(WebSSH/文件管理/任务)
  • 社区最活跃,文档丰富
  • 需要 GitHub OAuth 登录认证

Komari ⭐

  • 界面更简洁现代,颜值更高
  • 部署更简单,账密直接登录
  • 轻量省资源,响应速度快

面板端 Docker Compose 部署

/opt/komari/docker-compose.yml
# 文件路径:/opt/komari/docker-compose.yml

services:
  komari:
    image: ghcr.io/komari-monitor/komari:latest
    container_name: komari
    restart: unless-stopped
    ports:
      - "25565:25565"   # 只绑定本地,配合 Nginx 反代
    volumes:
      - ./data:/app/data           # 数据持久化(配置、节点信息)
    environment:
      - TZ=Asia/Shanghai

# 启动:docker compose up -d
# 首次访问 http://服务器IP:25565 创建管理员账号(直接账密登录,无需 OAuth)

被控端 Agent 安装(每台被监控的服务器执行)

Komari Agent 安装
# 在 Komari 面板后台:节点管理 → 添加节点,复制生成的安装命令
# 命令格式类似:
curl -fsSL https://raw.githubusercontent.com/komari-monitor/komari-agent/main/install.sh \
  | bash -s -- --server https://komari.yourdomain.com --token 你的节点Token

# Agent 会自动注册为系统服务(systemd),开机自启
# 安装成功后几秒内即可在面板上看到该节点的实时指标

💡 Komari 与哪吒可以共存: 两者的 Agent 互不冲突,可以同时安装在同一台服务器上。哪吒用于日常运维(WebSSH 远程登录很方便),Komari 用于对外展示美观的公开状态页。

📊 进阶:Prometheus + Grafana 企业级监控

如果您需要更精细的时序数据(如每秒 CPU 波动、HTTP 请求延迟分布),Prometheus + Grafana 是业界标准方案。代价是资源占用较高(约 500MB 内存),适合 2GB+ 内存的服务器。

docker-compose.yml(三服务全栈)

/opt/monitoring/docker-compose.yml
# 文件路径:/opt/monitoring/docker-compose.yml
# 完整监控栈:Prometheus + Grafana + Node Exporter

services:

  # ── Prometheus:时序数据收集与存储 ──────────────────────────────────────────
  prometheus:
    image: prom/prometheus:${PROMETHEUS_VERSION}
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "127.0.0.1:9090:9090"      # 不向公网暴露管理与查询接口
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml  # 配置文件
      - prometheus_data:/prometheus                       # 数据持久化
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.retention.time=15d                 # 保留 15 天数据

  # ── Node Exporter:采集宿主机系统指标 ────────────────────────────────────────
  node-exporter:
    image: prom/node-exporter:${NODE_EXPORTER_VERSION}
    container_name: node-exporter
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - --path.procfs=/host/proc
      - --path.sysfs=/host/sys

  # ── Grafana:数据可视化仪表盘 ────────────────────────────────────────────────
  grafana:
    image: grafana/grafana:${GRAFANA_VERSION}
    container_name: grafana
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}  # .env 权限设为 600
      - GF_USERS_ALLOW_SIGN_UP=false                     # 禁止公开注册

volumes:
  prometheus_data:
  grafana_data:

prometheus.yml 抓取配置

/opt/monitoring/prometheus.yml
# 文件路径:/opt/monitoring/prometheus.yml
# Prometheus 抓取配置

global:
  scrape_interval: 15s      # 每 15 秒抓取一次指标
  evaluation_interval: 15s

scrape_configs:
  # 采集 Prometheus 自身指标
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # 采集宿主机系统指标(通过 Node Exporter)
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100'] # Compose 网络内使用服务名

  # 如需监控其他服务器,添加更多 targets:
  # - job_name: 'remote-server'
  #   static_configs:
  #     - targets: ['服务器IP:9100']

💡 Grafana 仪表盘快速导入: 登录 Grafana(默认 admin / 您设置的密码)→ Dashboards → Import → 输入 Dashboard ID 1860(Node Exporter Full)→ 选择 Prometheus 数据源 → 导入。这是社区最流行的 Linux 系统监控仪表盘,覆盖 CPU/内存/磁盘/网络全部指标,开箱即用。

📱 进阶:多渠道告警通知配置

监控的目的是及时通知。相比邮件,即时通讯工具推送速度更快、到达率更高。以下是最常用的告警渠道:

Telegram 机器人(个人最推荐)

Telegram Bot 创建与测试
# ── 通过 BotFather 创建 Telegram 机器人 ─────────────────────────────────────
# 1. 在 Telegram 搜索 @BotFather,发送 /newbot
# 2. 输入机器人名称(如 MyVPS Monitor Bot)
# 3. 输入机器人用户名(必须以 bot 结尾,如 myvps_monitor_bot)
# 4. BotFather 返回 HTTP API Token(格式:1234567890:ABCdef...)

# ── 获取 Chat ID ──────────────────────────────────────────────────────────────
# 方法一:搜索 @userinfobot,发送任意消息,它会回复您的 User ID
# 方法二:将机器人加入群组,发送消息后访问:
# https://api.telegram.org/bot<TOKEN>/getUpdates
# 在返回的 JSON 中找到 "chat":{"id": 你的Chat_ID}

# ── 测试发送消息(替换 TOKEN 和 CHAT_ID)────────────────────────────────────
BOT_TOKEN="你的Bot_Token"
CHAT_ID="你的Chat_ID"

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage"   -d "chat_id=${CHAT_ID}"   -d "parse_mode=Markdown"   -d "text=✅ *测试消息*
服务器:$(hostname)
时间:$(date '+%Y-%m-%d %H:%M:%S')
CPU:$(top -bn1 | grep 'Cpu(s)' | awk '{print $2}')%"
# 如果手机收到消息,配置成功!

企业微信 / 飞书 / 钉钉 Webhook(团队场景)

企业微信 / 飞书 / 钉钉 Webhook
# ── 企业微信机器人 Webhook ───────────────────────────────────────────────────
# 在企业微信群聊 → 群设置 → 群机器人 → 添加 → 自定义机器人 → 复制 Webhook URL

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": "⚠️ 服务器告警
主机:yourdomain.com
状态:CPU 使用率超过 90%"
    }
  }'

# ── 飞书机器人 Webhook ────────────────────────────────────────────────────────
# 飞书群聊 → 设置 → 群机器人 → 添加机器人 → 自定义机器人 → 复制 Webhook URL

curl -s -X POST "https://open.feishu.cn/open-apis/bot/v2/hook/你的Token"   -H "Content-Type: application/json"   -d '{
    "msg_type": "text",
    "content": {
      "text": "⚠️ 服务器告警:CPU 使用率超过 90%"
    }
  }'

# ── 钉钉机器人 Webhook ────────────────────────────────────────────────────────
# 钉钉群聊 → 群设置 → 智能群助手 → 添加机器人 → 自定义 → 复制 Webhook URL

curl -s -X POST "https://oapi.dingtalk.com/robot/send?access_token=你的Token"   -H "Content-Type: application/json"   -d '{
    "msgtype": "text",
    "text": {
      "content": "⚠️ 服务器告警:磁盘使用率超过 85%"
    }
  }'

📋 Uptime Kuma 支持的通知渠道(部分)

Telegram企业微信飞书钉钉SlackDiscordEmailPushoverLineWhatsAppPagerDutyWebhook

在 Uptime Kuma 面板内直接图形化配置,无需手写代码。

📝 轻量:Shell 监控脚本(无 Docker)

如果您的 VPS 内存不足以跑 Docker 监控工具,或者只是想学习监控的底层原理,可以用一个简单的 Shell 脚本配合 Cron 实现基本的自动巡检和告警。

/root/server-check.sh
#!/bin/bash
# ════════════════════════════════════════════════════════════════════
#  轻量服务器自检脚本(无需 Docker,适合低配 VPS)
#  功能:检查 CPU/内存/磁盘/关键服务,超阈值发送 Telegram 告警
# ════════════════════════════════════════════════════════════════════
set -euo pipefail

# ── 配置区 ────────────────────────────────────────────────────────────────────
: "${TG_TOKEN:?请通过受限环境文件提供 TG_TOKEN}"
: "${TG_CHAT_ID:?请通过受限环境文件提供 TG_CHAT_ID}"
CPU_THRESHOLD=85               # CPU 使用率告警阈值(%)
MEM_THRESHOLD=90               # 内存使用率告警阈值(%)
DISK_THRESHOLD=85              # 磁盘使用率告警阈值(%)
SERVICES=("nginx" "mysql")     # 需要检查状态的系统服务
LOG_FILE="/var/log/server-check.log"

# ── 工具函数 ──────────────────────────────────────────────────────────────────
log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"; }

send_alert() {
  local msg="$1"
  log "ALERT: $msg"
  if [[ -n "$TG_TOKEN" && -n "$TG_CHAT_ID" ]]; then
    curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage"       -d "chat_id=${TG_CHAT_ID}"       -d "text=⚠️ $(hostname): $msg" > /dev/null 2>&1 || true
  fi
}

# ── 检查 CPU ──────────────────────────────────────────────────────────────────
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print int($2)}')
if (( CPU_USAGE > CPU_THRESHOLD )); then
  send_alert "CPU 使用率 ${CPU_USAGE}%,超过阈值 ${CPU_THRESHOLD}%"
fi

# ── 检查内存 ──────────────────────────────────────────────────────────────────
MEM_TOTAL=$(free | awk '/Mem:/ {print $2}')
MEM_USED=$(free | awk '/Mem:/ {print $3}')
MEM_USAGE=$(( MEM_USED * 100 / MEM_TOTAL ))
if (( MEM_USAGE > MEM_THRESHOLD )); then
  send_alert "内存使用率 ${MEM_USAGE}%,超过阈值 ${MEM_THRESHOLD}%"
fi

# ── 检查磁盘(检查所有已挂载的本地文件系统)──────────────────────────────────
while IFS= read -r line; do
  USAGE=$(echo "$line" | awk '{print $5}' | tr -d '%')
  MOUNT=$(echo "$line" | awk '{print $6}')
  if (( USAGE > DISK_THRESHOLD )); then
    send_alert "磁盘 ${MOUNT} 使用率 ${USAGE}%,超过阈值 ${DISK_THRESHOLD}%"
  fi
done < <(df -h --output=source,size,used,avail,pcent,target | grep '^/' | tail -n +2)

# ── 检查关键服务 ──────────────────────────────────────────────────────────────
for svc in "${SERVICES[@]}"; do
  if ! systemctl is-active --quiet "$svc"; then
    send_alert "服务 $svc 已停止运行,需要人工确认日志、依赖和最近变更"
  fi
done

log "自检完成:CPU=${CPU_USAGE}% MEM=${MEM_USAGE}% DISK 检查完成"

# ── 部署(每 5 分钟执行一次)────────────────────────────────────────────────
# chmod +x /root/server-check.sh
# crontab -e 添加:
# 使用权限为 600 的 EnvironmentFile 向 systemd timer 提供令牌;
# 不要把令牌直接写进脚本或 crontab,也不要静默自动重启未知故障

常见问题解答

Uptime Kuma 的检测间隔设多少合适?设太短会有问题吗?

建议设置 60 秒作为通用值。设置太短(如 10 秒)会增加被监控服务器的请求压力,同时 Uptime Kuma 自身也需要更多 CPU 处理高频检测。对于关键 API 或支付页面等高优先级服务可以降到 30 秒,普通内容站点 120 秒完全够用。另一个重要参数是"判定宕机的失败次数"——建议设为 3 次(即连续 3 次检测失败才触发告警),避免因短暂网络波动导致误报。Uptime Kuma 还支持"心跳监控"模式,适合监控定时任务是否按时执行(配合第 19 篇备份脚本完成后 curl 一个 Kuma 提供的心跳 URL)。

哪吒探针和 Uptime Kuma 应该装在同一台服务器上吗?

可以同机学习,但不能把它当作可靠宕机告警:主机断电、网络隔离或 Docker 故障时,监控和通知会同时消失。生产环境至少保留一个不同提供商、区域或托管平台的外部探测,并让它监控监控面板自身。资源占用应以实际监控数量、保留周期和插件测量,不用固定内存数字承诺低配机器一定无压力。

Telegram 机器人无法收到通知,如何排查?

按顺序排查:① Bot Token 和 Chat ID 是否正确:用本文的 curl 命令手动测试发送,看是否收到消息;② 是否先给机器人发过消息:Telegram Bot 只能向主动开启对话的用户发消息,先搜索机器人用户名,点击 Start 发一条消息;③ Chat ID 是否正确:用 @userinfobot 获取的是您自己的 User ID(正确);如果是群组 Chat ID,通常是负数(如 -1001234567890),确认格式;④ 服务器能否访问 Telegram API:部分服务器的防火墙或网络策略限制了 api.telegram.org 的访问,用 curl https://api.telegram.org/bot你的TOKEN/getMe 测试连通性;⑤ Uptime Kuma 内的通知设置:确认通知已关联到具体的监控项(添加/编辑监控时勾选通知)。

Grafana 仪表盘显示没有数据,Prometheus 配置正确但抓不到指标,怎么办?

系统性排查:① docker compose ps 和日志确认 Node Exporter 正常;② 从 Prometheus 容器内请求 http://node-exporter:9100/metrics,验证服务名、端口和网络,而不是用容器内的 localhost;③ 查看 Prometheus Targets 页面中的错误信息,但只通过本机隧道或受保护反代访问;④ Grafana 数据源在 Compose 网络内使用 http://prometheus:9090。不要为了排查把 9090/9100 临时开放到公网。

能否监控 Docker 容器的 CPU/内存,而不仅仅是宿主机?

可以,有多种方案:① cAdvisor(容器顾问):Google 开源的 Docker 容器监控工具,以容器方式运行,自动发现并采集所有容器的 CPU/内存/网络/磁盘指标,可以直接被 Prometheus 抓取。在 docker-compose.yml 中添加 cadvisor 服务,配置 Prometheus 抓取 cadvisor:8080 端口;② 哪吒探针:Agent 本身就能采集宿主机上所有 Docker 容器的资源使用情况,在面板中按容器维度查看;③ docker stats 命令docker stats --no-stream 可以快速查看所有容器的实时资源使用,适合临时排查,不适合持续监控。对于 Prometheus + Grafana 方案,导入 Grafana Dashboard ID 14282(Docker Container & Host Metrics)可以同时展示宿主机和容器指标。

如何监控备份任务是否按时执行(而不仅仅是服务器在不在线)?

使用 Push/Heartbeat 监控,但只能在任务完整成功后发送成功心跳:备份生成、上传、校验任一步失败都必须以非零状态退出,不能由无条件执行的最后一行伪造成功。为任务设置合理宽限期,并另报运行时长、备份时间戳和校验结果。心跳 URL 等同密钥,应存放在受限环境文件;它能证明任务报告过成功,仍不能替代定期恢复演练。

哪吒探针的 Agent 占用多少资源?会影响被监控服务器的性能吗?

哪吒 Agent 非常轻量:内存占用约 5-15MB,CPU 占用通常低于 0.1%(每隔几秒采集一次系统指标),对被监控服务器几乎没有感知到的性能影响。Agent 以二进制程序方式运行(不需要 Docker),通过 systemd 管理,支持开机自启。网络方面:Agent 会持续与面板端建立一条长连接,带宽消耗微乎其微(约每秒几百字节的心跳数据)。与 Prometheus Node Exporter(约 20MB 内存)相比,哪吒 Agent 更轻量,且提供了更友好的多机管理界面。结论:即使是 512MB 内存的低配 VPS,安装哪吒 Agent 也不会有任何明显影响。

Uptime Kuma 的数据存储在哪里?如何备份监控配置?

Uptime Kuma 的完整状态位于挂载的 /app/data,官方当前更建议备份整个本地卷或数据目录;界面导出功能不能视为完整备份。为获得一致副本,应在维护窗口停止容器或使用支持 SQLite 一致性的快照方式,再加密复制到异地。恢复时使用相同受支持版本,在隔离实例还原数据目录,验证登录、监控项、通知配置和一次真实测试告警后再切换;不要在运行中直接打包数据库,也不要把数据目录放到 NFS。

学完监控后,下一步应该怎么进阶?

按本站 30 篇路径,第 20 篇(本篇)→ 第 21 篇(low-code-website-build)→ 第 22 篇(network-performance-and-optimization)是最自然的延伸。关联逻辑:完成了备份(第 19 篇)和监控(本篇),您的服务器基础设施已经相当完善——第 21 篇的 WordPress/Halo 建站可以放心部署,因为有了监控告警和数据备份双重保障;第 22 篇的网络性能优化则解决了另一个常见问题:哪吒探针的流量图显示延迟高或带宽不满,通过 BBR 加速和路由优化来解决。三篇构成"保护→建站→加速"的完整站长成长路径。

监控告警太频繁(告警风暴),如何降低误报率?

先按用户影响定义等级,再处理噪声:对瞬时抖动设置连续失败或持续时间,对同一故障的下游告警做分组和抑制,维护窗口只静默已知变更,并保留恢复通知。CPU 等资源指标应结合持续时间和业务错误率,不能只提高阈值隐藏问题。每条关键告警都要有负责人、可执行说明和去重键;定期测试通知渠道,并对“长时间完全没有任何告警或心跳”单独报警。