[Gluster-users] Request for user comments

[Pranith Kumar Karampuri]

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