Create Jaeger agent OpenTelemetry distribution

[pavolloffay]

Similar to Jaeger OpenTelemetry collector https://github.com/jaegertracing/jaeger/tree/master/cmd/opentelemetry-collector we should create Jaeger agent based on OpenTelemetry collector.

There will be also ingester and probably all-in-one based on OTEL collector. Question is whether we should create a separate image for each of these components or have a single image that switches configuration based on a property (env var, flag...)

cc) @jaegertracing/jaeger-maintainers

[objectiser]

One of the reasons for having different images, especially a distinct agent image, may be size. Would it be possible to quantify the size difference between collector (with storage exporters) vs stripped down agent image?

[pavolloffay]

There won't be a major difference, the storage implementations are just a couple of classes. The bigger difference would be if we packaged static UI files for the query service. We probably won't do it as the query can be implemented as a separate service.

# OTEL upstream collector
76M	./bin/otelcol_linux_amd64
# Jaeger OTEL collector
87M	./cmd/opentelemetry-collector/opentelemetry-collector-linux

[objectiser]

Doesn't look too bad at the moment - I wasn't sure how much of an increase the transitive dependencies would pull in.

This also may be an issue in the future as we may include other receivers, processors, extensions, exporters from the opentelemetry-collector-contrib repo (or other places), so something to bear in mind.

However we could just create a smaller agent image in the future if it starts becoming an issue.

[yurishkuro]

-rwxr-xr-x 1 ys staff 40M Feb 28 20:47 collector-linux*

So Jaeger version of collector is half the size, while having support for 3 external storage engines. Where's all this bloat coming from in OTEL?