Re: Regarding the Porting of messages from gf_log to gf_msg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

HTH,
Shyam

[1] http://www.gluster.org/pipermail/gluster-devel/2013-December/038077.html
[2] http://www.gluster.org/community/documentation/index.php/Features/better-logging
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux