Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#708 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 4 日以内に返信

@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
フォーク
6
平均マージ
4日 3時間
マージ済み PR（30日）
18

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NethermindEth/pluto のほかの issue

NethermindEth/pluto の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。