Add Go Auto-instrumentation application

[rogercoll]

Feature Request

Add a new Go service (or migrate a current one) that can be auto-instrumented with Go: https://github.com/open-telemetry/opentelemetry-go-instrumentation.
The Dockerfiles can reuse the image provided by the Operator: https://github.com/open-telemetry/opentelemetry-go-instrumentation/pkgs/container/opentelemetry-go-instrumentation%2Fautoinstrumentation-go

Is your feature request related to a problem?

No available example for Go auto-instrumentation.

Describe the solution you'd like:

The Go auto-instrumentation is based on eBPF, meaning that it will only work in Linux environments. The service could be marked as optional and only deploy it on these environments. Note that only a few libraries are compatible with the auto-instrumentation tool:

• database/sql
• github.com/segmentio/kafka-go
• google.golang.org/grpc
• net/http

Any idea for the example app?

[julianocosta89]

I don't like the idea of having a service that just works in one specific environment.

We could maybe have a separate file with this:
https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/productcatalogservice/main.go#L83-L130

Add an if to the main function and pass the OS via build-arg, env var or something like that. Than we do the decision to add the manual file, or to add the auto-instrumentation.

WDYT?

Does that make sense? Do you think this is doable?

[rogercoll]

That seems it should work. My main concern will be regarding the docker-compose and Helm Charts, the Go auto instrumentation works as a sidecar container, meaning that we will need to modify the deployment files depending on the environment. And I agree with you, I would rather prefer to have a unified deployment experience than having different configurations depending on the environment.

There is an ongoing idea about moving this sidecar container to a collector's receiver, which I think it would simply our deployment files open-telemetry/opentelemetry-go-instrumentation#1026