lmolkova

public static class MessagingExtensions
{
    // potential addition to event hubs SDK. service bus is similar
    // The only concern is availability of ActivityContext prior to .NET 5
    // there is a potential to update DiagnosticSource, but it's problematic because of 
    // version conflict: binding redirects on .NET Fx and version conflicts with Functions load contexts
    public static ActivityContext ExtractTraceContext(this EventData @event)
    {
        if (@event.Properties.TryGetValue("Diagnostic-Id", out var tp) && tp is string traceparent)
        {

lmolkova

package org.example.functions;

import com.azure.core.models.CloudEvent;
import com.azure.core.util.serializer.TypeReference;
import com.azure.messaging.eventgrid.EventGridEvent;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.microsoft.azure.functions.ExecutionContext;
import com.microsoft.azure.functions.HttpMethod;
import com.microsoft.azure.functions.HttpRequestMessage;

lmolkova

public static void main(String[] args) {
    // first call in not instrumented...
    doSomething();

    doSomething().transform(t -> {
        Span s = GlobalOpenTelemetry.getTracer("test")
                .spanBuilder("span")
                .startSpan();

        return t.doFinally(signal -> s.end())

lmolkova

• Structured logging in Azure SDK for Java
  • Problem
  • Goal
    • Non-goal
  • Proposal
    • Structured logging API
    • Log formatting and consumption
    • Perf
  • Additional Context
• Structured logging overview

lmolkova

HTTP

• P0 - Define span modelling conventions for HTTP client spans #1747
• Replace http.target with http.path and http.query? #2056
• Remove http.XX_content_length* semantic attributes #2028
• P0 - Confirm that HTTP instrumentations can provide sampling-relevant attributes at creation time #2011
• P? - required/optional #2114

P0 - Retries

• Semantic convention around retry attempts? #1306
• Adding semantic conventions for setting attributes to record retry behavior [#729](https://github.com/open-telemetry/opentelemetry-sp

lmolkova

private static final Method SET_REACTOR_CONTEXT_METHOD = getStoreContextMethod();    
static Method getStoreContextMethod() {
        try {
            Class<?> contextPropagationOperatorClass = Class.forName("io.opentelemetry.javaagent.shaded.instrumentation.reactor.ContextPropagationOperator");
            Class<?> oteContextShaded = Class.forName("io.opentelemetry.javaagent.shaded.io.opentelemetry.context.Context");
            if (contextPropagationOperatorClass != null && oteContextShaded != null) {
                Method storeMethod = contextPropagationOperatorClass.getDeclaredMethod("storeOpenTelemetryContext", reactor.util.context.Context.class, oteContextShaded);
                if (storeMethod.getReturnType() == reactor.util.context.Context.class) {
                    return storeMethod;
                }

lmolkova

package org.example;

import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.StatusCode;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.context.Scope;
import io.opentelemetry.exporter.jaeger.JaegerGrpcSpanExporter;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.common.CompletableResultCode;
import io.opentelemetry.sdk.trace.ReadableSpan;

lmolkova

package com.example.http;

import com.squareup.okhttp.Interceptor;
import com.squareup.okhttp.OkHttpClient;
import com.squareup.okhttp.Request;
import com.squareup.okhttp.Response;

import java.io.IOException;

import io.opentelemetry.api.trace.SpanKind;

lmolkova

Problem

Same operation may be instrumented multiple times (manual + auto or library-native + auto) because of multiple reasons (below). This usually affects protocol instrumentation (HTTP/gRCP/etc) as they are auto-instrumented already and quite popular. It manifests as duplicated spans that fights for context injection on RPC calls, double performance impact and increase telemetry bills. Here are some cases when it happens:

1. specialized instrumentation: native library instrumentaion can provide more rich data, better quality/performance + auto-instrumentation thats always on
2. new library behavior (user manually instrumented and then new version brings auto-instrumentation)
3. configuration error

While p1 is valid case, and p2/p3 are not, but we'd still would rather communicate the need to remove extra instrumentation instead of duplicating data.

Assumptions

lmolkova

       public class ResourceIdProcessor : ActivityProcessor
        {
            private  readonly AsyncLocal<string> resourceId = new AsyncLocal<string>();
            private readonly IHttpContextAccessor httpContextAccessor;

            public ResourceIdProcessor(IHttpContextAccessor httpContextAccessor)
            {
                resourceId = null;
            }