Feature request: Let Telegraf start unconfigured instead of shipping a default output

Use case

Out of the box, Telegraf refuses to start unless the config has at least one input and one
output. On a fresh install this means the packaged config either has to bundle a working output
or the service fails on first boot, which is a poor first-run experience and the subject of
#16718. It also gets in the way of deployment chains (Ansible and similar) that install the
package first and push the real config in a later step: the service will not come up until
something is configured.

The obvious quick fix, making a real output the default in the packaged config, has a hidden
cost. make config generates the shipped telegraf.conf from the same defaults, post-install on
deb/rpm copies that sample to the live config on a fresh install, and systemd runs it. So any
default output we pick starts sending every metric somewhere from first boot on every new install
(stdout to the journal, in the case explored in #19219), and we would be committing every user to
a destination they never chose.

Proposed behaviour

Rather than pick a default output, let Telegraf start with no configuration at all and warn
loudly. The startup gate (cmd/telegraf/telegraf.go:450-451, the len(c.Outputs) == 0 check)
becomes three cases:

1. No plugins configured, and the config is the default path with nothing given explicitly: start
   with a prominent warning, for example "Telegraf is starting unconfigured and will not collect
   any data. Please configure your inputs and outputs." Repeat the warning periodically (once per
   interval or a slower timer) so it does not just scroll out of the journal and leave the host
   looking healthy while it collects nothing.
2. At least one plugin configured but no inputs, or no outputs: keep the current error.
3. At least one input and at least one output: OK, unchanged.

An explicit --config or --config-directory that resolves to zero plugins should stay in case
2 (error), not fall into case 1. Zero plugins from an explicit path usually means the config
failed to load, a typo in the directory, a bad glob, or wrong permissions, and we do not want real
misconfiguration to start green and quiet. Case 1 is specifically "default path, nothing loaded".

The existing --test / --once special-casing stays as is.

Follow-on packaging change

With unconfigured start working, we no longer need to deliver a default telegraf.conf. A fresh
install with no config lands in case 1 and runs with the warning. This also lets us remove the
default config files, which closes #18961.

Note for the release: fresh installs would no longer get a starter telegraf.conf, so users who
want one run telegraf config. Existing installs are unaffected, since post-install only copies
the sample when no config is present.

Related

• resolves #16718
• resolves #18961
• supersedes #19219

Notes

Splitting this into two PRs keeps each reviewable: first the agent startup change (the three-case
logic plus the repeating warning), then the packaging change that stops delivering the default
config. Thanks to @calvinmachado20 whose PR #19219 surfaced this.

Start at the startup gate in cmd/telegraf/telegraf.go:450-451 and trace how the default path, explicit config paths, and --test/--once are distinguished. Then inspect make config and the deb/rpm packaging paths mentioned in the issue. Done means the three startup cases behave as specified, the unconfigured warning repeats, and the default config is no longer delivered in the follow-on packaging change.