Discussion:
Bug#1080354: ITP: golang-opentelemetry-collector -- OpenTelemetry Collector (library)
Add Reply
Guillem Jover
2024-09-02 18:40:02 UTC
Reply
Permalink
Package: wnpp
Severity: wishlist
Owner: Guillem Jover <***@sipwise.com>

* Package name : golang-opentelemetry-collector
Version : 0.108.1-1
Upstream Author : OpenTelemetry - CNCF
* URL : https://github.com/open-telemetry/opentelemetry-collector
* License : Apache-2.0
Programming Lang: Go
Description : OpenTelemetry Collector (library)

The OpenTelemetry Collector offers a vendor-agnostic implementation on how
to receive, process and export telemetry data. In addition, it removes the
need to run, operate and maintain multiple agents/collectors in order to
support open-source telemetry data formats (e.g. Jaeger, Prometheus, etc.)
to multiple open-source or commercial back-ends.
.
Objectives:
.
* Usable: Reasonable default configuration, supports popular protocols,
runs and collects out of the box.
* Performant: Highly stable and performant under varying loads and
configurations.
* Observable: An exemplar of an observable service.
* Extensible: Customizable without touching the core code.
* Unified: Single codebase, deployable as an agent or collector with
support for traces, metrics and logs.


This package is required by new Prometheus and VictoriaMetrics releases.

Thanks,
Guillem
Jérôme Warnier
2025-01-16 11:30:01 UTC
Reply
Permalink
Hello,

Any news about this?
I would be interested in packaging this too, including contributing to
your effort.

Best regards,
Guillem Jover
2025-01-28 23:10:01 UTC
Reply
Permalink
Hi!
Post by Jérôme Warnier
Any news about this?
I would be interested in packaging this too, including contributing to
your effort.
Sorry, was working on all required dependencies, then got stuck at the
end because the latest upstream version was not even working with any
of the latest upstream dependencies, which were staged for a transition
by Reinhard Tartler (on CC), but do not have the details fresh in my
mind and would need to recheck IRC logs, but I'd say we should just go
ahead and then deal with the fallout. I think this specific problem
might now be fixed in the newer upstream releases for its dependencies
(AFAIR from when I looked into it at the time, which they fixed way
after they had done the breaking changes in the dependencies), but
have not had time to look into this again. Was planning to work on
this last week and this week, but part of my time went into dealing
with the workflow stuff.
This looks like yet another nightmarish CNCF monorepo package with extremely
enthusiastic git tagging habits.
Yes.
I just tried packaging 0.108.1-1 as indicated by this ITP, and found that it
failed to build due to what is probably a breaking change in one of the
other otel dependencies (which seems to be the case with literally every
release).
src/go.opentelemetry.io/collector/service/telemetry/tracer.go:59:15: cannot
use attributes(set, cfg) (value of type map[string]interface{}) as
[]config.AttributeNameValue value in struct literal
# go.opentelemetry.io/collector/service/internal/proctelemetry
undefined: config.MetricExporter
undefined: config.MetricExporter
invalid argument: otlpConfig.Endpoint (variable of type *string) for
built-in len
cannot use otlpConfig.Endpoint (variable of type *string) as string value in
argument to normalizeEndpoint
cannot use otlpConfig.Headers (variable of type
[]config.NameStringValuePair) as map[string]string value in argument to
otlpmetricgrpc.WithHeaders
invalid argument: otlpConfig.Endpoint (variable of type *string) for
built-in len
cannot use otlpConfig.Endpoint (variable of type *string) as string value in
argument to normalizeEndpoint
cannot use otlpConfig.Headers (variable of type
[]config.NameStringValuePair) as map[string]string value in argument to
otlpmetrichttp.WithHeaders
When the upstream developers break the API so often, I can kinda see why
they favour monorepos. I don't think I've ever seen another project with
such frequent breaking changes listed in their release notes. However, it
still seems that the three or four main otel repos are extremely tightly
coupled in terms of required version, which is going to be quite a headache.
So much for semantic versioning...
I suspect that the otel/collector package might need to target a slightly
newer release, in order to be compatible with the other main dependencies,
i.e. opentelemetry-contrib and opentelemetry-otel.
I'll try to refresh my memory on what was the state of this from some
months ago, as this is a required dependency for both Prometheus and
VictoriaMetrics.

Thanks,
Guillem

Loading...