You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The redis plugin is missing a lot of the metrics shown in an info command.
For example
client_longest_output_list
client_biggest_input_buf
blocked_clients
rdb_last_bgsave_time_sec
rdb_last_bgsave_status
rdb_last_save_time
total_net_input_bytes
total_net_output_bytes
The list goes on.
These metrics should be recorded.
Proposal:
Provide some way of getting these additional metrics in influxdb. The implementation should be future proof as well. Meaning that if new metrics are added to a future redis version, the source code of the plugin should not have to be modified.
Thus the plugin should either pass through unknown metrics, and rely on fielddrop to omit them if the user does not want them. Or the plugin should have a configurable list where the user can add extra metric names to the hard coded list.
Current behavior:
Hard coded list of metrics.
Desired behavior:
Configurable list of metrics.
Use case: [Why is this important (helps with prioritizing requests)]
Users might want to track metrics the plugin author does not, or that weren't available at the time of authoring.
The text was updated successfully, but these errors were encountered:
I agree, I think it would be better to just pass through all available metrics from redis, I'm not sure why we ever put the hardcoded list to begin with...
Feature Request
The redis plugin is missing a lot of the metrics shown in an
info
command.For example
client_longest_output_list
client_biggest_input_buf
blocked_clients
rdb_last_bgsave_time_sec
rdb_last_bgsave_status
rdb_last_save_time
total_net_input_bytes
total_net_output_bytes
The list goes on.
These metrics should be recorded.
Proposal:
Provide some way of getting these additional metrics in influxdb. The implementation should be future proof as well. Meaning that if new metrics are added to a future redis version, the source code of the plugin should not have to be modified.
Thus the plugin should either pass through unknown metrics, and rely on
fielddrop
to omit them if the user does not want them. Or the plugin should have a configurable list where the user can add extra metric names to the hard coded list.Current behavior:
Hard coded list of metrics.
Desired behavior:
Configurable list of metrics.
Use case: [Why is this important (helps with prioritizing requests)]
Users might want to track metrics the plugin author does not, or that weren't available at the time of authoring.
The text was updated successfully, but these errors were encountered: