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

[Shyam]

On 04/26/2015 11:34 AM, Vijay Bellur wrote:
> 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?

Document posted for review/additions here, [1].

Shyam
[1] http://review.gluster.org/#/c/10896/