Skip to content

enchancement(internal_logs_source)!: decouple internal_logs log level from vector startup log level#25776

Open
dekelpilli wants to merge 2 commits into
vectordotdev:masterfrom
dekelpilli:internal_logs-configurable-log-level
Open

enchancement(internal_logs_source)!: decouple internal_logs log level from vector startup log level#25776
dekelpilli wants to merge 2 commits into
vectordotdev:masterfrom
dekelpilli:internal_logs-configurable-log-level

Conversation

@dekelpilli

@dekelpilli dekelpilli commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Summary

This PR should close #12399. It allows individual internal_logs sources to configure their own minimum log level, instead of being tied to Vector's startup config from flags/environment variables.

Vector configuration

[sources.internal_logs]
type = "internal_logs"
level = "debug"

[transforms.internal_logs_remap]
type = "remap"
source = ".abc = s'static-value'"
inputs = [
    "internal_logs",
]

[sinks.internal_logs_serr]
inputs = [
    "internal_logs_remap",
]
target = "stderr"
type = "console"

[sinks.internal_logs_serr.encoding]
codec = "json"

How did you test this PR?

I ran vector locally against the above config, changing its level = "debug" throughout, with various VECTOR_LOG levels configured.

Change Type

  • Bug fix
  • New feature
  • Dependencies
  • Non-functional (chore, refactoring, docs)
  • Performance

Is this a breaking change?

  • Yes
  • No

This is only a breaking change for users who ran vector with a non-default log level (-q/-v/VECTOR_LOG=) and relied on that log level for configuring their internal_logs source(s). Not necessarily a significantly breaking change, but still worth mentioning.

Does this PR include user facing changes?

  • Yes. Please add a changelog fragment based on our guidelines.
  • No. A maintainer will apply the no-changelog label to this PR.

References

Notes

  • Please read our Vector contributor resources.
  • Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
  • Some CI checks run only after we manually approve them.
    • We recommend adding a pre-push hook, please see this template.
    • Alternatively, we recommend running the following locally before pushing to the remote branch:
      • make fmt
      • make check-clippy (if there are failures it's possible some of them can be fixed with make clippy-fix)
      • make test
  • After a review is requested, please avoid force pushes to help us review incrementally.
    • Feel free to push as many commits as you want. They will be squashed into one before merging.
    • For example, you can run git merge origin master and git push.
  • If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
    run make build-licenses to regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.

@dekelpilli dekelpilli requested review from a team as code owners July 8, 2026 10:59
@github-actions github-actions Bot added docs review on hold The documentation team reviews PRs only after a PR is approved by the COSE team. domain: sources Anything related to the Vector's sources domain: external docs Anything related to Vector's external, public documentation labels Jul 8, 2026

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 57bd04dc96

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread src/sources/internal_logs.rs Outdated
// The broadcast channel feeding all `internal_logs` sources is filtered at the most
// verbose level requested by any such source; events below this source's own level are
// dropped from its stream in `run`.
crate::trace::raise_broadcast_max_level(self.level.into());

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Raise the broadcast level before source build

When internal_logs.level is set to debug or trace, this raise happens only while the source is being built, but tracing is initialized earlier in App::prepare_from_opts before config loading and topology/source construction. Any DEBUG/TRACE events emitted during config load or before this build call are filtered out by the initial INFO broadcast filter and never enter the early buffer, so a level = "trace" source still misses verbose startup logs it is meant to collect. The new tests only emit after start_source_with_config, so they don't cover this startup window.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The startup log level is now based on Vector's flags (-v/-q/VECTOR_LOG=), instead of being hard coded to info. There's no solution here that satisfies all cases:

  • If we make the default level trace, we unnecessarily process lots of logs during startup, even if there's no internal_logs source at all. This seems like a pretty steep cost for a very niche win.
  • For any other static value, a level = "trace" source will miss out on startup logs
  • Relying on Vector's flags, as I've chosen to do in the latest commit, means that if you run VECTOR_LOG=off, you won't catch any of the startup logs via the source.

Given these tradeoffs, I'm happy to go with any of these options, but I'd lean towards the last one

Comment thread src/trace.rs Outdated
/// subscriber was installed before the source was built.
pub fn raise_broadcast_max_level(level: LevelFilter) {
let new = level_filter_to_usize(level);
let old = BROADCAST_MAX_LEVEL.fetch_max(new, Ordering::SeqCst);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Recompute the broadcast level instead of only raising it

Because this uses fetch_max with no matching path to lower or reset the global level, a hot reload that removes a trace/debug internal_logs source or lowers it to info/error leaves the broadcast layer permanently enabled at the old verbose level. From then on, even accepted configurations that no longer request verbose internal logs still pay to enable those callsites, convert events to LogEvent, and send them through the broadcast path until process restart.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't considered config reloading. This is now fixed.

Comment thread src/trace.rs
static BROADCAST_MAX_LEVEL: AtomicUsize = AtomicUsize::new(DEFAULT_BROADCAST_MAX_LEVEL);

/// The default broadcast verbosity (3 = `INFO`).
const DEFAULT_BROADCAST_MAX_LEVEL: usize = 3;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Don't enable INFO broadcast work when no source requests it

The broadcast filter now starts at INFO unconditionally, before the config is known. In runs with VECTOR_LOG=off/--quiet and no internal_logs source, or with only level = "error"/"warn" sources, INFO callsites are still enabled for this layer; during startup they are converted into LogEvents and buffered because the early buffer is present, and after startup each event still enters BroadcastLayer and checks the buffer/sender before being dropped. Previously the broadcast layer used the console filter, so those callsites stayed disabled in these environments.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to discussion at #25776 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs review on hold The documentation team reviews PRs only after a PR is approved by the COSE team. domain: external docs Anything related to Vector's external, public documentation domain: sources Anything related to the Vector's sources

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Decouple internal_logs from log configuration

1 participant