feat: add mock data capabilities

[MichaHoffmann]

Required for all PRs

• [ ] Updated associated README.md.
• [ ] Wrote appropriate unit tests.
• [ ] Pull request title or commits are in conventional commit format

A draft of how to quickly test what metrics a configuration will emit. This PR adds a MockInput interface, types that implement it can be used in a config that uses mock = true and are able to emit metrics without talking to a backend. This can be gradually added.

[powersj]

Hi,

I see this is a draft, but I was curious: have you thought about using the exec or even file inputs? You can put whatever mock metrics you want in there, like copy and paste from the plugin's readme, and then run with that, for example.

[reimda]

Hi @MichaHoffmann, adding mock data functionality to telegraf is an interesting idea but I have some concerns about it. The approach this PR takes requires all inputs to implement a MockGather() method that returns metrics of the same as Gather(). If it's optional, I doubt plugin contributors will write it.

If they do write it, I suspect it won't match the real Gather closely enough to be useful. Some mock use cases require the metric format to be the same, some use cases need timing, some need size. Getting all these right for everybody is not trivial. If it's not accurate, it will be a source of frustration for users.

Writing an accurate MockGather will be difficult or very difficult for most plugins. For example, some plugins gather metrics from multiple versions of a service. Take the mysql input: it handles multiple versions of mysql and mariadb. To mock that accurately, there will have to be mock settings to say which type and version of the service you're mocking. There are plugins that gather metrics from very complex services, so there would need to be many mock settings.

Some of the most popular plugins are listeners, aka service inputs. Socket_listener accepts data in any of the parser formats. snmp_trap can receive any type of traps. I wouldn't like to try to mock them.

Even if the plugin's MockGather is accurate, it still needs to be kept up to date with future changes too Gather. This makes writing and reviewing bugfixes and new features more difficult.

I don't think generating mock data is going to be worth it.

Instead of generating mock data, I would recommend configuring telegraf in a test environment that has the correct versions of services you gather from, then running telegraf and recording the output to make a test metric dataset. @powersj recommended using a file output to save and file input to play back. That would work well for many use cases. If you need the playback timing to be accurate, you may need to use a tool that records timestamps and uses them when playing back. There are lots of tty oriented recording tools like script/replay, termrec, and ttyrec. They might be able to be used along with the execd plugins to record and play back timed metrics.

@MichaHoffmann I think we need to understand your use case better before we proceed. How you would like to use mocked data? What problem are you trying to solve?

Your PR descriptions says "how to quickly test what metrics a configuration will emit". Each plugin's documentation is supposed to include example output. (like https://github.com/influxdata/telegraf/tree/master/plugins/inputs/cpu#example-output) Does that give you the information you need?

[telegraf-tiger[bot]]

Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Page. Thank you!