redis-async-rs

redis-async-rs copied to clipboard

I'm working on implementing health checks for my app. I would like my app to return "not healthy" if the redis connection is somehow broken. That is fairly straight forward with PairedConnection by sending it a PING.

However I'm not sure how to accomplish that for PubsubConnection. I could try and subscribe to a random topic and see if that succeeds but feels a bit dirty.

Hello.

This is an interesting question. The nature of a subscription means we're waiting for other things to happen.

One thing that might be useful is that, if the connection behind the subscription drops or has a significant error, then the subscription Stream will end with an error. So if that Stream is still live, then the connection is healthy. As long as the underlying tokio::net::TcpStream is healthy then so is the subscription. If the connection drops, we'll try and reconnect, but the specific subscriptions need to resubscribe. This was a deliberate choice for two reasons: 1. if we resubscribe automatically, clients of the library might not know that anything went wrong, and may have missed messages while the resubscription happened, and 2. to produce clients with an error for monitoring/alerting/etc. purposes.

But the context of the question implies you need a kind-of end-to-end healthcheck, something equivalent to a PING? In the past when I've built something similar, the topic subscribed to was frequent enough that the lack of a message after x seconds would send an alert. But this depends on the nature of the data, of course, it wouldn't be a useful indicator if the messages were naturally sporadic.

I hope this provides some information that's useful.

In the past when I've built something similar, the topic subscribed to was frequent enough that the lack of a message after x seconds would send an alert

Neat trick but I don't think that strategy would work for my use case.

One thing that might be useful is that, if the connection behind the subscription drops or has a significant error, then the subscription Stream will end with an error

So perhaps regularly trying to send a "no-op" (which the clients will always ignore) and if that fails the connection could be considered dead?