ApplicationVersion doesn't seem to be uniformally available in Application Insights requests

[nulltoken]

👋 Hello, when configuring an azure function as described in #1182 (comment), and valuing the ApplicationVersion, this data is indeed attached to the dependencies displayed in Azure Portal.

However, the http parent request doesn't seem decorated with this information.

Similarly, traces issued through ILogger are decorated

But traces generated by the underlying framework aren't

Help?

[brettsam]

Application Insights logs coming from your app are a combination of logs coming from 2 processes -- the Functions host and the isolated worker.

That's the discrepancy you're seeing -- some of those logs are coming from the host and the others from the worker.

Any App Insights customizations setup on the isolated worker do not apply to the host, so you can see different values like this.

[nulltoken]

@brettsam Thanks a lot for the detailed explanation of the underlying reason.

What should be done to apply those customizations in a uniform way ?

I understand running in an isolated process is the way forward, and I'm fine with it. However, from someone running kusto queries standpoint, isolated or in-process is an implementation detail. How can we provide them with the "standard" experience they're used to ?

Customizing kusto queries to accommodate host/worker differences seems like a very non user-friendly approach.

Note: I've used ApplicationVersion here to showcase the issue in the simplest possible way. But I believe the same would apply for ITelemetryInitializer based implementations.

[brettsam]

Yes, this is a known struggle right now (that applies across all language in Functions, not just .NET). The host and worker are basically two separate services and you don't have as much access to the host code as you do the worker.

We're working on designs now (share-able soon, I hope) where we will either... (or maybe even both):

• Send all worker telemetry back to the host over OpenTelemetry (OTLP) and allow you to configure your destination (App Insights, for example) there via configuration -- but no custom processor code. Today we kind of do this -- but the telemetry is not rich and it only includes logging statements made during an invocation, which is quite limiting.
• Send all host telemetry through the worker -- or even some separate collector service -- (again, via OTLP) to allow you to export that telemetry to whatever destination you want, with full control over setting things like you are above.

We know folks are really struggling with things like

• "host.json" only applies to the host -- so you now have two logging configurations to deal with
• my initializers only run in the worker
• my worker and host logs look different

We'd love feedback on what would make sense to you (and others) -- we're trying to think through the "I just need basic logging to work" and "I have lots of customizations I need to run" scenarios.

[nulltoken]

@brettsam AWESOME FEEDBACK ! Thanks for that ❤️

Second scenario would be the one that would make the most sense in our context (team, department and organization levels).

TL;DR:
We live in telemetry data. Basic logging and counting requests won't be enough for us.

A bit more detailed context:
Part of the design of new features includes defining what we want to measure/track once in Production.

We greatly rely on events and metrics to track business operations, or even measure the performance of some processes (or alternate implementations). As such, we heavily rely on telemetry and enrich it through additional telemetry initializers to decorate those with contextual metadata (which is later used for filtering by queries).

Of course, we leverage those through kusto queries, some used in workbooks for high level supervision of our processes, some others tied to alerts when things start to escape the boundaries of acceptable limits (defined partly by the contextual metadata above).

[nulltoken]

@brettsam I've just read again this post providing an update of the Azure Function roadmap.

It states "We will announce this transition (complete deprecation of the in-process mode) before the initial preview of the first impacted LTS version. Parity will have to have been reached before then; it will be possible at that point to seamlessly uprade an app on the in-process model to its corresponding isolated process model for that .NET version. There will be no compromise in experience resulting from this transition."

The parts that I've highlighted in bold seem very promising and seem to also point forward a complete support of your second scenario. Or am I misunderstanding the blog post statement?

[jviau]

I want to chime in here and advise it is incorrect to have the host process emit logs with your application's version. These are different "applications" - the host is its own thing and should emit logs with its own app version. This is valuable as you may notice an emerging issue and be able to see it occurs on one host app version and not another.

Now, this does beg the question on if the host even sets app version for these logs... that I am unsure. If we don't, we should! We are working on improving observability in the host, and I believe this will be captured by that.

[jviau]

Closing this as it is a host concern, and is primarily covered by Azure/azure-functions-host#9273