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.
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.
[ ] 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?
The purpose and use-cases of the new component
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 avalkey
instance, see: https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otelcollector/otelcol-config.yml#L17 The OpenTelemetry demo uses theredis
receiver as a short term solution, but the end goal would be to use avalkey
specific one in case their APIs change. They are two different products, so we expect their functionalities may diverge over time.Implementation proposal:
redis
receiver logic into and internal package (internal/cachestore
?)valkey
receiver using the internal cachestore logic + specific Go client: https://github.com/valkey-io/valkey-goExample configuration for the component
Configuration example source.
Telemetry data types supported
Is this a vendor-specific component?
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?