We are running a number of Azure Functions on a Linux Consumption Plan instance using v4 functions written in C#. Code is deployed using GitHub Actions and all use Microsoft.Azure.Functions.Worker.Sdk Version 1.14.1.
One of the functions uses a CosmosDB Change Trigger to activate, and another is using a Timer Trigger set to execute very five minutes.
Our Application Insights for the functions is showing GET: {ipAddress}/metadata/instance calls every five minutes, each with an average duration of 1.1 minutes, and always resulting in a Cancelled state.
Where and why are these calls being made, and what can be done to avoid this? It seems like this would be adding unnecessary overhead load to the service?
This call is made by the Azure Cosmos DB SDK to capture Azure VM metadata information. Reference: https://learn.microsoft.com/azure/virtual-machines/instance-metadata-service?tabs=windows
This call is made during client initialization and the failure is not critical for the Cosmos DB client. The purpose is, for cases where you have issues and telemetry is emitted, it adds information such as, where is the location of the Azure VM and helps to identify cases where you have multiple client instances.
The important part here is, this should happen only during client initialization. The CosmosDBTrigger creates the client once and reuses it, if you are seeing it every 5 minutes, this means that either:
CosmosClientto perform some operations on an Azure Cosmos DB container and you are not following the Singleton pattern (for example, creating a new CosmosClient on your TimerTrigger for every execution). This is an anti-pattern. Reference: https://learn.microsoft.com/azure/azure-functions/manage-connections?tabs=csharp#static-clients. If this is your case, I'd advice to look into this example project that leverages Azure Functions Dependency Injection to generate a Singleton CosmosClient: https://github.com/Azure/azure-cosmos-dotnet-v3/tree/master/Microsoft.Azure.Cosmos.Samples/Usage/AzureFunctions