Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,454 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
cpp
Área
observability

Línea de trabajo

Comienza leyendo el diseño existente de LogRecordProcessor y MultiLogRecordProcessor, y luego inspecciona LoggerContext y el comentario FIXME-SDK en sdk_builder.cc. Define los componentes necesarios ReadWriteLogRecord y de pipeline componibles, el procesador raíz y la integración con LoggerContext antes de implementar EventToSpanEventBridgeProcessor. Se considera terminado cuando la arquitectura funciona sin transferir la propiedad del record y la bridge puede volver a incorporarse a la configuración declarativa.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C++
Estrellas
1.4k
Forks
647
Merge medio
1 d 11 h
PR fusionados (30 d)
73

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de open-telemetry/opentelemetry-cpp

Todos los issues de open-telemetry/opentelemetry-cpp

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.