azure-webjobs-sdk
azure-webjobs-sdk copied to clipboard
[AppInsights] -- Table Storage binding calls are appearing as dependency failures
Repro steps
-
Deploy Azure Function with http trigger and table storage binding. Enable AppInsights for this funtction App
-
Send http request to function endpoint
Expected behavior
No dependency error should be displayed in AppInsights Live Metrics
Actual behavior
Dependency error is logged and displayed in in AppInsights "Live Metrics" for every request to this endpoint (POST xxxstorage/Tables 409 error status)
Environment Info and Sample App
Azure Function Runtime: 2.0.12275.0 (~2) Sample app to reproduce issue: https://github.com/andrii-baranov/azure-func-binding-error-demo
I have the exact same issue other than the name of the storage account and the version of v2 runtime.
Runtime version: 2.0.12353.0 (~2)
I realize that these are 'benign' but I'm trying to debug my application and these are both misdirecting and unhelpful.
Same error here.
The packages are up to date
The binding that is throwing the dependency error:
Any update on this? Can you add a similar fix as you did for blob storage? One 404 is a lot better than thousands of 409s. Even better, can we have a policy? Then you can leave the default behavior in place but allow us to have some control without having to write our own bindings.
Same problem here, this just cost me a few hours to track down this bug.
Can we get an update on this please? This is causing a major headache for us!
I prefer to have errors-free analytics. So, here is a workaround that I use: https://gist.github.com/nardieu/24bedee7c488376fb508aee79e808eae
And usage:
[FunctionName("SomeFunction")]
public static async Task Run(
[TimerTrigger("0 */15 * * * *")]TimerInfo myTimer,
ExecutionContext context,
ILogger log)
{
var appService = new Utils.AppService(context);
var accountsTable = await appService.StorageService.GetTable("Accounts");
...
}
Also this solution allows you to reuse config for easily getting settings from local.settings.json
as a property of AppConfig
.
Thanks @nardieu. I was actually thinking of writing something similar. Definitely will be making use of this until the issue is resolved. Thanks for sharing.
Hi, I already did before. Nothing is changed since that time.
Get Outlook for Androidhttps://aka.ms/ghei36
From: delta25 [email protected] Sent: Wednesday, August 21, 2019 12:17:32 PM To: Azure/azure-webjobs-sdk [email protected] Cc: SergiyKostenko [email protected]; Manual [email protected] Subject: Re: [Azure/azure-webjobs-sdk] [AppInsights] -- Table Storage binding calls are appearing as dependency failures (#2098)
Thanks @nardieuhttps://github.com/nardieu. I was actually thinking of writing something similar. Definitely will be making use of this until the issue is resolved. Thanks for sharing.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-webjobs-sdk/issues/2098?email_source=notifications&email_token=AE3ZNFCNFVIP7GIIUEXANALQFUB2ZA5CNFSM4GSFSQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZAQYA#issuecomment-523372640, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3ZNFELCN6GSNZVPSCF643QFUB2ZANCNFSM4GSFSQ7Q.
I'm having this issue, and I've got these libraries
FYI, I've just upgraded the packages and having the same issue:
Thousands of garbage errors in AppInsights for months on end.
Any update on this? The amount of telemetry and storage requests generated is ridiculous, especially when you have a queue trigger (or similar). There is something to be said about the performance impact as well; additional execution time and therefore an additional cost for Consumption plans. My current workaround is creating the client and table reference myself using DI configuration in the v3 runtime. My suggestion would be to have the runtime get all of the binding attributes on the functions at startup and perform the CreateIfNotExists
, etc. calls there (or at least provide the option to do this).
The vast majority of Transactions showing up in Metrics are the CreateTable calls. It seems like such a waste of resources to just hammer away and get 409s. The simplest solution that would work for me would be to add a property on the binding (or in the hosts.json file) to tell it to let us handle any creation and just fail if it doesn't exist.
Issue still exist, but I would like to share workaround I am using, I am temporally disabling Appinsigts for such kind of calls:
TelemetryConfiguration.Active.DisableTelemetry = true;
Hope that help someone
Any update? We have Managed Identity configured for table access, and don't want to give it any table modification permissions, so CreateIfNotExists is actually a fatal error. We don't want that, the binding shouldn't try to create a table without being told to.