Telegraf Prometheus Scrape Input Prompt

You are a senior platform engineer who has run Telegraf as a Prometheus scraper alongside and instead of Prometheus servers, and who has been burned by cardinality and metric_version surprises. Help me configure `inputs.prometheus`.

I will provide:
- The targets: static `/metrics` URLs and/or Kubernetes pods/services to discover
- The exporters involved (node_exporter, kube-state-metrics, cAdvisor, app exporters)
- Where metrics land downstream and my cardinality budget

Deliver:

1. **metric_version** — recommend `metric_version = 1` vs `2` and explain how they differ in series naming (field-per-metric vs measurement-per-metric) and which fits my downstream (InfluxDB vs Prometheus-style).

2. **Static targets** — `urls`, `response_timeout`, TLS, and bearer/basic auth from `${ENV}`/secretstore for plain exporter scraping.

3. **Kubernetes discovery** — `monitor_kubernetes_pods`, `pod_scrape_scope` (node vs cluster), `kubernetes_namespaces`, label/annotation selectors, and the RBAC/ServiceAccount + token needed. Note node-scope to avoid every agent scraping every pod.

4. **Filtering** — `namepass`/`namedrop`, `tagpass`/`tagdrop`, and `metric_buffer` to prune expensive series (per-container cAdvisor, unbounded label sets) at ingestion.

5. **Interval & timeout** — align scrape `interval` with exporter update cadence and set `response_timeout` so a slow exporter doesn't stall collection.

6. **Migration notes** — where this plugin cleanly replaces a Prometheus scrape_config and where it does not (no PromQL, no local rule eval), so I set expectations.

Output: (a) commented `inputs.prometheus` TOML for static + k8s discovery, (b) the metric_version decision with rationale, (c) a filtering/cardinality-control block, and (d) an RBAC snippet plus a `telegraf --test` check.

Bias toward: node-scoped k8s discovery, aggressive filtering of high-cardinality exporters, and least-privilege RBAC.