sfxclient or splunk-otel-go

[pellared]

trafficstars

Shouldn't sfxclient be deprecated in favor of https://github.com/signalfx/splunk-otel-go and https://pkg.go.dev/go.opentelemetry.io/otel/metric?

Or maybe we should simply refer to https://github.com/signalfx/splunk-otel-go instead of sfxclient in the main README.md: https://github.com/signalfx/golib/blob/b545ac6814419671f0f808d2b0bbab89b1f7ec09/README.md#L3

CC @mdubbyap @jgheewala

[mdubbyap]

I think that would be rather premature for several reasons:

• we don't have support for mapping the content we support in builtin dashboards and alerts from otel.
• we don't support oter grpc or json, so it's kinda limited support.

I think the first step would be updating our documentation and our default collector build once the above exist, not deprecating the library, that would be last.

[akubik-splunk]

Are you saying it is integral part of our OTel Collector code realizing pipeline into observability? If so then we would agree but we are talking about parts related to instrumentation that would be used by our customers to instrument there code where they should move to OTel instrumentation instead

[pellared]

we don't support oter grpc or json, so it's kinda limited support.

Related: https://github.com/signalfx/splunk-otel-go/issues/2582. I think I can change the our OTel Go distribution to use the HTTP/protobuf endpoint it the user sets SPLUNK_REALM.

[pellared]

we don't have support for mapping the content we support in builtin dashboards and alerts from otel.

This looks like related to https://github.com/signalfx/splunk-otel-collector/blob/e1e54a2c780ce7689c4a52a3108defb23896f12c/go.mod#L93

CC @atoulme

[atoulme]

The way we depend on this library is internal to the smart agent receiver, where we still depend on the datapoint representation, and then transform datapoints to pdata (OpenTelemetry Collector data).

pkg/receiver/smartagentreceiver/output.go:      "github.com/signalfx/golib/v3/datapoint"
pkg/receiver/smartagentreceiver/output.go:      "github.com/signalfx/golib/v3/event"
pkg/receiver/smartagentreceiver/output.go:      "github.com/signalfx/golib/v3/trace"

We will reduce this over time, we might be able to move to pdata internally (https://github.com/signalfx/splunk-otel-collector/pull/3179 spike here).

We depend on sfxclient for collectd use cases.

[pellared]

We depend on sfxclient for collectd use cases.

@mdubbyap @atoulme How about moving the source code from golib to splunk-otel-collector?

[atoulme]

We can do that, sure. Would that help?

[pellared]

Here are known importers: https://pkg.go.dev/github.com/signalfx/golib/sfxclient?tab=importedby. We would need to first check:

• what importers has to still use sfxclient and they cannot use splunk-otel-go. If there are more than one repository that needs sfxclient then we should probably keep it. If only smartagentreceiver needs it then we can copy the code there.
• in those that we maintain we would need to update to use splunk-otel-go instead of sfxclient
• if everything would go well then we could deprecate sfxclient

CC @akubik-splunk