云端应用监控指标与告警规则设计，关键不是把所有曲线都设成告警，而是让告警对应可确认的故障和行动。比如，CPU短时升高未必影响用户；接口错误率持续上升，则可能需要立即排查。下面按五类场景对照指标、阈值和适用条件。文中的数值是初始参考，需结合服务基线、流量和服务目标调整。
先定规则：阈值要同时回答三个问题
每条规则至少写清楚监控对象、触发条件和处理级别。单次越线容易受抖动影响，可设置持续时间；低流量服务则要补充最小请求数，避免几次失败就触发高严重度告警。紧急告警应对应用户影响或数据风险，资源趋势、容量预警通常可以先发工单。
五项关键指标，按业务场景搭配
1. 可用性：服务是否还能正常响应
适用于网站、API和后台任务入口。可监控健康检查成功率、请求成功率或可用性目标。若连续多个检查周期失败，或关键入口不可访问，可设为高优先级；单个实例短暂异常但负载均衡仍能承接流量，宜先告警观察，避免把实例故障误报成全站故障。健康检查应验证实际依赖，避免只检查进程是否存活。
2. 延迟：用户等待时间是否变长
关注请求延迟的P95或P99，而不只看平均值；少数慢请求可能被平均数掩盖。对交互式接口，可先以P95超过自身正常基线约1.5至2倍、持续5至10分钟作为排查起点；若已有服务目标，应按目标设阈值。后台批处理和交互接口的可接受延迟不同，不能共用一条线。
3. 错误率：失败比例是否持续扩大
监控HTTP 5xx比例、任务失败比例，或数据库请求错误。对有稳定流量的服务，可将5分钟窗口内错误率超过约1%作为初步观察线，持续10分钟后升级；关键交易流程可设得更严格。低流量时应同时设置失败次数门槛，或拉长窗口，否则一个请求失败就可能令比例大幅波动。4xx通常代表客户端请求问题，不宜与服务端错误一概而论。
4. 资源饱和度：容量是否快要耗尽
CPU、内存、磁盘空间和连接池用于判断资源压力。以PostgreSQL为例，可观察连接数占最大连接数比例、查询等待和磁盘余量；Redis则可关注内存使用与淘汰情况。CPU使用率超过约80%持续10至15分钟，适合作为初始预警，而非所有场景都该立刻叫醒值班人员。磁盘余量低于约15%可通知维护人员；具体边界要考虑增长速度、扩容耗时和保留策略。
5. 业务流程：技术正常是否等于事情办成
HTTP服务可能正常，但注册、下单、文件上传或定时处理仍可能失败。应选一个能代表用户结果的指标，如流程完成数、成功率、队列积压量，并与请求量或历史同时间段比较。对有明显日周期的业务，不宜用全天固定数量设阈值；可先检查连续多个采样窗口的变化，再对照上游流量和部署记录。云端应用监控指标与告警规则设计，应把这类结果指标与错误率、延迟互相验证。
把阈值变成可执行的告警
列出关键用户流程和依赖组件，标明故障影响范围。
为每个流程选可用性、延迟、错误率或业务结果指标，并确定统计窗口。
用近期正常数据建立基线；先区分工作日、低流量时段和批处理窗口。
按影响设置级别：用户广泛受阻优先通知值班人员，容量趋势或单实例异常可先创建工单。
回看误报和漏报，调整持续时间、最小请求数及抑制条件；部署期间也应保留必要告警。
如果使用Prometheus与Alertmanager，可以把指标查询、持续时间和通知路由分开配置，并按服务或严重级别分组，避免同一故障产生大量重复通知。无论采用何种平台，每条告警都应附上指标图表、影响对象和建议检查项。
常见问题
阈值应该固定还是按基线变化？
资源容量和明确的服务目标适合固定边界；流量、延迟等波动较大的指标，可结合历史基线，但需设置上下限，避免基线异常时规则失效。
为什么指标越多，告警反而不好用？
没有明确处理动作的告警会增加噪声。优先告警用户影响、数据风险和即将耗尽的资源，其余指标用于仪表盘或趋势工单。
阈值上线后多久复查？
可在首次运行的一至两周内集中检查误报、漏报和通知负担；之后遇到流量模式、架构或服务目标变化时再复核。云端应用监控指标与告警规则设计应随业务变化更新，而不是设定一次便长期不动。