Incresed Observability of go-redis OSS client #3097
Replies: 4 comments 2 replies
-
@monkey92t @vmihailenco please take a look at this when you are free |
Beta Was this translation helpful? Give feedback.
-
@monkey92t Could you take a look at this? I’d appreciate any feedback or suggestions you might have. I'm happy to submit a proposal PR if needed. |
Beta Was this translation helpful? Give feedback.
-
@vladvildanov Could you please review this idea? I'd love to hear your thoughts and feedback on it. |
Beta Was this translation helpful? Give feedback.
-
@srikar-jilugu So it's a matter of the performance here. I would say we cannot just do "some" metrics or logging, it should be a strategy of what we want an achieve and what does it costs in terms of performance. I would appreciate any thoughts on this 🙂 |
Beta Was this translation helpful? Give feedback.
-
Currently, our OSS Redis Cluster ecosystem has limited monitoring capabilities within the go-redis client, making it challenging to debug issues from the client's perspective. For instance, when there's a sudden increase in redis response time during an Elasticache autoscaling event,, we want to check if there are any issues due to prolonged
moved
errors, an excessive number of retries, or if the cluster topology hasn't been updated on the client sideAlong with that, we recently enabled
RoutebyLatency
in one of our cluster clients and there is very little scope to validate its functionality as there's no insight into which node is handling specific requests from the client.To enhance the observability of the client, we could implement the following improvements through metrics or logging, depending on the use case:
moved
andreadonly
errorsno.of.retries
per commandfailed
Beta Was this translation helpful? Give feedback.
All reactions