Redis Cluster: Cluster slots / cluster nodes command improvements

[benlaplanche]

These two commands give the vital information, albeit in bit of a confusing format.

From an operations perspective, you want to just run a command see vital information such as:

-node IP
-node port
-node status (healthy, up / down)
-node role (master / slave)
-AZ location (if configured)
-max-memory usage
-% of the total data it owns

Something like nodetool status output from Cassandra gives a great overview

http://stephen-walsh.com/wp-content/uploads/2014/08/cassandra-node-down.jpg

[antirez]

Confusion is a feeling. If we want to focus on the actual formats, CLUSTER NODES is a plain CSV space-separated file providing everything you listed that is actually part of Redis Cluster. Many things you listed are currently not part of Redis Cluster so can't be listed.

Of the things you provide, memory usage and/or % of total data it owns, which is the more likely to be added to Redis Cluster v2, I think will be moved into a different command, since CLUSTER NODES is especially designed to hold what is the persistent part of the Cluster node. It's not by chance indeed that the format is the same of the nodes.conf file.

So it is likely we'll get some new cluster command that shows the total memory usage, the masters data usage for each node, the amount of memory used by replicas for each master node, and so forth. Closing this issue since there is no action I can take in the short term, nor in the long term it is clear what we'll end getting into Redis Cluster v2.

[antirez]

p.s. note that documentation on CLUSTER NODES format is available here: http://redis.io/commands/cluster-nodes explaining each field.

[benlaplanche]

I think there is work that can still be done in the interim, mainly around the formatting of the output.
If it could be parsed into a table output, with the relevant headers against it that would be quicker to read and understand without referring to the documentation.

I still believe a simple status column would be very useful to operators. Being able to see whether a node is currently up/down/being promoted/other relevant statuses

With regards to the memory and data values, if they are not available yet then we can revisit that later.

@tsaleh

[badboy]

A nice tabular output would be the task of the frontend tool, that just parses the output and formats it the way you want.

[antirez]

Ok with the additional informations you provide I think the feature request changed a bit, at least in the way I think at it. Are we basically talking more of an human oriented output? That makes sense to me, and is not against Redis way to provide commands which are only useful for humans to quickly inspect what's going on (for example memory reporting has _human fields where it is converted to the nearest order of magnitude unit).

However this may be done in multiple ways. One is as a native command, another is as a redis-cli feature where CLUSTER NODES gets parsed and provides a visual output. However if my feeling is that all this possibilities are a step forward compared to read CLUSTER NODES by naked eyes, but are still sub optimal when the cluster size starts to be in the order of a few tens between master and slaves, go figure when you have hundreds.

So there was this project to have something like:

redis-trib web 127.0.0.1:6379
Please point your browser to http://127.0.0.1:9999 for Redis Cluster web interface

This should spin a simple Sinatra application that provides a visual representation of the cluster, where clicking into single nodes will provide information, colors are used to signal issues with a node, and by other means it is possible to see used memory, number of slots served, and so forth.

I think this would be valuable already just in read-only mode, but the next step would be the ability to use, form the UI, all the redis-trib commands in a visual way, for example in order to trigger reshardings and other stuff.

Does this make sense or is a totally different matter compared to the original request? Please while reading this comment think that I'm a totally cli oriented person, so I'm suggesting a graphical approach as a last resort after seeing that with many nodes, the visual approach is apparently the only one able to handle it.

[benlaplanche]

yes, a human readable cluster nodes output is what i'm envisaging.

I guess the question is starting to become, where is the domain split between the functionality that the redis-cli provides which i appreciate should be carefully considered and in a certain format to be parsed by the various clients.

vs the tools that an operator needs to manage the cluster. Should this be a separate tool that is based only for the cli so we can have more human focused output and options available?

If its the latter then we can split that into a separate Issue as it feels like a bigger more distinct feature request.

for the web app, that sounds pretty cool and a huge value add but in my mind definitely separate from Redis itself.