Merge remote-tracking branch 'nullcubed/patch-1' into fixup

Author: ggailey777

articles/azure-functions/TOC.yml

@@ -620,6 +620,7 @@
           displayName: monitoring
         - name: Work with OpenTelemetry
           href: opentelemetry-howto.md
+          displayName: OTel
     - name: Authenticate
       items:
         - name: Configure auth providers

articles/azure-functions/opentelemetry-howto.md

@@ -18,35 +18,33 @@ This article shows you how to configure your function app to export log and trac
 
 > [!TIP]  
 > Because this article is targeted at your development language of choice, remember to choose the correct language at the top of the article.
-::: zone pivot="programming-language-java" 
-> Currently, there's no client optimized OpenTelemetry support for Java apps.
-:::zone-end
 ::: zone pivot="programming-language-csharp" 
-> OpenTelemetry currently isn't supported for C# in-process apps.
+> OpenTelemetry currently isn't supported for [C# in-process apps](./functions-dotnet-class-library.md).
 :::zone-end
 
  You can obtain these benefits by enabling OpenTelemetry in your function app: 
 
-+ Correlation across traces and logs being generated both at the host and in your application code.
-+ Consistent, standards-based generation of exportable telemetry data. 
++ Correlates data across traces and logs being generated both at the host and in your application code.
++ Enables consistent, standards-based generation of exportable telemetry data. 
 + Integrates with other providers that can consume OpenTelemetry-compliant data. 
 
 OpenTelemetry is enabled at the function app level, both in host configuration (`host.json`) and in your code project. Functions also provides a client optimized experience for exporting OpenTelemetry data from your function code that's running in a language-specific worker process.
 
-## 1. Enable OpenTelemetry in the Functions host
+## Enable OpenTelemetry in the Functions host
 
 When you enable OpenTelemetry output in the function app's host.json file, your host exports OpenTelemetry output regardless of the language stack used by your app.   
 
-To enable OpenTelemetry output from the Functions host, update the [host.json file](./functions-host-json.md) in your code project to add a `"telemetryMode": "openTelemetry"` element to the root collection. With OpenTelemetry enabled, your host.json file might look like this:
+To enable OpenTelemetry output from the Functions host, update the [host.json file](./functions-host-json.md) in your code project to add a `"telemetryMode": "OpenTelemetry"` element to the root collection. With OpenTelemetry enabled, your host.json file might look like this:
 
 ```json
 {
     "version": "2.0",
-    "telemetryMode": "openTelemetry"
+    "telemetryMode": "OpenTelemetry",
+    ...
 }
 ```
 
-## 2. Configure application settings 
+## Configure application settings 
 
 When OpenTelemetry is enabled in the host.json file, the endpoints to which data is sent is determined based on which OpenTelemetry-supported application settings are available in your app's environment variables. 
 
@@ -60,15 +58,22 @@ Create specific application settings in your function app based on the OpenTelem
 
 **`OTEL_EXPORTER_OTLP_ENDPOINT`**: an OTLP exporter endpoint URL. 
 
-**`OTEL_EXPORTER_OTLP_HEADERS`**: (Optional) list of headers to apply to all outgoing data. This is used by many endpoints to pass an API key.
+**`OTEL_EXPORTER_OTLP_HEADERS`**: (Optional) list of headers to apply to all outgoing data. This setting is used by many endpoints to pass an API key.
 
 If your endpoint requires you to set other environment variables, you need to also add them to your application settings. For more information, see the [OTLP Exporter Configuration documentation](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/). 
 
 You should remove the `APPLICATIONINSIGHTS_CONNECTION_STRING` setting, unless you also want OpenTelemetry output from the host sent to Application Insights. 
 
 ---  
 
-## 3. Enable OpenTelemetry in your app
+::: zone pivot="programming-language-java"
+You must also add `JAVA_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true` to your application settings. Setting this flag tells the Functions host to let the Java worker process stream OpenTelemetry logs directly, which prevents duplicate host-level entries.
+
+> [!NOTE]  
+> When both Application Insights and OTLP exporter settings are present, telemetry flows to both backends.
+::: zone-end
+
+## Enable OpenTelemetry in your app
 
 With the Functions host configured to use OpenTelemetry, you should also update your application code to output OpenTelemetry data. Enabling OpenTelemetry in both the host and your application code enables better correlation between traces and logs emitted both by the Functions host process and from your language worker process. 
 
@@ -128,107 +133,70 @@ The way that you instrument your application to use OpenTelemetry depends on you
     To export to both OpenTelemetry endpoints, call both `UseAzureMonitor` and `UseOtlpExporter`. 
 ::: zone-end
 ::: zone pivot="programming-language-java"
+1. Add the required libraries to your app. The way you add libraries depends on whether you deploy using Maven or Kotlin and if you want to also send data to Application Insights.
+
+    ### [Maven](#tab/maven/app-insights)
+
+    ```xml
+    <dependency>
+      <groupId>com.microsoft.azure.functions</groupId>
+      <artifactId>azure-functions-java-opentelemetry</artifactId>
+      <version>1.0.0</version>
+    </dependency>
+    <dependency>
+      <groupId>com.azure</groupId>
+      <artifactId>azure-monitor-opentelemetry-autoconfigure</artifactId>
+      <version>1.2.0</version>
+    </dependency>
+    ```
 
-### Step 1 – Add the required libraries
-
-**Core bridge** (always) – enables OpenTelemetry inside the Java worker
-
-**Maven**
-```xml
-<dependency>
-  <groupId>com.microsoft.azure.functions</groupId>
-  <artifactId>azure-functions-java-opentelemetry</artifactId>
-  <version>1.0.0</version>
-</dependency>
-```
-
-**Gradle (Kotlin DSL)**
-```kotlin
-implementation("com.microsoft.azure.functions:azure-functions-java-opentelemetry:1.0.0")
-```
-
-**Application Insights exporter** (optional) – add only if you plan to send data to AI
-
-**Maven**
-```xml
-<dependency>
-  <groupId>com.azure</groupId>
-  <artifactId>azure-monitor-opentelemetry-autoconfigure</artifactId>
-  <version>1.2.0</version>
-</dependency>
-```
-
-**Gradle (Kotlin DSL)**
-```kotlin
-implementation("com.azure:azure-monitor-opentelemetry-autoconfigure:1.2.0")
-```
-
-> The bridge looks for `AzureMonitorAutoConfigure` by reflection; if this dependency isn’t present, it simply skips the AI exporter.
-
----
-
-### Step 2 – Add application settings
-
-Set this flag **in every Java Functions app that uses the bridge**, even if you export only to OTLP:
-
-```text
-JAVA_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true
-```
-
-This capability tells the Functions host to let the Java worker stream OpenTelemetry logs directly, preventing duplicate host-level entries.
-
-Additional settings:
-
-* **Application Insights**
-  `APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=https://...`
-
-* **OTLP export**
-  `OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.example.com:4318`
-  `OTEL_EXPORTER_OTLP_HEADERS=api-key=abcd1234` (optional)
-
-If both AI *and* OTLP variables are present, telemetry flows to **both** back-ends.
-
----
-
-### Step 3 – (Optional) create custom spans
-
-```java
-import com.microsoft.azure.functions.opentelemetry.FunctionsOpenTelemetry;
-import io.opentelemetry.api.trace.Span;
-import io.opentelemetry.api.trace.SpanKind;
-import io.opentelemetry.context.Scope;
+    ### [Kotlin](#tab/kotlin/app-insights)
 
-Span span = FunctionsOpenTelemetry.startSpan(
-        "com.contoso.PaymentFunction",  // tracer name
-        "validateCharge",               // span name
-        null,                           // parent = current context
-        SpanKind.INTERNAL);
+    ```kotlin
+    implementation("com.microsoft.azure.functions:azure-functions-java-opentelemetry:1.0.0")
+    implementation("com.azure:azure-monitor-opentelemetry-autoconfigure:1.2.0")
+    ```
 
-try (Scope ignored = span.makeCurrent()) {
-    // business logic here
-} finally {
-    span.end();
-}
-```
+    ### [Maven](#tab/maven/otlp-export) 
 
-Custom spans inherit all resource attributes and exporters configured by the bridge.
+    ```xml
+    <dependency>
+      <groupId>com.microsoft.azure.functions</groupId>
+      <artifactId>azure-functions-java-opentelemetry</artifactId>
+      <version>1.0.0</version>
+    </dependency>
+    ```
 
----
+    ### [Kotlin](#tab/maven/otlp-export) 
 
-### Step 4 – Local development and testing tips
+    ```kotlin
+    implementation("com.microsoft.azure.functions:azure-functions-java-opentelemetry:1.0.0")
+    ```
 
-* Outside Azure, the resource detector defaults `service.name` to `java-function-app`.
-* **Java Virtual Machine (JVM)** flags to silence telemetry during unit tests:
+    ---
 
-  ```text
-  -Dotel.traces.exporter=none
-  -Dotel.metrics.exporter=none
-  -Dotel.logs.exporter=none
-  ```
-* You don’t need to register anything manually—the Java worker **autodiscovers** `OpenTelemetryInvocationMiddleware`.
+2. You can optionally add this code to create custom spans:
 
-::: zone-end
+    ```java
+    import com.microsoft.azure.functions.opentelemetry.FunctionsOpenTelemetry;
+    import io.opentelemetry.api.trace.Span;
+    import io.opentelemetry.api.trace.SpanKind;
+    import io.opentelemetry.context.Scope;
+    
+    Span span = FunctionsOpenTelemetry.startSpan(
+            "com.contoso.PaymentFunction",  // tracer name
+            "validateCharge",               // span name
+            null,                           // parent = current context
+            SpanKind.INTERNAL);
+    
+    try (Scope ignored = span.makeCurrent()) {
+        // business logic here
+    } finally {
+        span.end();
+    }
+    ```
 
+::: zone-end  
 ::: zone pivot="programming-language-javascript,programming-language-typescript"
 1. Install these npm packages in your project:
     
@@ -328,7 +296,7 @@ These instructions only apply for an OTLP exporter:
     ```
     ---
 
-1. Make sure the below library is in your `requirements.txt` file, whether from uncommenting or adding yourself:
+1. Make sure these libraries are in your `requirements.txt` file, whether from uncommenting or adding yourself:
 
     ### [Application Insights](#tab/app-insights)
 
@@ -349,7 +317,7 @@ These instructions only apply for an OTLP exporter:
 
     ### [Application Insights](#tab/app-insights)
 
-    If you followed the above steps by setting the `PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY`, you don't need to add any additional code and skip the below.
+    If you followed the above steps by setting the `PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY`, you don't need to add any other code and skip the below.
 
     If you would like to enable Application Insights collection manually without automatic instrumentation, add the following code:
    
@@ -390,22 +358,34 @@ These instructions only apply for an OTLP exporter:
 
     ---
 
-1. Refer to [Azure monitor Distro usage]https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/monitor/azure-monitor-opentelemetry#usage) documentation for how to configure the SDK.
+1. Refer to [Azure monitor Distro usage](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/monitor/azure-monitor-opentelemetry#usage) documentation for how to configure the SDK.
   
 ::: zone-end  
 ## Considerations for OpenTelemetry
 
 When you export your data using OpenTelemetry, keep these current considerations in mind.
 
-+ At this time, only HTTP, Service Bus and Event Hub triggers are supported with OpenTelemetry outputs. 
++ At this time, only HTTP, Service Bus and Event Hubs triggers are supported with OpenTelemetry outputs. 
 
 + When the host is configured to use OpenTelemetry, the Azure portal doesn't support log streaming or recent function invocation traces.
+::: zone pivot="programming-language-java" 
++ Custom spans automatically include all resource attributes and use the exporters configured in your app.
+
++ When your app runs outside Azure, including during local development, the resource detector sets the `service.name` attribute to `java-function-app` by default.
 
++ Use these Java Virtual Machine (JVM) flags to silence telemetry when running locally during unit tests:
+
+    + `-Dotel.traces.exporter=none`
+    + `-Dotel.metrics.exporter=none`
+    + `-Dotel.logs.exporter=none`
+
+* You aren't required to manually register middleware; the Java worker autodiscovers `OpenTelemetryInvocationMiddleware`.
+::: zone-end  
 + [Azure Functions diagnostics](functions-diagnostics.md) in the Azure portal is a useful resource for detecting and diagnosing potential monitoring-related issues. 
 
 To access diagnostics in your app:
 
-  1. In the [Azure portal](https://portal.azure.com) navigate to your function app resource. 
+  1. In the [Azure portal](https://portal.azure.com), navigate to your function app resource. 
   
   1. In the left pane, select **Diagnose and solve problems** and search for the *Function App missing telemetry Application Insights or OpenTelemetry* workflow.