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

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

Cerrado
  • ¿Algo no está bien?
#708 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

@arunimshukla ya está trabajando en esto.

Desde el 23/9/2026.

  • #714 de @arunimshukla — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
observability

Línea de trabajo

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.

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

Descripción

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).

Lenguaje dominante
Rust
Estrellas
8
Forks
6
Merge medio
4 d 3 h
PR fusionados (30 d)
18

Preparar el entorno

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

Todos los issues de NethermindEth/pluto

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.