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;
            }

lmolkova

    public class ClientIpHeaderTelemetryInitializerCopy : TelemetryInitializerBase
    {
        private const string HeaderNameDefault = "X-Forwarded-For";
        private readonly char[] headerValuesSeparatorDefault = { ',' };

        private char[] headerValueSeparators;

        /// <summary>
        /// Initializes a new instance of the <see cref="ClientIpHeaderTelemetryInitializer" /> class.
        /// </summary>

lmolkova

Tracing API Comparison

A distributed trace is a set of events, triggered as a result of a single logical operation, consolidated across various components of an application. A distributed trace contains events that cross process, network and security boundaries. A distributed trace may be initiated when someone presses a button to start an action on a website - in this example, the trace will represent calls made between the downstream services that handled the chain of requests initiated by this button being pressed.

Contract difference

OpenTelemetry Tracing API is a very strict contract that enables tracing signal (not debugging or profiling). This contract is the same for all kinds of libraries and tracing backends and includes several related concepts:

• span creation, required and optional properties
• sampling
• exporting
• noop behavior in absence of tracing implementaiton
• extra information certain types spans should include (e.g. spans for http calls).