[Gluster-devel] Regarding the Porting of messages from gf_log to gf_msg

Vijay Bellur vbellur at redhat.com
Sun Apr 26 15:34:06 UTC 2015


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



More information about the Gluster-devel mailing list