azure - Microsoft AZURE blob 触发功能间歇性工作

标签 azure azure-functions

我们的 Blob 触发功能遇到了问题。 该函数是用 JavaScript 编写的。 我们很难为其制定自动化部署流程。 以下是我们遵循的步骤。

  1. 使用 ARM 模板和参数文件在现有资源组中创建函数应用 New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateFile $templateFilePath -TemplateParameterFile $armParametersFilePath;

  2. 通过 Kudu api 部署函数代码 Invoke-RestMethod -Uri“$apiUrl”-Method Put -InFile“$functionCodeArchivePath”-Credential $credentials -DisableKeepAlive -UserAgent“powershell/1.0”-TimeoutSec 600

  3. 通过 kudu api 运行 npm install 命令 Invoke-RestMethod -Uri“$apiCommandUrl”-Method Post -Body $json -DisableKeepAlive -ContentType“application/json”-Credential $credentials -UserAgent“powershell/1.0”-TimeoutSec 1200

在最后一步中 - 获取 Kudu 上的依赖项(npm install)的命令超时,这似乎是 known issue .

为了克服这个问题,我们使用 WebPack 将所有依赖项打包到一个 JavaScript 文件中,如下 this approach .

现在部署速度更快,但该功能似乎没有正确执行。

当我们将文件放入 blob 存储帐户时,函数会被触发,该函数似乎并不总是记录执行跟踪。 有些运行具有完整日志,有些运行仅包含功能启动,而没有任何自定义日志语句。

这里是直接来自 Kudu 的日志 (D:\home\LogFiles\Application\Functions\Function\functionname>)

2017-03-03T11:24:33.835 Function started (Id=77b5b022-eee0-45e0-8e14-15e89de59835)
2017-03-03T11:24:35.167 JavaScript blob trigger function started with blob:
2017-03-03T11:24:35.167 Name: _1486988111937 
 Blob Size: 8926 Bytes
2017-03-03T11:24:35.167 Extracting file
2017-03-03T11:24:35.167 JavaScript blob trigger function processed blob 
 Name: _1486988111937 
 Blob Size: 8926 Bytes
2017-03-03T11:24:35.183 Function completed (Success, Id=77b5b022-eee0-45e0-8e14-15e89de59835)
2017-03-03T11:24:35.292 { Error: [** SENSITIVE ERROR MESSAGE, INTERNAL TO FUNCTION, REMOVED **] }
2017-03-03T11:28:34.929 Function started (Id=8bd96186-50bc-43b0-916c-fefe4bd0cf51)
2017-03-03T11:38:18.302 Function started (Id=7967cc93-73cf-4acf-8428-20b0c70bbac9)
2017-03-03T11:39:32.235 Function started (Id=a0abb823-9497-429d-b477-4f7a9421132e)
2017-03-03T11:49:25.164 Function started (Id=ab16b1d9-114c-4718-aab2-ffc426cfbc98)
2017-03-03T11:53:51.172 Function started (Id=87ed29bc-122f-46d2-a658-d933330580c9)
2017-03-03T11:56:06.512 Function started (Id=23f8ee3f-cda0-45a3-8dd0-4babe9e45e4e)
2017-03-03T12:02:58.886 Function started (Id=c7ef7ad5-62b8-4b43-a043-bc394d9b02f5)

PS:我们的函数代码是获取 blob(一个压缩文件),将其解压缩并对压缩文件夹内的每个文件进行 API 调用。日志中标有 [** SENSITIVE ERROR MESSAGE, INTERNAL TO FUNCTION, REMOVED **] 的错误与我们 API 的连接有关。

最佳答案

看起来 Blob 触发不太可靠,至少根据此页面:How to use Azure blob storage with the WebJobs SDK

The WebJobs SDK scans log files to watch for new or changed blobs. This process is not real-time; a function might not get triggered until several minutes or longer after the blob is created. In addition, storage logs are created on a "best efforts" basis; there is no guarantee that all events will be captured. Under some conditions, logs might be missed. If the speed and reliability limitations of blob triggers are not acceptable for your application, the recommended method is to create a queue message when you create the blob, and use the QueueTrigger attribute instead of the BlobTrigger attribute on the function that processes the blob.

您可能应该更改逻辑并为放入 Blob 存储中的每个文件创建一个队列消息

关于azure - Microsoft AZURE blob 触发功能间歇性工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42584925/

相关文章:

azure - 使用 ARM 模板部署动态启用/禁用的 Azure Function

Azure 应用程序洞察

azure - KQL 查询以获取在 azure 中运行的 Aks 集群的节点数

git - 从 Azure 中提取 Orchard 实例的更新

azure - "The binding type(s) ' queueTrigger ' are not registered"错误随机出现。

azure - Azure 函数应用部署中心的 ftps 凭据选项卡去了哪里?

Azure 数据工厂的 Python 自定义事件

azure - 使用 WindowsAzure.ServiceBus 2.8.2 时,NServiceBus 5.2.14 不支持 HTTPS

azure - 与旧库相比,新库的 Cosmos DB 速度非常慢

c# - 为 Azure Functions 创建测试项目