由队列触发的Azure函数定期超时

ddrv8njm  于 2023-06-24  发布在  其他
关注(0)|答案(1)|浏览(95)

我有一个由队列触发的Linux Azure函数。函数试图处理的大多数消息都在“poison”队列中结束,我能看到的唯一日志表明它超时了。

2023-06-12 20:00:14.132  Executing 'Functions.Drone' (Reason='New queue message detected on 'drone-input-queue'.', Id=6e66d069-0b09-4966-92dd-d63a8f9aa3fc)  Information
2023-06-12 20:00:14.133  Trigger Details: MessageId: 3c54e04a-3d96-4ab9-ab69-3101f77a16f1, DequeueCount: 1, InsertionTime: 2023-06-12T20:00:10.000+00:00  Information
2023-06-12 20:10:14.133  Timeout value of 00:10:00 exceeded by function 'Functions.Drone' (Id: '6e66d069-0b09-4966-92dd-d63a8f9aa3fc'). Initiating cancellation.  Error
2023-06-12 20:10:14.133  Executed '{functionName}' ({status}, Id={invocationId}, Duration={executionDuration}ms)  Error
2023-06-12 20:10:14.133  Executed 'Functions.Drone' (Failed, Id=6e66d069-0b09-4966-92dd-d63a8f9aa3fc, Duration=600000ms)  Error
2023-06-12 20:10:14.133  Error

潜在相关信息:

  • 功能应用程序正在使用消耗计划。我知道可能会有冷启动,但我看到这种情况发生,像,90%的时间,即使每隔几分钟就有消息。
  • 功能应用程序和队列使用ARM模板设置。该函数稍后从存档中部署。
  • 函数使用Linux作为操作系统类型,并运行Java代码。
  • 我偶尔会看到正确的执行,所以“AzureWebJobsStorage”、“STORAGE_QUEUE_CONNECTION_STRING”和“WEBSITE_CONTENTAZUREFILECONNECTIONSTRING”都应该正确设置。
  • 我已经对host.json和function.json进行了两次和三次检查,但在这里,供参考:host.json
{
  "version": "2.0",
  "functionTimeout": "00:10:00",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[2.*, 3.0.0)"
  },
  "extensions": {
    "queues": {
      "maxPollingInterval": "00:00:02",
      "visibilityTimeout" : "00:00:30",
      "batchSize": 16,
      "maxDequeueCount": 3,
      "newBatchThreshold": 8
    }
  }
}

function.json

{
  "scriptFile" : "../my.package.drone.jar",
  "entryPoint" : "my.package.Drone.run",
  "bindings": [
    {
      "name": "message",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "catapult-drone-input-queue"
    },
    {
      "name": "output",
      "type": "queue",
      "direction": "out",
      "queueName": "catapult-drone-output-queue"
    }
  ]
}
  • 我最初使用过时版本的CLI部署该函数。虽然更新修复了一些问题,但它没有修复这一个。下面是版本信息。
# az version
{
  "azure-cli": "2.39.0",
  "azure-cli-core": "2.39.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {}
}
# func
...
Azure Functions Core Tools
Core Tools Version:       3.0.4899 Commit hash: N/A  (64-bit)
Function Runtime Version: 3.17.0.0
...

我怀疑这可能与扩展配置有关,但我不知道如何配置它。任何建议将不胜感激。
下面是一段入口点代码:

@FunctionName("Drone")
public void run(@QueueTrigger(name = "message", queueName = "drone-input-queue") String message, 
                @QueueOutput(name = "output", queueName = "drone-output-queue") OutputBinding<String> output,
                final ExecutionContext context) {
    String id = UUID.randomUUID().toString();
    logger.setContext(context); //custom tool for logging to context logger and/or blob
    logger.info("["+id+"] Start");
    encryption = initializeInFlightEncryptionClient(logger);
    logger.info("["+id+"] encryption initialized");
    jsonSigner = initializeJsonSigningUtility(logger);
    logger.info("["+id+"] jsonSigner initialized");
    try {
        // ... logic to handle message ...
    }
    catch(Exception e) {
        logger.severe("ERROR: "+e.getMessage(), e);
    }
    finally {
        logger.closeLogFile();
    }
}

我忘了提到我在这部分代码中有相当广泛的日志记录,所以我知道,至少,它不会超过'logger. setContext',它只设置一个私有变量context.getLogger()。这就是为什么我之前没有费心分享代码。
此外,我还看到过仅需30秒处理的消息导致此超时。如果我一次发送10个,第一个可能会得到正确和快速的处理,但接下来的9个往往都有这个超时。这就是为什么我怀疑配置有问题。
P.S.这是功能App中唯一的功能。

nsc4cvqm

nsc4cvqm1#

您的功能通话时间超过10分钟。它在本地完成需要多长时间?在本地运行时,可以将超时设置为更大的值。
如果时间太长,你的选择是:

  • 应用程序计划(无限制)
  • 把它分成小块
  • 使用持久功能

相关问题