Opening up telemetrygen for integration and unit testing

[Erog38]

Component(s)

cmd/telemetrygen

Describe the issue you're reporting

I would love to open up telemetrygen's metric, logs, and trace generation in order to make them usable from integration tests written in Go. This would allow for a pattern such as:

1. Create a receiver with a test sink consumer
2. Execute built collector binary
3. Initiate telemetry generation using libraries rather than calling the CLI tool
4. Validate signals received to the test sink consumer

Using this patten, we can write telemetry through a running collector and validate the collector has processed them as expected per a provided configuration.

It also allows for validating integration testing of a collector which contains custom components.

This would require the Start functions in the telemetrygen internal/[metrics,logs,traces] packages to become exported, as well as their configurations.

[github-actions]

Pinging code owners:

• cmd/telemetrygen: @mx-psi @codeboten

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[atoulme]

1. ok
2. ok
3. why would you not use the telemetrygen binary or docker image at this point? you are pointing at a built collector anyway, so you can even use a docker-compose for this.
4. telemetrygen doesn't help with that.

I don't see a compelling reason to open the API to run telemetrygen here. You might also like to send specific metrics/traces/logs a finite number of times, telemetrygen just blasts constantly.

Here is an example you can follow: https://github.com/signalfx/otlptest/blob/main/main.go

[Erog38]

I appreciate your feedback on this one, the main key here running the tests via integration build tags in order to run with as little additional complexity as possible. Opening up this API would allow for us to leverage the existing capabilities in telemetrygen without statically creating a number signals as the example you've posted.

I could write and use a wrapper around telemetrygen which ensures the local install and can execute it appropriately, but it creates a lot of undue overhead compared to building against the current version which gets tagged and released with the rest of the collector components it works against.

As far as maintaining the API stability, I feel your pain and am happy to help however possible here. Telemetrygen already has a published public interface in regards to the command line flags and expected parameters which align with the expected config, and the exported Start and Run functions haven't changed in some time, but I'd be happy to refactor them to make API stability simpler with variadic optional parameters in the function calls.

[Erog38]

Per our conversation on slack, I have approval from my org to take this on in an official capacity from Yahoo and am happy to take up ownership if you're open to it.