1) 明确目标:保证服务可用性、响应时间和带宽稳定性;
2) 最小化误报:设置合理阈值与抖动窗口以避免震荡报警;
3) 可扩展性:监控方案应支持多台VPS、跨机房扩展;
4) 多维度覆盖:CPU、内存、磁盘、网络、IO、连接数与业务指标;
5) 可落地的自动化:告警自动化、自动恢复脚本与故障工单接入。
1) CPU使用率:短期峰值告警85%(持续2分钟),严重告警95%(持续1分钟);
2) 内存使用率:使用率90%触发告警,swap使用>30%触发紧急处理;
3) 磁盘空间:剩余空间<15%触发告警,inode使用>80%触发告警;
4) IO等待(iowait):iowait>20%持续1分钟触发告警;
5) 网络丢包/延迟:丢包>1%且持续60s或P95延迟>200ms触发告警。
1) 数据采集:在VPS上部署node_exporter或Telegraf采集主机指标;
2) 存储与查询:Prometheus做时序存储(建议保留15天细粒度数据);
3) 可视化:Grafana构建仪表盘展示CPU、内存、磁盘、网络及业务QPS;
4) 黑盒监控:blackbox_exporter做ICMP/TCP/HTTP可用性与延迟检测;
5) 告警与通知:Alertmanager做路由与抖动控制,集成Slack/Telegram/短信/工单系统。
1) 聚合告警:对同一主机相同类告警做grouping,比如5分钟内合并相同实例告警;
2) 抖动控制:Prometheus规则加上for=2m避免瞬时峰值告警;示例:cpu_usage > 0.85 for 2m;
3) 分级策略:INFO->WARN->CRITICAL,根据持续时间与影响范围上报不同通道;
4) 自动化响应:CPU持续95%触发脚本重启特定进程并回写工单;
5) 演练与回放:定期进行告警演练并对告警进行后续复盘。
1) 路由规则:按业务分组(web、db、cache)送到不同运维组;
2) 抑制(inhibit):当主机网络不可达时抑制业务级别冗余告警;
3) 通知分级:CRITICAL发短信+电话,WARN发Slack/邮件;
4) 静默窗口:夜间非紧急告警进入静默或仅短信通知值班;
5) 去重与限频:同一告警1小时内限频通知3次,避免通知疲劳。
1) 边界防护:使用CDN(如Cloudflare)做七层缓存与速率限制,过滤大流量;
2) BGP/带宽策略:选择提供BGP Anycast或大带宽清洗的越南机房;
3) 内核与连接数调优:net.core.somaxconn、tcp_tw_reuse、conntrack最大值等调优;
4) 防暴力与登录防护:部署fail2ban、ssh限速、二次认证;
5) 流量监控:设置Netflow/sFlow采样,异常流量自动触发黑洞或清洗服务。
1) 案例背景:某SaaS在越南胡志明市机房部署,用户反馈间歇性延迟与掉线;
2) 初始配置:VPS配置为4 vCPU、8GB RAM、160GB NVMe、1Gbps不计流量,系统Ubuntu 22.04;
3) 采取措施:部署Prometheus+Node Exporter+Blackbox,建Grafana仪表盘并设置Alertmanager路由,接入Cloudflare并启用速率限制;
4) 结果对比(下表展示前后关键指标);
5) 结论:通过网络优化、告警抖动控制与CDN引流,Uptime和延迟显著改善,长期运行稳定。
| 项 | 部署前 | 部署后 |
|---|---|---|
| 平均CPU使用 | 65% | 30% |
| 平均延迟(P95) | 280ms | 120ms |
| 丢包率 | 2.4% | 0.1% |
| 月度可用率 | 99.20% | 99.99% |