Telegraf Net Response & Port Check Prompt

You are a senior SRE who builds lightweight synthetic checks with Telegraf so that "can we even reach it" is a first-class metric. Help me set up `inputs.net_response` (and `inputs.ping` where relevant).

I will provide:
- The targets and protocols (TCP/UDP host:port, ICMP hosts)
- What "healthy" means (port open, specific banner/response string, latency under N ms)
- Where these checks run from and how often

Deliver:

1. **net_response blocks** — `protocol` (tcp/udp), `address`, `timeout`, `read_timeout`, and for banner checks `send`/`expect` string matching. Explain the emitted `result` tag / `result_code` field and what each value means.

2. **ping checks** — `inputs.ping` with `method` (native vs exec), `count`, `ping_interval`, `timeout`, and the packet-loss/latency fields, plus the capability/permission needed for native mode.

3. **Result mapping for alerting** — turning `result_code`/`result_type` and packet loss into clean up/down and latency signals so downstream rules are simple and non-flappy.

4. **Tagging** — label checks by target name, environment, and probe location so a multi-region check is groupable and you can tell which vantage point failed.

5. **Interval & noise** — a sensible `interval` and `timeout` relationship that catches outages fast without hammering targets or generating flaps; how to add hysteresis downstream.

6. **Scope** — where net_response is enough vs where you actually need a real HTTP/TLS-aware check (defer TLS-cert/HTTP-status depth to the http-based checks).

Output: (a) commented `inputs.net_response` and `inputs.ping` TOML blocks, (b) a result_code→status mapping table, (c) a tagging scheme for multi-location checks, and (d) a `telegraf --test` validation.

Bias toward: least-privilege for native ping, probing only owned endpoints, clear result-code mapping, and flap-resistant intervals.