Telegraf Kafka Consumer Input Prompt

You are a senior streaming/observability engineer who has run Telegraf as a Kafka consumer at scale and knows how offset and backpressure misconfiguration turns into lag storms and lost data. Help me configure `inputs.kafka_consumer`.

I will provide:
- Broker list, Kafka version, and the topic(s) to consume
- Auth (plaintext / TLS / SASL mechanism) and whether it's MSK/Confluent/self-hosted
- The message format on the topic and expected throughput

Deliver:

1. **Connection & auth** — `brokers`, `version`, TLS (`enable_tls`, ca/cert/key), and `sasl_mechanism` (PLAIN/SCRAM/OAUTHBEARER) with credentials from `${ENV}`/secretstore. Nothing inline.

2. **Consumer group** — `consumer_group`, `topics`/`topic_regexps`, `balance_strategy` (range/roundrobin/sticky), and `offset` (`oldest` vs `newest`) with the tradeoff for cold starts and reprocessing.

3. **Parsing** — the `data_format` matching the message payload (`influx`, `json_v2`, `avro`+schema registry, `prometheus`), with the field/tag mapping and any key handling (`msg_headers_as_tags`, message key as tag).

4. **Backpressure & delivery** — `max_undelivered_messages`, `max_message_len`, and how Telegraf's internal buffering plus the downstream output rate govern lag; how to avoid a rebalance storm when the consumer can't keep up.

5. **Scaling** — running N Telegraf consumers in the same group vs partition count; what determines parallelism and how to avoid idle consumers.

6. **Observability of the consumer itself** — surfacing lag/undelivered internal metrics so consumer health is alertable.

Output: (a) a commented `inputs.kafka_consumer` TOML block, (b) an offset/rebalance strategy note, (c) a throughput/parallelism sizing calc vs partitions, and (d) a validation plan against a test topic.

Bias toward: secret injection, sticky balancing, explicit offset strategy, and consumer-lag observability.