[Gluster-devel] Logging framework in Gluter 4.0

[Nagaprasad Sathyanarayana]

I remember Shyam had done some ground work a while ago on logging improvements.  One of the option being explored was rsyslog.

I have seen the use of transaction IDs in logs.  This usually helps in grouping related log messages as they use same transaction ID.  This also speeds up analyzing issues.

Regards
Naga

----- Original Message -----
From: "Aravinda" <avishwan at redhat.com>
To: "Avra Sengupta" <asengupt at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>
Sent: Friday, November 6, 2015 1:30:01 PM
Subject: Re: [Gluster-devel] Logging framework in Gluter 4.0


regards
Aravinda
http://aravindavk.in

On 11/06/2015 12:28 PM, Avra Sengupta wrote:
> Hi,
>
> As almost all the components targeted for Gluster 4.0 have moved from 
> design phase to implementation phase on some level or another, I feel 
> it's time to get some consensus on the logging framework we are going 
> to use. Are we going to stick with the message ID formatted logging 
> framework in use today, or shall we move on to a better solution.
>
> Some good to have features I would like to have in the logging 
> framework are:
> 1. Specific distinction between logs of various transactions (or 
> operations), that would make it a lot easier to make sense than 
> looking at some serialized log dump
Externally grouping Message IDs may help in this situation.

> 2. We often encounter issues, and then find ourselves wishing the 
> process was running in debug mode so that we could have gotten some 
> debug logs. If there is any solution that enables me tracability of 
> the process's flow, without compromising the space constraints of the 
> logs that would be great to have.
I think after each debugging session, we should revise the log messages 
to get following answers.
1. Is something missing in log, which could have reduced the time spent 
to root cause.
2. Logging is available but imcomplete details. (For example, on volume 
set, debug message will have key and value but no Volume name)
3. Is something redundant or not required. (For example, Geo-replication 
worker logs sync engine as rsync or tar mode. If we have multiple 
workers then all workers prints this log message. Instead if we move 
this log to monitor process instead of worker process we could save some 
space in log files)

With this practice, we can improve our logs over time.
>
> This is kind of an open floor question I am putting across to the 
> community, with no specific solution in mind at this point in time, 
> but a concern that we should rather decide on something sooner in the 
> development cycle than later.
>
> Regards,
> Avra
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel