On 06/17/2015 11:34 PM, Ravishankar N wrote:
On 06/17/2015 10:58 PM, Pranith Markup Karampuri wrote:
On 06/17/2015 10:44 PM, Ravishankar N wrote:
On 06/17/2015 10:34 PM, Pranith Kumar Karampuri wrote:
Depends on the log size. Largest logfile I debugged from customers
is >20GB. Production logs are generally of the order of GBs.
Readability hardly matters when things get to that size.
On the contrary, readability is what matters the most. What you
cannot read easily you cannot interpret easily.
Nah! what you can not process easily you can not interpret at that
scale.
You need to be able to process the logs and get useful information
with least amount of work. With the message-id framework we are
going towards this will be even more important to have the whole
log in same line, so that we can grep using msg-id alone.
Again, how does the patch affect the 'grep'-ability of logs?
If there are 6 code paths which are passing NULL to dict_ref. All of
them use msg-id LG_INVALID_ARG in the log file. To figure out the
uniq code paths the command is:
"grep LG_INVALID_ARG <log-file> | grep dict_ref | sort | uniq -c"
Assume the log is 20GB. And there are 100000 dict_ref logs. What will
be the command to get the info above after this change is merged?
Ah, I now see where you are coming from. But to be fair, since there
will be a delta in the time-stamps of the messages, your uniq filter
would anyway end up printing all 100000 log counts.
You can delete that part with awk. But I guess you got the problem. It
will be very difficult to get this information if we have logs with '\n'.
Pranith
Thanks,
Ravi
Pranith
Pranith
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
