Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#708 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@arunimshukla 已经在做这个了。

开始于 2026年9月23日。

  • #714 来自 @arunimshukla —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
observability

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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

主要语言
Rust
星标
8
派生
5
平均合并
4 天 18 小时
30 天内合并 PR
4

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NethermindEth/pluto 的其他 Issue

查看 NethermindEth/pluto 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。