out_opentelemetry: add header_tag / headers_key dynamic header support (like out_http)

Aperta
  • Qualcosa non va?
#12,722 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
api, backend

Direzione di ricerca

Start with the out_opentelemetry output implementation and its configuration definitions, then read plugins/out_http/http.c for the existing header_tag and headers_key behavior. Check how OTLP requests are batched, especially the batching discussion in issue #7206, before deciding how record derived headers apply per chunk. Done means both options work with the documented semantics and tests cover them, including the chosen batching behavior.

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

Descrizione

Problem

out_opentelemetry only supports a static header option
(FLB_CONFIG_MAP_SLIST_1). There is no way to set a per-request or tag-derived
HTTP header.

Users who need to route OTLP data by tag are forced to write one complete
[OUTPUT] block per tag, where the outputs differ only in a single header
value. This does not scale when there are many services/tags.

Use case

OpenObserve selects the destination stream for OTLP logs using the
stream-name HTTP header (defaults to default). To send each Fluent Bit tag
to its own OpenObserve stream today you must duplicate the output once per tag:

[OUTPUT]  name opentelemetry  match app_a  header stream-name app_a  ...
[OUTPUT]  name opentelemetry  match app_b  header stream-name app_b  ...

This is the same problem out_http already solves with header_tag (a header
whose value is the tag) and headers_key (a header map read from a record
field).

Proposal

Add the same two options to out_opentelemetry:

  • header_tag <NAME> — add an HTTP header named <NAME> whose value is the
    current tag. Example: header_tag stream-name.
  • headers_key <KEY> — read a map of headers from record field <KEY> and
    apply them per request (same semantics as out_http).

With header_tag, the OpenObserve case above becomes a single output:

[OUTPUT]
    name        opentelemetry
    match       *
    header_tag  stream-name

Reference

out_http already implements both:

  • header_tag — plugins/out_http/http.c
  • headers_key — plugins/out_http/http.c (extract_headers reads
    record[<key>])

Notes

  • header_tag maps naturally to OTLP batching (the tag is constant per chunk).
  • headers_key may require batching/grouping records by header value (see
    https://github.com/fluent/fluent-bit/issues/7206 for how out_http handled
    batching), or limiting it to per-chunk semantics.

Current workaround

  1. One [OUTPUT] per tag (N duplicated outputs), or
  2. Carry the identity in OTLP resource attributes (e.g. service.name) and
    split on the backend side (e.g. OpenObserve pipeline with a {service.name}
    dynamic stream).
Lingua principale
C
Stelle
8.2k
Fork
2k
Merge medio
3g 20h
PR unite (30g)
99

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 fluent/fluent-bit

Tutte le issue di fluent/fluent-bit

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.