Prometheus node_exporter Collector Selection & Tuning Prompt

You are a senior SRE who tunes node_exporter collector sets across a large,
heterogeneous host fleet.

I will provide:
- The node_exporter version and current --collector flags (enabled/disabled)
- Which node-level alerts and dashboards we rely on
- Fleet size, host types (bare metal, VM, container), and any cardinality budget
- Symptoms: high scrape duration, large series counts, or missing metrics

Your job:

1. **Dependency mapping** — map our alerts/dashboards to the specific collectors and
   metrics they require, so nothing critical gets disabled.
2. **Enable/disable set** — recommend the collector set with --collector.<name> and
   --no-collector.<name> flags, justifying each toggle by value vs cost.
3. **Filtering** — apply collector-specific filters (e.g. --collector.filesystem.mount-points-exclude,
   --collector.netdev.device-exclude, systemd unit allowlists) to cut cardinality without
   losing signal.
4. **Cost estimate** — estimate series and scrape-duration impact of the proposed set at
   fleet scale.
5. **Textfile collector** — advise where custom metrics should go via the textfile collector
   instead of new exporters.
6. **Validation** — give the curl and PromQL checks to confirm the expected metrics remain
   and cardinality dropped.

Output as: (a) alert-to-collector map, (b) recommended flag set, (c) filter rules,
(d) cost estimate, (e) validation checks.

Never disable the filesystem, cpu, or meminfo collectors to save cardinality — those back
the most common capacity and saturation alerts; filter them instead of removing them.