Hi there,
Currently the MONITOR command shows only the commands server received. If it can output the return server emitted, it would be very useful for debugging! For bulk replies, I suggest that MONITOR outputs only the first 1 or 2 lines (depends on command type), and shows how many total lines there is, e.g.
+123456789.1234 HGETALL u:1234 < +123456789.4321 1) loginName < +123456789.4321 2) user1 < +123456789.4321 ... +10 lines, 123 bytes
Any thoughts?
Shannon
Comment From: janoberst
I think this might be useful, however on a busy server it will be complete overkill. Would it make sense to add a KEYS * like semantic? i.e. saying "MONITOR u:1234" in your example to only monitor things that happen to that specific key?
That way the amount of data shown could be minimized. In addition I'd probably add a keyword like MONITOR RESPONSES, so not to break the existing monitor command.
Comment From: AndrewGuenther
I agree that the ability to get returned values from the MONITOR command would be very useful, but that would also involve storing these values as well. I haven't completely familiarized myself with how MONITOR is implemented, but I believe it uses AOF to get the command history. If this is the case, I think that implementing this would seriously hinder the compactness of the AOF format.
In response to @janoberst's comment, I don't think a KEYS * like semantic would be totally necessary. With lua scripting coming, a lua script could be used to filter these results for you.
That all said, I think there is a potential compromise here. I absolutely agree that the output of return values would be great for debugging, but unfortunately impractical to continuously store them in a real world implementation. I propose a SPOOL type command. If you are unfamiliar with sqlplus, SPOOL essentially records SQL query inputs as well as outputs. Something like this would be great for debugging, and from my understanding would not be possible to implement in a lua script.
An example:
redis > SPOOL debug.out
redis > -- Insert testing queries here
redis > SPOOL off
The inputs and outputs would then be stored in the debug.out file you specified.
As much as I cringe at the idea of adding more commands, I think this would be a truly valuable addition.
What are your thoughts?
Comment From: janoberst
There's also a more in-detailed ticket #177 that covers monitoring expires and filtering by command.
I actually agree that a "KEYS *" option would be overkill. Most of the functionality can be reproduced by simply calling redis-cli MONITOR |grep
There is also the SLOWLOG setting that stores (slow) queries in a redis list with limited length. Maybe implementing MONITOR with data based on a redis-internal list like that would be an alternative to writing logfiles to disk? That way one could look back at the last 100 or so executions of a certain command and see which result was returned to the client.
Comment From: AndrewGuenther
I like the idea of adding a parameter to monitor that would force it to give return values. My last comment may have made a few inaccurate statements about how MONITOR works. My understanding is that it catches and prints what is on its way to the AOF file. If this is not the case, I think the ability to say MONITOR return would be great.
redis-cli MONITOR RETURN | grep
This would absolutely be the ideal in my mind. I am digging through and trying to find out more how MONITOR works to see how feasible this is.