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