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

Global `EnvFilter` prevents topic spans from being constructed at the default log level

Aperta
  • Qualcosa non va?
#708 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

@arunimshukla ci sta già lavorando.

Dal 23/9/2026.

  • #714 di @arunimshukla — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
observability

Direzione di ricerca

Start in crates/tracing/src/init.rs, especially the subscriber construction around lines 90-93 and default_env_filter, then inspect crates/tracing/src/layers/metrics.rs and the existing tracing tests. Run the real pluto_tracing::init stack at the default info level and verify that topic labels are retained while console and Loki verbosity still follow --log-level. Add a regression test covering warn/error metrics and their topic labels.

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

Descrizione

bug rust

Summary

EnvFilter is attached as a global layer on the subscriber stack, so it gates Subscriber::enabled for every layer — including MetricsLayer: init.rs#L90-L93.

Every topic span in the workspace is DEBUG-level, and the default --log-level is info (common.rs#L103, default_env_filter). At info the span is never constructed, MetricsLayer::on_new_span never fires, no SpanTopic extension is stored, and event_topic walks an empty scope.

Result: 100% of warn/error events are counted under topic="" at the default configuration. The topic mechanism only works under RUST_LOG=debug.

Evidence

Probed against the real MetricsLayer, both directions:

subscriber stack console filter debug_span! constructed app_log_warn_total label
EnvFilter global (current) info no (is_disabled=true) topic=""
EnvFilter global (current) debug yes topic="<name>"
EnvFilter on fmt only + MetricsLayer.with_filter(LevelFilter::DEBUG) info yes topic="<name>"

The third row is the proposed fix: the console still emits at info (the WARN printed normally), while the metric keeps its label.

Scope

This predates the topic work and is not caused by it. It already affects the two topics on main — health and stacksnipe — and will silently neutralise all 17 topics once #588 / #669 lands.

Why it matters

  • app_log_{warn,error}_total{topic} is the only per-component signal for warn/error rate. With one label value it answers no question that the unlabelled counter does not already answer — which is exactly what #588 set out to fix.
  • Generated alert rules are silently degraded. define.rs#L375 builds increase(app_log_warn_total{topic!~"vmock|tracker"}[30s]) > 2. Against a pluto node every series carries topic="", which matches !~"vmock|tracker" — so the exclusion never excludes anything and the rule is strictly more trigger-happy than intended. This directly undercuts the re-validation planned in #583.
  • Grafana panels collapse. dash_charon_overview.json#L1701-L1714 aggregates by (topic); pluto contributes a single empty series next to charon's ~20.
  • It blocks #47 (app/tracer). The same global filter drops debug-level spans before they can reach an OTLP exporter, so an OTel integration inherits the problem rather than working around it.

Charon contrast

The counter is level-independent by construction: incWarnCounter(ctx) is the first statement of log.Warn, before the logger is consulted — log.go#L107-L108, same for log.Error. Charon's topic rides on context.Context, so console verbosity and metric labelling are independent concerns. Pluto couples them through the span, which is what makes the filter placement load-bearing.

Proposed fix

Move EnvFilter off the subscriber and onto the layers that should honour the operator's verbosity — fmt and Loki — and give MetricsLayer its own LevelFilter::DEBUG filter so topic spans are always materialised:

let registry = Registry::default()
    .with(fmt_layer.with_filter(env_filter))
    .with(MetricsLayer.with_filter(LevelFilter::DEBUG));

Loki needs the same treatment (it currently sits behind the global filter too), and EnvFilter is not Clone, so the filter has to be built per layer from the same directive string.

The alternative — promoting every topic span to info — is a smaller diff but makes span names visible in default console output and leaves the counter level-dependent, which is the coupling charon does not have.

Acceptance

  • app_log_{warn,error}_total carries its topic label with the subscriber built by pluto_tracing::init at the default info level.
  • A regression test in crates/tracing pins this against the real layer stack, not a hand-built one.
  • --log-level still controls console and Loki verbosity exactly as before.

Context

Diagnosed while reviewing #669; see this comment for the original analysis. Related: #588 (topic labels), #631 (span propagation), #583 (alert-rule re-validation), #47 (app/tracer).

Lingua principale
Rust
Stelle
8
Fork
6
Merge medio
4g 20h
PR unite (30g)
21

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 NethermindEth/pluto

Tutte le issue di NethermindEth/pluto

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.