使用消费计划的Azure函数触发每日配额超额停止报错排查求助

核心认知纠正 #

消费计划并非无配额限制，默认存在每日执行时间配额（400,000 GB-s）、每日执行次数配额，同时支持手动设置自定义配额；此外区域资源池临时限制也可能间接触发类似报错。

排查方向 #

1. 检查函数应用的自定义配额配置 #

• 进入Azure Portal的目标函数应用，导航至配置 > 常规设置
• 查看「每日使用配额（GB-s）」和「每日执行次数」的数值：
  • 若数值远低于默认的400000 GB-s，说明被手动调整过，是触发停止的直接原因
  • 确认是否有其他管理员修改过该配置

2. 核查当日资源消耗峰值 #

• 进入函数应用的监控 > 指标面板，添加以下指标并筛选20日当天的时间范围：
  • Function Execution Units：统计每日累计消耗的执行单元，查看是否接近或达到配额阈值
  • Function Executions：统计当日执行总次数，确认是否触发次数配额
  • 对比前几日的消耗曲线，看20日是否出现突发暴涨

3. 排查异常执行行为 #

• 进入监控 > 日志，用Kusto查询定位异常函数：

  FunctionAppLogs
  | where TimeGenerated between (datetime(2024-XX-20 00:00:00) .. datetime(2024-XX-20 23:59:59))
  | summarize execCount = count() by FunctionName, ResultType
  | order by execCount desc
  

  重点关注失败执行（ResultType为Failure）次数多的函数，或执行次数远超平日的函数（比如触发器重复触发、恶意请求轰炸）

• 进一步查询函数执行时长，确认是否有执行超时或时长暴增的情况：

  FunctionAppLogs
  | where TimeGenerated between (datetime(2024-XX-20 00:00:00) .. datetime(2024-XX-20 23:59:59))
  | summarize avgDuration = avg(DurationMs), maxDuration = max(DurationMs) by FunctionName
  | order by maxDuration desc
  

  单条执行时长过长会大幅增加执行单元消耗，可能快速触达配额

4. 排查区域级资源限制 #

• 进入Azure Portal的服务健康面板，查看20日当天函数应用所在区域的「Function App Service」是否有服务公告或资源限制通知
• 部分区域可能因资源池临时耗尽，导致函数被限制执行，表现为触发配额报错但自身消耗未达阈值

高效查询建议 #

• 优先核查自定义配额配置，这是最易被忽略的触发点
• 若指标显示消耗接近配额，用以下查询拆分每个函数的执行单元消耗，快速定位大户：

  FunctionAppLogs
  | where TimeGenerated between (datetime(2024-XX-20 00:00:00) .. datetime(2024-XX-20 23:59:59))
  | extend ExecutionUnits = (DurationMs / 1000) * (MemorySize / 1024)
  | summarize totalUnits = sum(ExecutionUnits) by FunctionName
  | order by totalUnits desc
  

• 若自身消耗未达配额，直接查看服务健康的区域状态，确认是否为平台侧限制

内容的提问来源于stack exchange，提问作者S-Wing