
核心在于覆盖主机、网络、应用和业务层面。主机层建议监控 CPU 使用率、内存 占用、磁盘 I/O 与剩余空间;网络层监控带宽、丢包率与延迟;应用层监控进程健康、响应时间、错误率(4xx/5xx);业务层监控事务量、队列长度与关键业务指标。
可细化为:系统资源(CPU、MEM、IO)、网络(RTT、丢包、连接数)、服务(端口、进程、守护进程)、数据库(查询慢、连接池)、日志(异常关键词、OOM、Crash)、证书(过期)等。
关键指标如 CPU/响应时间采集周期可设为1分钟,日志与事件实时流式传输,历史指标可按 15min/小时聚合存储以降低成本。
设置阈值要结合基线和业务波动。先做 7-14 天基线分析,按平均值与峰值设定预警与严重告警,如 CPU > 80% 持续 5 分钟触发预警,> 90% 持续 10 分钟触发严重告警;磁盘使用率 > 85% 触发预警,> 95% 触发紧急。
对波动大的指标使用动态阈值或基于模型的异常检测(比如 Prometheus + alertmanager 的基于预测的告警),并结合增量/斜率告警(例如短时间内错误率增长 300%)。
使用抖动过滤(例如持续 N 个周期)、抑制(silence)与分组告警,把相关事件合并为一条告警以减少噪音。
优先选择多通道策略:邮件和短信用于高可用团队与运维负责人,企业即时通讯(如 Slack、Microsoft Teams、LINE)用于运维与开发协同,Webhook 用于自动触发工单或扩容脚本。对泰国地区,可额外接入本地 SMS/LINE 提示以提高到达率。
按 Severity 级别划分通知:P3(信息)仅写入日志;P2(警告)发至运维群;P1(严重)同时短信+电话+页面呼叫(on-call)。并确保告警中包含必要的上下文(主机ID、时间、指标值、最近日志摘录和应对步骤)。
配置 Webhook 与 ITSM(如 Jira/ServiceNow)集成,实现告警自动创建工单、分配并追踪处理流程,提高响应效率。
采取多层策略:一是设置稳健的抖动策略(例如连续 3 次周期满足条件再告警);二是利用告警去重与聚合,把同一根因触发的多项告警合并;三是使用抑制规则(在已知维护窗口或自动扩容过程中静默相关告警)。
为常见告警编写 runbook,让一线通过脚本或控制台执行标准化恢复步骤;并推广自动恢复(如故障自动重启、扩容或回滚)以减少人工干预。
建立告警确认、处理、关闭流程并记录原因与根因分析(RCA),持续优化阈值与规则以降低噪声。
可优先考虑云厂商自带的监控平台(若有)以便与实例、镜像、快照、网络资源无缝集成;再结合开源/第三方工具如 Prometheus(指标采集)、Alertmanager(告警路由)、Grafana(可视化)、ELK/EFK(日志),或商业方案如 Datadog、New Relic,并确保网络和数据主权合规。
1)采用统一的监控 Agent 与标准化指标命名;2)建立模板化告警规则并按业务分组;3)配置可复用的 Grafana 仪表盘与告警面板;4)定期演练告警响应与故障恢复。
监控系统本身要做好访问控制与审计,数据保留与采样策略应兼顾成本与可追溯性,定期清理无用指标与历史日志以节省费用。