ApplicationInsights changes to AvailabilityTelemetry logging in v3.x loses AvailabilityTelemetry trace/span info

Aperta
#3,166 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp
Ambito
observability

Direzione di ricerca

Confronta la gestione di AvailabilityTelemetry nelle build 2.23.0 e 3.x, iniziando dal percorso v3.x ILogger e dell’esportatore OpenTelemetry. Esamina il comportamento indicato di AddAvailabilitySpanInfo e AddTelemetryParentIds, quindi analizza la gestione di LogRecord dell’esportatore azure-sdk-for-net. Riproduci la perdita in aspnetcore9.0 e definisci un modo per consentire alle voci di disponibilità di mantenere TraceId e ParentSpanId.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

keep-open

Working packages:

  • Microsoft.ApplicationInsights 2.23.0
  • Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel 2.23.0

Broken packages

  • Microsoft.ApplicationInsights 3.x

Runtime: aspnetcore9.0
Hosting environment: any

The changes to proxy AvailabilityTelemetry through ILogger + the OpenTelemetry exporter in the 3.x builds lose the otel trace/span info that previously worked. This previously worked:

    private static void AddAvailabilitySpanInfo(AvailabilityTelemetry telemetryItem, Activity? activity)
    {
        if (activity != null)
        {
            telemetryItem.Id = activity.SpanId.ToString();
        }

        AddTelemetryParentIds(telemetryItem, activity);
    }

    private static void AddTelemetryParentIds(ITelemetry telemetryItem, Activity? activity)
    {
        if (activity != null)
        {
            telemetryItem.Context.Operation.Id       = activity.TraceId.ToString();
            if (activity.ParentId != null)
            {
                telemetryItem.Context.Operation.ParentId = activity.ParentSpanId.ToString();
            }
        }
    }

but now the otel trace/span info is lost. I've verified by code reviewing both this repo and the otel exporter in the azure-sdk-for-net that the span info in the legacy TelemetryContext.Operation is not accounted for.

Modelling an AvailabilityResult as a LogRecord is potentially problematic because an AvailabilityResult has span semantics (it has a duration and can be a non-leaf node in the trace tree). The ApplicationInsights UI gets this correct, eg this is how our health reporting looks using ApplicationInsights 2.23.0 client lib:

Image

So if you want to push an AvailabilityTelemetry through an ILogger to a LogRecord you're going to have to come up with a representation for the TraceId and ParentSpanId that can be restored within the Availability entry in the otel exporter.

We are 90% migrated to OpenTelemetry - the only reason we still have a dependency on the ApplicationInsights (classic/legacy) library is for Availability reporting. So it would be better for us to be able to log Availability entries directly (via the otel exporter or preferably an Api client), then we could drop the ApplicationInsights libraries. But we'd still need a way to specify the activity/span info for each Availability entry - currently there is none. I've tried doing this purely using ILogger and using the Availability properties, and I can create the Availability telemetry this way except for the span properties.

Of course I would feel more comfortable if there was a strong API (eg service API client) for reporting availability telemetry, vs a set of dictionary keys passed to an ILogger that could change at any time.

To be clear: We can't upgrade to ApplicationInsights 3.x until this is addressed, and/or we can't migrate to the otel exporter library only until there is a way to report AvailabilityTelemetry where we can specify the TraceId and ParentSpanId.

Lingua principale
C#
Stelle
616
Fork
298
Merge medio
19h 31m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/ApplicationInsights-dotnet

Tutte le issue di microsoft/ApplicationInsights-dotnet

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.