feat: exporter toolkit bootstrap

[nicolastakashi]

Summary

This adds a new optional bootstrap package to exporter-toolkit for exporters that want a shared startup path for common process wiring. Today, many exporters duplicate the same startup concerns around:

• common web flags
• logger setup
• metrics path registration
• landing page wiring
• web.ListenAndServe integration

This PR introduces an additive package that can own those shared pieces without changing the existing web package API or forcing any current exporter to migrate.

Why

The goal is to reduce repeated startup code across exporters while keeping boundaries clear:

• web remains focused on transport/server concerns such as listeners, TLS, auth, and serving
• bootstrap owns higher-level exporter startup concerns such as flag registration, logging initialization, metrics endpoint wiring, and landing page setup

This is intentionally additive:

• exporters already using web.ListenAndServe can continue unchanged
• exporters can opt into bootstrap only if it simplifies their startup path
• this gives us a concrete shared layer for downstream adoption without requiring ecosystem-wide churn

A key design choice in this PR is keeping web.telemetry-path ownership in bootstrap, not in web.FlagConfig, so transport concerns and exporter routing concerns do not get mixed together. It also keeps the existing web startup path intact.

Startup Example

Without bootstrap:

metricsPath := kingpin.Flag(
	"web.telemetry-path",
	"Path under which to expose metrics.",
).Default("/metrics").String()
disableExporterMetrics := kingpin.Flag(
	"web.disable-exporter-metrics",
	"Exclude metrics about the exporter itself (promhttp_*, process_*, go_*).",
).Bool()
maxRequests := kingpin.Flag(
	"web.max-requests",
	"Maximum number of parallel scrape requests. Use 0 to disable.",
).Default("40").Int()
toolkitFlags := kingpinflag.AddFlags(kingpin.CommandLine, ":9100")
promslogConfig := &promslog.Config{}
flag.AddFlags(kingpin.CommandLine, promslogConfig)
kingpin.Parse()
logger := promslog.New(promslogConfig)

http.Handle(*metricsPath, newHandler(!*disableExporterMetrics, *maxRequests, logger))
if *metricsPath != "/" {
	landingPage, err := web.NewLandingPage(web.LandingConfig{
		Name:        "My Exporter",
		Description: "Prometheus My Exporter",
		Version:     version.Info(),
		Links: []web.LandingLinks{{
			Address: *metricsPath,
			Text:    "Metrics",
		}},
	})
	if err != nil {
		level.Error(logger).Log("err", err)
		os.Exit(1)
	}
	http.Handle("/", landingPage)
}

server := &http.Server{}
if err := web.ListenAndServe(server, toolkitFlags, logger); err != nil {
	level.Error(logger).Log("err", err)
	os.Exit(1)
}

With bootstrap:

runner := bootstrap.New(bootstrap.Config{
	App:            kingpin.CommandLine,
	Name:           "my_exporter",
	Description:    "Prometheus My Exporter",
	DefaultAddress: ":9100",
	MetricsHandlerFactory: func(b *bootstrap.Bootstrap) (http.Handler, error) {
		return newHandler(!b.DisableExporterMetrics, b.MaxRequests, b.Logger), nil
	},
})
if err := runner.Run(); err != nil {
	fmt.Fprintln(os.Stderr, err)
	os.Exit(1)
}

Notes

• This PR does not deprecate or remove the existing web startup flow.
• This PR does not try to model exporter-specific runtime config.
• This PR is intended to be proven by real downstream adoption, starting with node_exporter.

[SuperQ]

I think this is a continuation of #147

[nicolastakashi]

I think this is a continuation of #147

Should we get the first one merged first @SuperQ ?

[ArthurSens]

Really cool! This can be so easily applied to a lot of exporters :)

[ArthurSens]

LGTM, but let's see what exporter-toolkit maintainers have to say :)

[roidelapluie]

why is MetricsHandlerFactory: func(b *bootstrap.Bootstrap) (http.Handler, error) {
return newHandler(!b.DisableExporterMetrics, b.MaxRequests, b.Logger), nil
}, needed?

[nicolastakashi]

why is MetricsHandlerFactory: func(b *bootstrap.Bootstrap) (http.Handler, error) { return newHandler(!b.DisableExporterMetrics, b.MaxRequests, b.Logger), nil }, needed?

Good question @roidelapluie and I realized this is not so clear on the PR description.

The reason behind this is because the final handler might depend on values that are only available after bootstrap has parsed the common flags and initialized logging.

In the node_exporter integration, the handler is built from b.Logger, b.DisableExporterMetrics, and b.MaxRequests, e.g.: prometheus/node_exporter#3660

So the factory is the exporter-specific assembly point once the shared bootstrap state is resolved. Without it, callers would either have to duplicate bootstrap parsing/setup outside this package, or bootstrap itself would need to know how to construct exporter-specific handlers.

[ArthurSens]

One thing that I just thought about!

If all CLI flags are registered through this bootstrapping package, we could create a hidden kingpin command to print them all.

I believe almost all exporters in prometheus and prometheus-community have their CLI flags in the README, but they are updated manually. We could easily build the automation needed to keep the README and the real world in sync