
监控需求通常围绕系统资源、网络质量和应用可用性三类展开。对于香港节点,网络延迟和丢包率尤为重要,因为跨境访问敏感度高。核心指标建议包括:
系统资源:CPU利用率(1m/5m/15m)、内存使用与Swap、磁盘使用(容量与inode)、磁盘IO(iowait、await)等。
网络与连接:带宽上下行利用率、带宽突发、TCP连接数、端口可达性、延迟与丢包(ping/TCP/HTTP探测)。
应用层:服务响应时间(p95/p99)、请求成功率(4xx/5xx比率)、数据库慢查询、连接池消耗、队列长度等。
香港VPS多按流量计费,监控采样与指标保留要平衡成本与可追溯性。短期高频(10s-1m)用于告警与实时面板,长期可降采样保存用于趋势分析。
推荐的工具与组合如下,按适用场景区分:
优点:适合容器化与分布式环境,查询灵活(PromQL)、与Grafana可视化强、生态丰富(exporters)。
缺点:对长期存储需额外组件(Thanos/Remote Write),对初学者配置略复杂。
优点:功能完整、模板丰富、支持被动与主动检查、报警策略直观。适合运维团队对主机级指标的全面监控。
缺点:大规模监控时性能与扩展性需注意。
优点:部署简单、实时度高、适合快速诊断单机性能问题。
缺点:不适合长期指标存储与复杂告警逻辑。
优点:部署门槛低,集成丰富,告警和报表功能强,适合不想运维监控平台的团队。
缺点:成本高,尤其是海外流量与采集量大时。
Observability:Elastic Stack(ELK)、Grafana Cloud、Prometheus 生态(Alertmanager、Pushgateway)、以及基于云厂商的监控(阿里云/腾讯云/Huawei Cloud的监控)。
阈值要基于业务特性、容量规划与历史基线调整。下面给出通用的参考阈值(可按业务级别调节):
CPU:单机平均CPU使用率 > 85% 核心数 * 2 持续5分钟。
内存:使用率 > 90%20% 报警。
磁盘:容量使用 > 80% 预警,> 90% 严重告警;inode使用 > 80% 预警。
磁盘IO:iowait > 30% 或 avg. await > 50ms(取决于磁盘类型,SSD阈值应更低)。
带宽:链路利用率 > 80%(5分钟均值)预警,> 95% 严重告警。
延迟:对近地区(CN→HK)常见阈值 < 80ms 为正常;若平均 RTT > 150ms 且持续3次采样,触发告警。
丢包:丢包率 > 1%(5分钟)触发一级告警,> 3% 需快速排查。
HTTP错误率(5xx)> 1%(1分钟)或错误率较基线上升 >200% 报警;请求延迟p95 > 1s(或业务可接受值)。
数据库连接数 > 80% 最大连接数,慢查询比例 > 1% 且单条慢查询 > 5s。
建议按影响度分级:信息(info)-> 警告(warning)-> 严重(critical)。例如CPU 85%-90%为warning,>90%为critical,并结合持续时间与业务影响作为触发条件。
告警策略应讲究可靠性与可操作性,避免重复无意义的报警:
设置阈值同时要求持续一段时间(如连续3次采样或5分钟内),并对同一问题做聚合(如多个网卡出现相同丢包只触发一次告警)。
在发布、扩容等已知事件期间启用抑制(maintenance window),并用临时抑制避免变更引起的噪音。
使用告警去重(Alertmanager、Zabbix的event correlation)把同一根因的多项告警合并,防止告警风暴。
不同级别走不同通道:warning -> 邮件/企业微信群;critical -> 电话/SMS/语音或On-Call推送。并配置自动升级策略(未确认/未回复升级)。
每次告警都应记录处理流程与根因,形成知识库,减少重复误报。
部署与运维要兼顾监控覆盖率与成本控制,实用建议如下:
小团队或单机场景:可先部署Netdata或轻量Prometheus+Node Exporter做实时诊断;
中大型或容器化:建议Prometheus+Grafana,加Alertmanager和长期存储(Thanos/Loki/远程写);若不想自建,选用Datadog或Grafana Cloud。
香港VPS流量敏感,尽量采用采样、压缩与批量发送Telemetry;使用Pushgateway或边缘代理汇总Agent数据,减少频繁的小包。
合理设置采样频率(关键指标短周期,次要指标可降频),并对历史数据进行分级存储(高分辨率30天,低分辨率长期存储)。使用告警抑制减少无效告警导致的人力成本。
建立SLA/SLO,明确告警响应时间与责任人;定期回顾阈值与误报,基于实际数据调整。利用监控Runbook化常见问题的排查步骤。