We have started to use the Queue binding in our Azure functions for longer-running tasks such as sending bulk e-mails and "clean-up" tasks for CosmosDB. We develop locally with the Functions emulator then commit into VSTS/Azure DevOps which then auto-deploys into our Function App.
It seems as though pretty quickly we're going to have multiple Functions (two local emulators and one cloud function) all listening to the same queue. We tried disabling locally and renaming locally, but these all seem like awkward workarounds that require too much manual work and have the possibility to push the wrong queue name forward into VSTS.
How do we configure the queue name in the function.json to read an environment variable? The connection setting in the binding takes the name of an environment variable, but the queue setting wants a string.
{
"disabled": false,
"bindings": [
{
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in",
"queueName": "emailer",
"connection": "STORAGE_CONNECTION_STRING"
}
]
}
Just wrap variable name with % and function can read its value from Application settings on portal and Values in local.settings.json locally.
"queueName": "%myqueue%"
connection property of triggers and bindings is a special case and automatically resolves values as app settings, without percent signs.
See Binding expressions - app settings.
Related
We have an Azure function v3 running Node, consumption plan, with an input trigger connected to a cosmos database. The function.json looks like this:
{
"disabled": false,
"bindings": [
{
"type": "cosmosDBTrigger",
"name": "productDocuments",
"collectionName": "products",
"direction": "in",
"connectionStringSetting": "DB_CONNECTION_STRING",
"databaseName": "product-management",
"createLeaseCollectionIfNotExists": true,
"maxItemsPerInvocation": 1
},
{
"name": "productDocument",
"type": "cosmosDB",
"databaseName": "product-management",
"collectionName": "products",
"createIfNotExists": true,
"connectionStringSetting": "_DB_CONNECTION_STRING",
"direction": "out"
}
],
"scriptFile": "dist/nameOfFunction.js"
}
But this trigger is working really, really slow and unreliable. If we add an item to the DB it sometimes triggers straight away, sometimes it seems to take hours and sometimes not at all. I am manually monitoring the cosmos db so I can see that items are added.
I am looking at this page, and most of the time nothing happens. I don't know how else to debug this
Should it really take hours for an invocation to show up here? Or is it the trigger that's unreliable?
General guidance is in this doc: https://learn.microsoft.com/azure/cosmos-db/troubleshoot-changefeed-functions#my-changes-take-too-long-to-be-received
What happens on Consumption Plan is that, after a period of inactivity, instances are deprovisioned. When a new instance is provisioned, it hits a cold start.
The key part here is that, when your instances are deprovisioned, they are not checking the Change Feed for events, so how does Functions know when to "wake them up"?
There is a periodic check done by an external component that checks to see if there are new changes, if there are new, then it would provision new instances of your Function to start consuming them.
This external component in your case, could be having an issue or delays in this checks.
If you have no Function logs for an hour even though you are making changes to the monitored collection, I would try to contact Azure Support to understand why is your Function not "waking up".
One of the known issues I've heard about was related to where the Cosmos DB Connection Strings were stored. Apparently this component at some point (maybe it's already fixed) had a problem where it could not access the Connection String if it was saved in "Connection Strings" section of the Function configuration, but was looking for it only on the "App Settings". In this cases, it could not wake up the Function and the Function only woke up if someone opened it on the Azure Portal. My recommendation would be to check where are you storing your connection string and see if you can move it to "App Settings" and see how it behaves.
Our problem with this was that we had two separate functions that both had a CosmosDBTrigger on the same collectionm but used the same lease, and apparently you can't do that. So it was solved by setting two separate leases (we used the leaseCollectionPrefix in the function.json.)
I have written a blob-triggered function that uploads data on a CosmosDB database using the Gremlin API, using Azure Functions version 2.0. Whenever the function is triggered, it is going to read the blob, extract relevant information, and then queries the database to upload the data on it.
However, when all files are uploaded on the blob storage at the same time, the Function is going to process all files at the same time, which results in too many requests for the database to handle. To avoid this, I ensured that the Azure Function would only process one file at a time, by setting the batchSize to 1 in the host.json file :
{
"extensions": {
"queues": {
"batchSize": 1,
"maxDequeueCount": 1,
"newBatchThreshold": 0
}
},
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
}
},
"version": "2.0"
}
This worked perfectly fine for 20 files at a time.
Now, we are trying to process 300 files at a time, and this feature doesn't seem to work anymore, the Function processes all the files at the same time again, which results in the database not being able to handle all the requests.
What am I missing here ? Is there some scaling issue I'm not aware of ?
From here:
If you want to avoid parallel execution for messages received on one queue, you can set batchSize to 1. However, this setting eliminates concurrency as long as your function app runs only on a single virtual machine (VM). If the function app scales out to multiple VMs, each VM could run one instance of each queue-triggered function.
You need to combine this with the app setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT when you run in Consumption plan.
Or, according to the docs, the better way would be through the Function property functionAppScaleLimit: https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling#limit-scale-out
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT would work of course.
You can also scale to multiple Function App instances within one Host then you can have less hosts and more FUNCTIONS_WORKER_PROCESS_COUNT per host. Cost implications would depend on your plan.
Note that all workers within a Host would share resources, so this is recommended for more IO bound workload.
I am using a Function app with cosmos DB trigger, when running locally, the behavior is very strange as I stop receiving events randomly, like if the connection to the Lease collection drops. I am getting an error message that says a read operation fails to Blob storage, but not sure if this is related. Here's the error:
There was an error performing a read operation on the Blob Storage Secret Repository.
Please ensure the 'AzureWebJobsStorage' connection string is valid
I am running the function app with this code: func host start --cors * --verbose
And here's the CosmosDBOptions object I can see in the console:
[2021-02-09T16:17:58.305Z] CosmosDBOptions
[2021-02-09T16:17:58.307Z] {
[2021-02-09T16:17:58.307Z] "ConnectionMode": null,
[2021-02-09T16:17:58.308Z] "Protocol": null,
[2021-02-09T16:17:58.309Z] "LeaseOptions": {
[2021-02-09T16:17:58.310Z] "CheckpointFrequency": {
[2021-02-09T16:17:58.310Z] "ExplicitCheckpoint": false,
[2021-02-09T16:17:58.311Z] "ProcessedDocumentCount": null,
[2021-02-09T16:17:58.311Z] "TimeInterval": null
[2021-02-09T16:17:58.312Z] },
[2021-02-09T16:17:58.313Z] "FeedPollDelay": "00:00:05",
[2021-02-09T16:17:58.313Z] "IsAutoCheckpointEnabled": true,
[2021-02-09T16:17:58.314Z] "LeaseAcquireInterval": "00:00:13",
[2021-02-09T16:17:58.314Z] "LeaseExpirationInterval": "00:01:00",
[2021-02-09T16:17:58.315Z] "LeasePrefix": null,
[2021-02-09T16:17:58.316Z] "LeaseRenewInterval": "00:00:17"
[2021-02-09T16:17:58.316Z] }
[2021-02-09T16:17:58.323Z] }
and my host.json file:
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[1.*, 2.0.0)"
}
}
Finally, that issue started since I added a shared folder, not sure if it's related but it's really annoying, deleting leases collection solves temporary the problem but It costs a lot of time and all the other running functions break because I clean all the collection.
TLDR; Using the CosmosDB emulator for local development solves this issue, as you won't have two functions pointing to the same lease collection.
There are two important points:
If you have one Azure Function deployed on Azure and one running locally in your machine with the same lease configuration listening for changes in the same monitored collection then these will behave as multiple instances of the same deployment and changes will be delivered to one or the other and you might experience "event loss" on the one running in Azure. This is documented in https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-changefeed-functions#some-changes-are-missing-in-my-trigger. If you want to have 2 independent Functions listening for changes in the same monitored collection, sharing the same lease collection, you need to use the LeaseCollectionPrefix configuration https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-create-multiple-cosmos-db-triggers
The error you are seeing locally is potentially related to either not having the Azure Storage emulator running or not configuring the AzureWebJobsStorage configuration locally to use it. Azure Functions runtime (regardless of the Cosmos DB Trigger) requires a storage account. You can use UseDevelopmentStorage=true for the local storage emulator.
I am just starting to test with Microsoft Azure Functions. I have my VS2017 publishing and my function is working nicely. I currently have one function that I am working with. It is set on a timer of every 5 minutes.
However, it appears that that function is executing even when I have it "disabled". This can be seen in the Monitor and in one of the systems that it is interacting with. The only way that I am able to stop it is to stop the overall function group. When I then start the function group, it starts the disabled function running every 5 minutes again.
Am I missing something? Does the disabling of an individual function have some other purpose?
How do I get an individual function within a function group to not execute on its defined schedule?
Thanks.
What you are experiencing is an expected behavior though not an ideal one. It is a bug in the portal experience.
The Function runtime directly consumes metadata in the binary files of the pre-compiled functions. Here is sample of annotation for the disabled function.
[TimerTrigger("0 */5 * * * *"), Disable()]
This is the function.json generated by visual studio the above annotations.
{
"generatedBy": "Microsoft.NET.Sdk.Functions.MSBuild-1.0.2",
"configurationSource": "attributes",
"bindings": [
{
"type": "timerTrigger",
"schedule": "0 */5 * * * *",
"useMonitor": true,
"runOnStartup": false,
"name": "myTimer"
}
],
"disabled": true,
"scriptFile": "..\\bin\\FunctionApp3.dll",
"entryPoint": "FunctionApp3.Function1.Run"
}
The function.json generated by the precompiled functions is consumed by the portal and that is what is shown in the portal. When you change the disabled state of the function in the portal the disabled property is changed in the function.json but it is not consumed by the functions runtime. Hence it continues to execute.
When you deploy it in disabled state, runtime is aware of it and honors it as expected.
I have opened this bug to fix the portal experience.
https://github.com/Azure/azure-functions-ux/issues/1857
Today, I got the same problem, and after to disable the function in Azure, I recommend you to restart the Function service. Because the Azure needs to refresh the metadata, and the restart is one of the solutions to accomplish it.
Note: Even though it may seem duplicate, My issue is different and I request you to read complete description before hastily marking the question down just by reading Question title.
I opened "Azure function is not triggering on scheduled time " issue on official "azure-webjobs-sdk-script" git repository on May 24, 2017-but there is no reply yet. So I am re-asking this here.
I am using azure function in consumption plan, and have scheduled it to execute at every 4.00 am utc by setting following cron expression in function.json:
{
"bindings": [
{
"name": "myTimer",
"type": "timerTrigger",
"direction": "in",
"schedule": "0 0 4 * * *"
}
],
"disabled": false
}
Azure function does get execute on time only if I am logged into portal or clicks on function blade. It does not invoke when I am logged out from portal (suggesting either system listener or function go to sleep after some interval).
Their official documentation states that functions in consumption plan do not require any other settings (like Always on) to keep the function alive, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events.. So as per documentation, no other settings I have to configure to execute function in consumption plan.
What I have tried?
From "Timer triggered azure function not getting triggered" question on SO, I re-checked and ensured my plan (consumption plan) and time zone. (I want it to run in utc, so no explicit setting is required)
From "#1445: Azure function timer trigger not firing" git issue, I checked whether it was just logs that are not appearing. But I am certainly sure, that its not the logs but the actual function does not get triggered unless I am having my portal on or trigger it manually.
I tried to check whether this behavior exists if I change the schedule to a more closer recursive invocations--I scheduled function to get executed at every 2 hours, and this schedule perfectly worked even when I logged out or did not awake function manually. This means, there is some issue when schedule is set to run on larger set of intervals (in my case each day)
As discussed here in #1534, deleting and redeploying the function completely in new function app did not reproduce the issue. So deleting the function and/or function app-and redeploying the same should make things working. Meanwhile, Azure team has announced to add internal logging which will help future diagnosis.