[receiver/valkey]: Init new component #37005
Conversation
This reverts commit 9898ae9.
rogercoll
force-pushed
the
init_valkey_receiver
branch
from
c3e23c0 to
a64d888
Compare
rogercoll
force-pushed
the
init_valkey_receiver
branch
from
b991b59 to
a82e488
Compare
rogercoll
force-pushed
the
init_valkey_receiver
branch
from
a82e488 to
1644903
Compare
|
cc @dmitryax |
Co-authored-by: Sam DeHaan <[email protected]>
| } | ||
|
|
||
| result, err := vs.client.retrieveInfo(ctx) | ||
| if err != nil { |
There was a problem hiding this comment.
Are there errors that should be considered differently - IE errors that show the client is no longer valid and we need to construct a new one?
There was a problem hiding this comment.
Not that I am aware of, the Redis receiver does not do any distinction either https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/redisreceiver/redis_scraper.go#L82
| attrs := make(map[string]string) | ||
| lines := strings.Split(data, attrDelimiter) | ||
| for _, line := range lines { | ||
| if len(line) == 0 || strings.HasPrefix(line, "#") { |
There was a problem hiding this comment.
The lines with a # prefix appear to start a named section of key/value pairs. Is there a promise in the API that there will be no name conflicts across categories? If no, we may need to consider grouping the parsed pairs by category, not in one shared map.
There was a problem hiding this comment.
Since 1.0.0, there do not appear to have been any conflicts in the sections. See the documentation: https://valkey.io/commands/info/
Although I like the idea of grouping the data by section, I would suggest keeping this feature for a future PR if needed. The current exported client metrics are not affected by the tested version (integration test 7.2)." Wdyt?
receiver/valkeyreceiver/README.md
Outdated
|
|
||
| ## Configuration | ||
|
|
||
| > :information_source: This receiver is in beta and configuration fields are subject to change. |
There was a problem hiding this comment.
I think this sentence is redundant, since the status of this component is in development, no one should assume that there will be no breaking changes to configuration.
There was a problem hiding this comment.
Good point, removed in 018a5e4
receiver/valkeyreceiver/README.md
Outdated
| receiver the duration between runs. This value must be a string readable by | ||
| Golang's `ParseDuration` function (example: `1h30m`). Valid time units are | ||
| `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. | ||
| - `tls`: |
There was a problem hiding this comment.
I think you can just link the Readme for configtls https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md
There was a problem hiding this comment.
Makes sense, thanks 018a5e4
.chloggen/init_valkey_receiver.yaml
Outdated
| # Use this changelog template to create an entry for release notes. | ||
|
|
||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
| change_type: 'enhancement' |
There was a problem hiding this comment.
this should be new_component
Description
Base receiver code for the new Valkey receiver (metadata, client interface, unit and integration tests). Just the
valkey.client.connection.countmetric will be available after this PR. Based on https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-metrics.md#metric-dbclientconnectioncountConfiguration options: Valkey endpoint + TLS options
Link to tracking issue
Fixes #33787
Testing
testdata+ contrib golden package.Documentation