Microsoft AZURE blob 触发功能间歇性工作 [英] Microsoft AZURE blob triggered function working intermittently
问题描述
我们的 Blob 触发函数遇到了问题.该函数是用javascript编写的.我们很难为其实施自动化部署流程.以下是我们遵循的步骤.
We are running into issues with our Blob triggered function. The function is written in javascript. We had a hard time putting an automated deployment process for it in place. Here are the steps we followed.
使用 ARM 模板和参数文件在现有资源组中创建函数应用
New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateFile $templateFilePath -TemplateParameterFile $armParametersFilePath;
通过Kudu api部署功能代码Invoke-RestMethod -Uri "$apiUrl" -Method Put -InFile "$functionCodeArchivePath" -Credential $credentials -DisableKeepAlive -UserAgent "powershell/1.0" -TimeoutSec 600
Deploy the function code through the Kudu api
Invoke-RestMethod -Uri "$apiUrl" -Method Put -InFile "$functionCodeArchivePath" -Credential $credentials -DisableKeepAlive -UserAgent "powershell/1.0" -TimeoutSec 600
通过 kudu api 运行 npm install 命令Invoke-RestMethod -Uri "$apiCommandUrl" -Method Post -Body $json -DisableKeepAlive -ContentType "application/json" -Credential $credentials -UserAgent "powershell/1.0" -TimeoutSec 1200
Run the npm install command through the kudu api
Invoke-RestMethod -Uri "$apiCommandUrl" -Method Post -Body $json -DisableKeepAlive -ContentType "application/json" -Credential $credentials -UserAgent "powershell/1.0" -TimeoutSec 1200
在最后一步 - 在 Kudu 上获取依赖项 (npm install) 的命令超时，这似乎是 已知问题.
In the last step - the command to get the dependencies (npm install) on Kudu times out this seems to be a known issue.
为了克服这个问题，我们使用 WebPack 将所有依赖项打包到一个 JavaScript 文件中，遵循 这种方法.
To overcome this, we went for using WebPack to package all the dependencies in one JavaScript file, following this approach.
现在部署速度更快了，但功能似乎没有正确执行.
当我们将一个文件放入我们的 blob 存储帐户时，该函数被触发，该函数似乎并不总是记录执行跟踪.有些运行包含完整的日志，有些运行只包含 Function started 而没有任何自定义日志语句.
When we drop a file into our blob storage account the function is triggered from , the function does not seem to log the execution trace always.
There are runs which have the full logs, and there are runs that only have Function started in them without having any custom log statements.
这里是直接来自 Kudu 的日志 (D:homeLogFilesApplicationFunctionsFunctionfunctionname>)
Here are the logs, straight from Kudu (D:homeLogFilesApplicationFunctionsFunctionfunctionname>)
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 连接有关.
PS: Our function code is getting the blob, a zipped file, unzipping it and making API calls for each of the files inside the zipped folder. The error marked with [** SENSITIVE ERROR MESSAGE, INTERNAL TO FUNCTION, REMOVED **] in the log is related to connectivity to our API.
推荐答案
看起来 Blob 触发不是那么可靠，至少根据这个页面:如何将 Azure blob 存储与 WebJobs SDK 一起使用
It looks like that Blob triggering is not that reliable, at least according to this page: How to use Azure blob storage with the WebJobs SDK
WebJobs SDK 扫描日志文件以监视新的或更改的 blob.这个过程不是实时的；在创建 blob 几分钟或更长时间后，函数可能不会被触发.此外，存储日志是在尽力而为"的基础上创建的；无法保证所有事件都会被捕获.在某些情况下，可能会丢失日志.如果您的应用程序无法接受 Blob 触发器的速度和可靠性限制，推荐的方法是在创建 Blob 时创建队列消息，并使用 QueueTrigger 属性而不是 BlobTrigger 上的属性处理 blob 的函数.
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 存储中的每个文件创建一个队列消息
You should probably change the logic and create a queue message for each file that you put in Blob storage
这篇关于Microsoft AZURE blob 触发功能间歇性工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
