New component: Valkey receiver

[rogercoll]

The purpose and use-cases of the new component

Valkey is a high-performance data structure server that primarily serves key/value workloads. It supports a wide range of native structures and an extensible plugin system for adding new data structures and access patterns.

Repository: https://github.com/valkey-io/valkey

The component should behave as the current redis receiver. Actually, the redis receiver is currently being used in the OpenTelemetry demo to extract metrics from a valkey instance, see: https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otelcollector/otelcol-config.yml#L17
The OpenTelemetry demo uses the redis receiver as a short term solution, but the end goal would be to use a valkey specific one in case their APIs change. They are two different products, so we expect their functionalities may diverge over time.

Implementation proposal:

• Move the redis receiver logic into and internal package (internal/cachestore?)
• Evaluate if the current client interface could be reused in other cachestore clients. The same applies for the configuration.
• Create the valkey receiver using the internal cachestore logic + specific Go client: https://github.com/valkey-io/valkey-go

Example configuration for the component

valkey:
  endpoint: "localhost:6379"
  username: "test"
  password: "test"
  collection_interval: 10s
  tls:
    insecure: true

Configuration example source.

Telemetry data types supported

• Metrics

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am a member of the OpenTelemetry organization.
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

@rogercoll

Sponsor (optional)

No response

Additional context

I proposed myself as a codeowner, but I am absolutely open to any suggestion. @dmitryax, @hughesjj as being codowners of the current redis receiver, would you also like to continue in this role for the valkey one?

As discussed in the SIG meeting, @dmitryax would you be able to sponsor this new component?

[andrzej-stencel]

@dmitryax would you be up for sponsoring this?

[hughesjj]

I'm of the opinion we'd be better off just copy+pasting the code for the redis client into a new module and s/redis/valkey/g'ing everything (metaphorically, of course some things like documentation will likely differ). You could then even use the valkey-go client directly.

The current redis receiver is a bit of a pain imo given we need to support more than just the latest version (at least, unless and until we initiate and complete an effort to define SLAs for how many versions in the past we support).

This is relevant given redis has re-arranged their APIs (via "duplication" of functionality) in a way such that you can scrape more than just "info" every time. This relates to the master/slave terminology that still persists thoughout the code base, even though there's technically some replacement APIs for them in newer versions.

So, in summary:

This is the chance for a fresh slate. Take it! There's no reason to couple your implementation to the existing receiver, at all. Duplicated code is not necessarily a terrible thing. There's no marketability reasons for doing so either, as both would live in the same -contrib distribution (if people are using ocb to pull in redisreceiver it should be trivial to also pull in valkeyreceiver)