On 04/25/2015 12:35 AM, Shyam wrote:
On 04/24/2015 11:06 AM, Anusha Rao wrote:
I had a few doubts regarding the conversion from gf_log to gf_msg:
1) Is it necessary to convert all gf_log messages to gf_msg ?
Yes, once we get to the point that gf_log is not used anywhere, we
should be retiring that interface.
2) If (1) is yes, then should all the "INFO" and other messages have
msg_id (If it is not related to the Admins) ?
Since msg_id argument in the gf_msg is one of the mandatory field ?
INFO messages reach the admin, as they are logged in the current default
log level and admins can see them.
That being said, the intention for the message ID is as elaborated here
(a little dated but relevant), [1] [2].
The idea is that all messages have IDs and the admin can glean better
information for these based on the ID. Even further, automated log
processing schemes can leverage these IDs to provide better monitoring
(say sending mails on some key msg IDs like a split brain).
All INFO messages may not need a message ID, as some maybe for
developers to have better insight into some failures. In such cases, we
can group them into a common message ID bucket _per component_ and say
these are to be ignored as the trouble shooting step for these messages.
I would state, care should be taken when doing this, so that we just do
not put in an ID for the sake of it. The ID has a meaning and can be
used in various circumstances to help both users and developers. As a
result any such common bucket usage would need better scrutiny from
component maintainers in general.
This certainly is useful information. Shyam - can you please add this as
doc/developer-guide/logging-guidelines.md or equivalent?
Thanks,
Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
