Re: Request for user comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux