[nicolastakashi]

Summary

This continues the incremental refactor to make node_exporter easier to embed outside the standalone binary.
The broader goal is to support ongoing work to make Prometheus exporters embeddable inside the Prometheus OpenTelemetry Collector distribution as native receivers, without requiring each exporter to be rewritten as an OpenTelemetry component.
This PR builds on the reusable config package by adding a runtime layer that downstream callers can construct directly from config, independent of CLI parsing and HTTP serving.
Specifically, this PR:

• adds collector.Runtime as a reusable wrapper around NodeCollector
• validates reusable config at runtime construction time
• exposes embeddable APIs for:
  • collector access via Collectors()
  • registry creation via Registry()
  • enabled collector discovery via EnabledCollectors()
• adds unit tests covering runtime construction, validation, and registry gathering

Why

Today, node_exporter collector construction is tied closely to the binary wiring. Introducing a reusable runtime layer is a small but important step toward separating:

• binary concerns such as flags, HTTP serving, and process setup
• reusable exporter concerns such as config validation, collector construction, and metric registry assembly
  This does not make node_exporter fully embeddable yet. In particular, collector-specific process-global configuration and state still need follow-up refactors. The intent here is to establish a reusable runtime API that future changes can build on.

Stack

This PR is part of a stacked series:

• depends on Remove boilerplate code by adopting exporter-toolkit's bootstrap.Runner() #3660
  Only the runtime layer is intended to be reviewed here; the CLI wiring changes will come in a follow-up PR.

[nicolastakashi]

Relates to prometheus/opentelemetry-collector-bridge#41

[nicolastakashi]

Resolves: prometheus/opentelemetry-collector-bridge#60

[ArthurSens]

Anything I could do to unblock this PR? :)

[nicolastakashi]

@ArthurSens PTAL

[ArthurSens]

Good start :)

I noticed a bug with collector state still depending on global variables, which prevent us from doing something like this:

receivers:
  nodeexporter/cpu:
    scrape_interval: 10s
    exporter_config:
      collectors:
        cpu: true
        filesystem: false
        # Other collectors disabled.

  nodeexporter/filesystem:
    scrape_interval: 60s
    exporter_config:
      collectors:
        cpu: false
        filesystem: true
        # Other collectors disabled.

because both runtimes would be overriding each others enabled collectors state

[ArthurSens]

I believe the collectors' enable/disabled state also needs to be part of the runtime object so multiple runtimes don't affect each other.

[ArthurSens]

These configuration options don't seem related to configuring the metric collection, could we leave them out?

[ArthurSens]

This one also seems unrelated to metric collection

[ArthurSens]

Besides enabling/disabling collectors, it seems like we're missing a lot of config pieces that are specific to one single collector that also need to be here.

For example, we have --collector.textfile.directory, and this isn't present here, therefore we won't be able to configure this option whem embedding node exporter

[ArthurSens]

You can take a look at another similar PR in another exporter: prometheus/mysqld_exporter#1043

we have things like this:

type Config struct {
    Collectors            map[string]bool
    InfoSchemaProcesslist InfoSchemaProcesslistConfig
    // ...
}

type InfoSchemaProcesslistConfig struct {
    MinTime         int
    ProcessesByUser bool
    ProcessesByHost bool
}

where infoSchemaProcesslistConfig is one of many collectors in MySQL exporter