Allow per-function filtering of request telemetry

[brettsam]

Today we log all results with the category Host.Results. Can we change that to be Host.Results.<YOUR_FUNCTION_NAME>? Even if it requires a separate flag to enable (which it may not; I'm not thinking about this as breaking), it would open up a bunch of scenarios that in-proc customers currently rely on ITelemetryProcessors to handle today. These aren't loaded by the host for out-of-proc scenarios.

[jviau]

I think this will be covered by OTel work. The function information will be part of the scope, which we will start including as a property bag.

[fabiocav]

@RohitRanjanMS will be validating to ensure this is easily done with OTel.

[mbrcic-avy]

Any status updates?

[mbrcic-avy]

@RohitRanjanMS any status updates?

[RohitRanjanMS]

Hi @mbrcic-avy , can you help explain your scenario? What's the problem and how is it affecting you?

[mbrcic-avy]

Hi @mbrcic-avy , can you help explain your scenario? What's the problem and how is it affecting you?

Hi @RohitRanjanMS , thanks for reaching out. We want to be able to use TelemetryProcessors like with asp.net core apps, and it seems some types of telemetry doesn't even reach our custom hooked telemetry processor and for DependencyTelemetry which for example reaches custom TelemetryProcessor, it seems that it can not fully filter out stuff, that some downstream telemetry mechanism overrules what we tried to do with our custom telemetry processor, even if we accept the "ITelemetryProcessor next" in the constructor of custom telemetry processor.

So we were curious if switching to otel SDK instead of appInsights SDK would give us option to have better control to filter out what comes to appInsights vs what doesn't.

[mkeinemans]

Hi All,

We are also facing issues regarding the inability to filter request telemetry. To be specific, we have a Monitor endpoint and a very chatty DurableTask that we where able to filter out on the older in-process model but we cannot in the new model.

I have been looking into filtering this out by setting the loglevels in the host.json, but this does not work since all the request telemetry is logged under the Host.Results category, instead of a category that is specific to the function that is being called.

Our bill for application insights have been increased by a quite a bit, we have mitigated this for now by increasing the sampling rate. But this is not a desired situation, and will only be a temporary solution, because we are still moving other functions to the new isolated model, so in the future we probably have to adjust the sampling rate again.

I am also fine if we have to start using a different SDK to have this fixed.

[marcselman]

Waiting on this feature as well