Gluster users - Jun 2015 - Request for user comments

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.

> 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?
>
> Pranith

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?

Pranith
>
>>
>> Pranith
>