[Gluster-users] Request for user comments
Pranith Kumar Karampuri
pkarampu at redhat.com
Wed Jun 17 18:08:18 UTC 2015
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
>>>> 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'.
More information about the Gluster-users