[opampsupervisor] Enable emitting logs via the OTel sdk

[TylerHelmuth]

Description

Experiment with enabling the logs SDK for the opampsupervisor telemetry

Link to tracking issue

Fixes

Testing

Updated unit test and tested manually. Here are the logs being exported to Honeycomb

Documentation

[evan-bradley]

Would it be feasible to add a simple E2E test to verify we get these logs in an OTLP sink?

[evan-bradley]

On second thought, it would make more sense as a unit test since we're not starting a Collector binary, but it would be nice to have a smoke test to determine that setting this option has the intended effect.

[TylerHelmuth]

On second thought, it would make more sense as a unit test since we're not starting a Collector binary, but it would be nice to have a smoke test to determine that setting this option has the intended effect.

@evan-bradley what did you have in mind besides the adding to the Test_NewSupervisorWithTelemetrySettings test? It would be good to have some e2e tests for the opamp supervisor but that feels out of scope for this PR.

[evan-bradley]

I think we should be able to use something in the testbed package like MockBackend to receive OTLP and check that we're getting in data.

We actually do have a pretty extensive E2E test suite in e2e_test.go at the root of the Supervisor directory. It's for tests that require a Collector binary to run. I was thinking we could maybe run tests for the Supervisor's telemetry without needing a Collector, but if we do then it's fine if it's an E2E test instead of a unit test.

[TylerHelmuth]

I think we should be able to use something in the testbed package like MockBackend to receive OTLP and check that we're getting in data.

We'll need that for traces and metrics too. Do you want me to do that in this PR or in a followup?

[evan-bradley]

Agreed, I forgot to bring it up in the other PRs. Let's just do logs in this PR and tackle traces and metrics in a follow-up.

[TylerHelmuth]

@evan-bradley test added