feat: Support OpenTelemetry Azure monitor distro

[lzchen]

Description

We are planning to support auto instrumentation of Azure monitor distro for azure functions. This allows automatic collection of telemetry using OpenTelemetry apis/sdks in users applications in azure functions. The current design is an opt-in model which is controlled by an Appsetting PYTHON_ENABLE_OPENTELEMETRY. The worker takes an indirect dependency on the distro package and attempts to load/instrument with it via configure_azure_monitor() api provided. The idea is to have this package already preinstalled into the functions image. Until the images are pushed out with this package, you may test this change by manually installing the distro onto your dev environment.

Additionally, any exceptions thrown by the distro are caught and logged accordingly. A telemetry sdk should never cause a user's application to crash.

@gavin-aguiar @vrdmr

[lzchen]

@gavin-aguiar

Since this is a telemetry sdk meant only to be loaded once, I have placed this in worker_init_request. Is there anything special that happens during environment_reload_request that needs to be done pertaining this in your opinion?

[gavin-aguiar]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[gavin-aguiar]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[gavin-aguiar]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lzchen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[gavin-aguiar]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ashleysommer]

@lzchen
I've started using this new version of Azure Functions Python Worker locally, and I believe after this addition of Azure Monitor Distro feature there is a regression in the previous behaviour even though this new feature is.

I use OpenTelemetry in my app by calling context_api.get_context() to get the current context that is pushed by the Function Worker.
In previous versions, this context was pushed on every invocation if _otel_libs_available is True. After this feature addition, the context is pushed on every invocation only if _azure_monitor_available is True.

_azure_monitor_available is only True under the following condition:

1. PYTHON_ENABLE_OPENTELEMETRY var is set and
2. OpenTelemetry python modules are installed and
3. azure.monitor.opentelemetry python module is installed.

In my case, I do not with to use Azure Monitor Otel Distro, so I have:
PYTHON_ENABLE_OPENTELEMETRY enabled, and OpenTelemetry python modules installed, but azure.monitor.opentelemetry module not installed.
In pre-v4.31, my application works fine (the worker sets the context using context_api.attach(), and I can retrieve it in my app using context_api.get_context(). In v4.31+ the worker does not attach the context on each invocation because _azure_monitor_available is not True.

[lzchen]

@ashleysommer

We will be rolling out images in which the azure.monitor.opentelemetry module will be pre-installed on the image itself so it will always exist (regardless if (1) is set). Thus, effectively, only (1) and (2) would be needed from the users side.

There is an interim stage in which these images will not be pushed to production yet. If you would like to use the preview version of the worker, you can set the context in code manually for now as a workaround.

[lzchen]

As a followup to the above, we introduced this pr: #1621

We have decided to use separate app settings to control context propagation and enabling appinsights explitcily, the latter automatically also supports the former.