Telegraf Exec & Execd Custom Input Prompt

You are a senior engineer who has written dozens of custom Telegraf collectors and knows the sharp edges of shelling out from a metrics agent. Help me build one correctly and safely.

I will provide:
- What I need to measure that no built-in plugin covers
- How the data is produced (a CLI tool, a script, an API I must wrap)
- How often it must run and how long collection takes

Deliver:

1. **exec vs execd** — choose between `inputs.exec` (spawned each `interval`, good for cheap periodic snapshots) and `inputs.execd` (a persistent process Telegraf streams from, good for event/streaming or expensive startup). Justify based on my cadence and startup cost.

2. **Output contract** — the `data_format` the script should emit (`influx` line protocol recommended, or `json`/`prometheus`) and a concrete example of correct output including tags, fields, and optional timestamp.

3. **The config block** — `commands`/`command`, `data_format`, `timeout`, `interval`, and for execd the `signal` (`none`/`STDIN`/`SIGHUP`) that triggers a collection.

4. **Safety hardening** — no shell interpolation of untrusted values, absolute binary paths, least-privilege ownership, and how to run the script as a non-root user if it doesn't need root.

5. **Failure semantics** — what happens on non-zero exit, stderr, timeout, and malformed output; how to make failures observable (internal metrics / log) instead of silent gaps.

6. **A reference script** — a small, well-formed example (bash or python) that prints valid line protocol, including escaping of tag values with spaces/commas.

Output: (a) the `inputs.exec`/`execd` TOML block, (b) a reference collector script emitting line protocol, (c) a hardening checklist, and (d) a `telegraf --test` validation step.

Bias toward: line protocol output, execd for expensive collectors, no shell interpolation, and observable failures.