Azure自动修复触发器含义解析：requests与slowRequests区别及示例问询

一、各触发器参数具体含义 #

• privateBytesInKB：设置应用进程私有内存的触发阈值（单位：KB），当进程占用的私有内存超过该值时触发自动修复（如重启应用池）。设为0表示禁用该触发器。
• requests：基于请求总量的触发规则，指定时间区间内请求数达标时触发修复
  • count：触发修复所需的请求总数，设为0则禁用该规则
  • timeInterval：统计请求数的时间窗口，格式为hh:mm:ss（例如00:05:00代表5分钟）
• slowRequests：基于慢请求数量的触发规则，指定时间区间内，耗时超过阈值的请求数达标时触发修复
  • count：触发修复所需的慢请求数量，设为0则禁用
  • timeInterval：统计慢请求的时间窗口，格式为hh:mm:ss
  • timeTaken：定义“慢请求”的耗时阈值，格式为hh:mm:ss（例如00:00:10代表10秒）
• statusCodes：基于HTTP状态码的触发规则，支持配置多条规则，当指定时间区间内特定状态码的请求数达标时触发修复
  • count：触发修复所需的对应状态码请求数量，设为0则禁用
  • status：目标HTTP状态码（如500、404）
  • subStatus：HTTP子状态码（如500.19），设为0表示不限制子状态码
  • timeInterval：统计时间窗口，格式为hh:mm:ss
  • win32Status：Windows系统级错误码，设为0表示不限制

二、requests 与 slowRequests 的核心区别 #

• 触发逻辑不同
  • requests：仅统计指定时间内的请求总数量，不关心单个请求的耗时，只要总量达标就触发
  • slowRequests：仅统计指定时间内耗时超过阈值的请求数量，请求总数不影响结果，只要慢请求数量达标就触发
• 适用场景不同
  • requests：适合应对突发流量激增导致的服务负载过高（如秒杀活动期间请求暴增拖垮应用）
  • slowRequests：适合排查处理性能瓶颈问题（如数据库查询超时、接口响应慢导致的大量慢请求）

三、触发器配置示例 #

1. requests 参数示例：应对突发流量 #

配置为5分钟内请求数达到1000次时触发自动修复：

{
  "privateBytesInKB": 0,
  "requests": {
    "count": 1000,
    "timeInterval": "00:05:00"
  },
  "slowRequests": {
    "count": 0,
    "timeInterval": "",
    "timeTaken": ""
  },
  "statusCodes": []
}

2. slowRequests 参数示例：处理慢请求 #

配置为10分钟内出现50个耗时超过15秒的请求时触发修复：

{
  "privateBytesInKB": 0,
  "requests": {
    "count": 0,
    "timeInterval": ""
  },
  "slowRequests": {
    "count": 50,
    "timeInterval": "00:10:00",
    "timeTaken": "00:00:15"
  },
  "statusCodes": []
}

3. 多触发器组合示例 #

同时开启内存阈值、请求数和500错误码触发规则：

{
  "privateBytesInKB": 102400, // 进程内存超过100MB时触发
  "requests": {
    "count": 800,
    "timeInterval": "00:03:00" // 3分钟内请求数达800次触发
  },
  "slowRequests": {
    "count": 0,
    "timeInterval": "",
    "timeTaken": ""
  },
  "statusCodes": [
    {
      "count": 20,
      "status": 500,
      "subStatus": 0,
      "timeInterval": "00:05:00", // 5分钟内出现20个500错误触发
      "win32Status": 0
    }
  ]
}

内容的提问来源于stack exchange，提问作者VariableTao