Azure-functions-host: Add telemetry for language versions on Windows

Created on 23 Jan 2020  路  16Comments  路  Source: Azure/azure-functions-host

P1 Supportability

All 16 comments

In Linux consumption we now log language versions (e.g. python-3.8 instead of just python). Should ensure that for languages we are emitting the right details for analytics to get language AND version. So node should be something like node-8 and node-12 for example.

@mhoeger may have context

The Linux change was fairly straight-forward because there is a single point where each version of each language stack is well defined. For Windows, the problem is trickier since the version comes from many different places

@pragnagopa - I think the placeholder id logic does this work for us... Is there some way we could flow the placeholder id down to the runtime?

This is an Antares change to inject placeholderId as environment variable. Tagging @AnatoliB - Incase he has more ideas as he has recently worked on injecting runtime version property.

I've recently added code that populates the FUNCTIONS_WORKER_RUNTIME_VERSION environment variable with the language version for Java, Node, and PowerShell, so this variable is automatically available to the host. This will be deployed with ANT87.

Please note, however, that the purpose of this variable is to _communicate user's intent_ to the Functions host, and it is not always equal to the _actually used_ version. For example, PowerShell users don't have to specify _any_ version. If they don't specify any version, FUNCTIONS_WORKER_RUNTIME_VERSION will be empty, and the Function host will use the default version taken from the worker config file ("6" in this specific example). I don't know if we have similar logic for other languages.

Thanks. Once ANT87 deploys, we can use FUNCTIONS_WORKER_RUNTIME_VERSION and for other languages, cases where this is empty would be small as node always required an AppSetting and Java uses JavaVersion for a long time now.

Ok. It is quite possible that my example with PowerShell 6 is the only one. :-)

Awesome! @divyagandhii made the Functions runtime change for Linux here, so looks like we just have to wait for ANT 87 for Windows data! (Our dashboards may also need to special case the PowerShell case where if there's no version, assume it's 6)

FYI that change was tweaked a little
https://github.com/Azure/azure-functions-host/commit/20f0c6d7fcf987f37f29b79030a75145fe15ccf9

But this change is only going out on Linux with the current release.

@mhoeger Assigning to Sprint 74. Can you clarify the work remaining to be done?

@kulkarnisonia16 - I believe we are just waiting for deployments. @Hazhzeng and @divyagandhii worked on fixes to populate the data (here and here). These changes are going out with a hotfix deployment likely this week.

@AnatoliB - do you know if the change you made are deployed? I'm a bit confused with ANT 87.1

@mhoeger I'm also not very clear on the current ANT 87 deployment status. I can see my changes started working on some stamps, but not everywhere. Apparently, the deployment has been stopped and we need to wait for ANT 87.1 now. I will update this thread if I find something different.

Apparently, the deployment has been stopped and we need to wait for ANT 87.1 now.

As far as I understand now, ANT 87 is not entirely complete yet: we are still waiting for Geo's. So, no need to wait for ANT 87.1.

We need to validate whether this is working now that ANT 87 is done.

@kulkarnisonia16 - running a query (and validating from an app in prod), it looks like the App Setting FUNCTIONS_WORKER_RUNTIME_VERSION is now being populated in Windows and the value is being emitted to FunctionsMetrics (example event name: "host.startup.runtime.language.node-~8")

From our perspective, the work is complete but please let us know if there's any work that remains to consider this issue closed.

Also note there is a special case for PowerShell:

Please note, however, that the purpose of this variable is to communicate user's intent to the Functions host, and it is not always equal to the actually used version. For example, PowerShell users don't have to specify any version. If they don't specify any version, FUNCTIONS_WORKER_RUNTIME_VERSION will be empty, and the Function host will use the default version taken from the worker config file ("6" in this specific example).

@kulkarnisonia16 - is it ok to close this issue?

Verified that the data is there as expected

Was this page helpful?
0 / 5 - 0 ratings