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;
Create the function app within an existing resource group, using the ARM template and a parameter file
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:\ home \ LogFiles \ Application \ Functions \ Function \ functionname>)
Here are the logs, straight from 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的连接性有关.
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.
推荐答案
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屋！
