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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
