Choose and Design the Right Telegraf Input Plugin for a Source

You are a senior observability engineer who has instrumented hundreds of sources with Telegraf and knows the tradeoffs between native plugins, `http`, `prometheus`, `exec`/`execd`, and `tail`. Help me choose the right input plugin for a new source and design its configuration.

I will provide:
- The source: what it is (a service, host, cloud API, log file, message queue, database, or device), how it exposes data (HTTP endpoint, Prometheus `/metrics`, JSON API, CLI/script output, log lines, SNMP, JMX), and roughly how many metrics/series it produces
- Constraints: collection frequency I need, auth requirements, where the agent runs (host, container, DaemonSet), and any existing conventions (tag keys, naming)
- What I actually want to measure and alert on from this source

Deliver:

1. **Plugin selection** — recommend the single best input plugin and name the runner-up, with a short, concrete rationale. Prefer a native/first-class plugin (e.g. `inputs.postgresql`, `inputs.redis`, `inputs.docker`) over a generic `http`/`exec` wrapper when one exists, and explain the maintenance and data-quality reasons why. Call out when `prometheus` scrape or `http` + a parser is the honest right answer.

2. **Parser choice** — if the plugin needs a `data_format` (`json_v2`, `influx`, `prometheus`, `value`, `grok`), specify it and the exact parser config: which JSON paths or log fields become tags vs fields, timestamp handling, and type coercion. Flag anything that would land as a string when it should be a number.

3. **Tag and field design** — list the tag keys that identify the series (host, instance, source-specific dimensions) and the fields that carry values, keeping cardinality bounded. Explicitly name any field that would explode cardinality if tagged (IDs, UUIDs, URLs) and how to drop or bucket it.

4. **Interval and cost** — recommend a per-plugin `interval` sized to the source's freshness needs and cost, with the arithmetic for series × interval, and note when to give this input its own longer interval rather than slowing the whole agent.

5. **Auth and secrets** — show how to inject credentials via `${ENV}` or a secretstore, TLS settings if the endpoint is remote, and least-privilege scoping for any token or DB user.

6. **Resilience** — set `timeout`, and where relevant `name_override`, `tagexclude`/`fielddrop`, and error handling so one bad target or slow response doesn't stall collection.

Output as: (a) the plugin recommendation with rationale and runner-up, (b) a commented `[[inputs.<plugin>]]` TOML block ready to drop into telegraf.conf, (c) a table of the resulting tag keys and their cardinality, and (d) a `telegraf --test` validation command plus what a healthy first output line should look like.

Bias toward: native plugins over shell-outs, bounded cardinality, secret injection over inline strings, and validating against one target before rollout.