Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[SDK] Support non-exporting pipeline log record processors (needed for EventToSpanEventBridgeProcessor)

Aperta
  • Qualcosa non va?
#4,454 0 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
cpp
Ambito
observability

Direzione di ricerca

Inizia leggendo il design esistente di LogRecordProcessor e MultiLogRecordProcessor, quindi esamina LoggerContext e il commento FIXME-SDK in sdk_builder.cc. Definisci i componenti richiesti ReadWriteLogRecord e di pipeline componibili, il processore radice e l’integrazione con LoggerContext prima di implementare EventToSpanEventBridgeProcessor. Il lavoro è completato quando l’architettura funziona senza trasferire la proprietà del record e la bridge può essere reintrodotta nella configurazione dichiarativa.

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

Descrizione

discuss triage/accepted

Summary

EventToSpanEventBridgeProcessor (proposed in #4309) bridges log-record events onto the live Span referenced by the log record's resolved context. It needs a LogRecordProcessor that can:

  • read the resolved context (Context/live Span) at OnEmit() time
  • read the log record's own data (body, attributes) without taking exclusive ownership away from downstream processors/exporters

The current LogRecordProcessor interface doesn't support this shape of "non-exporting", read/mutate pipeline processor, so the bridge processor can't be implemented correctly without new SDK architecture.

Background

From review on #4309:

Processors like the bridge processor will require some new architectural components and changes to existing components to be spec compliant and maintain reasonable performance. This is in addition to the Logger API level EmitLogRecordWithContext change, which is needed.

The architecture components / changes that seem to be required include:

  1. Standardize the SDK built-in exporters (OTLP, ostream) on a recordable with a read-write interface. Pipeline processors need to read data from the record and not duplicate it.
  2. Create a new processor interface for composable pipeline processors that can read and mutate data but do not own the recordable life-cycle.
  3. Create a new root level processor that supports pipeline processors
  4. Update the LoggerContext to support setting a new root processor.

The concrete problem: with today's LogRecordProcessor interface, a configuration like

logger_provider:
  processors:
    my_logs_filter:
    my_log_record_sanitizer:
    event_to_span_bridge:
    batch:
      exporter:
        otlp_http:

fans out via MultiLogRecordProcessor instead of forming a pipeline: each processor gets an independent copy of the record via OnEmit(), which transfers ownership. That means N copies of the record (N times the recording cost) and the exporter at the end receives the raw, unfiltered/unsanitized record rather than the output of the upstream stages, since mutations made by an earlier stage are made on a copy that is then discarded.

See the full discussion: https://github.com/open-telemetry/opentelemetry-cpp/pull/4309#pullrequestreview-4953987049 and https://github.com/open-telemetry/opentelemetry-cpp/pull/4309#discussion_r3798294882

Scope

  • Standardize SDK built-in exporters (OTLP, ostream) on a ReadWriteLogRecord-style recordable.
  • New processor interface for composable pipeline processors that mutate data in place without owning the recordable lifecycle.
  • New root-level processor implementing a pipeline of these composable processors.
  • LoggerContext support for installing this new root processor.
  • Once the above lands, implement EventToSpanEventBridgeProcessor against the new interface and reintroduce it into declarative configuration (currently the config model/parser accepts the event_to_span_bridge processor block, but SdkBuilder only logs a warning that it is not yet supported; see the FIXME-SDK comment in sdk_builder.cc).

Status

Pending design and implementation of the components above. #4309 was scoped down to just the configuration model and YAML parser per this discussion, with the actual processor implementation deferred until this issue is resolved.

Lingua principale
C++
Stelle
1.4k
Fork
647
Merge medio
1g 10h
PR unite (30g)
74

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 open-telemetry/opentelemetry-cpp

Tutte le issue di open-telemetry/opentelemetry-cpp

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.