[Gluster-devel] regarding gluster msg ids
shyamsundarr at gmail.com
Fri Apr 11 13:49:13 UTC 2014
Just adding to the context (or stating the obvious),
The gluster messages would contain the following format,
[date&time] [SEV] [MSGID] [code location] [xlator/component] <message>
So it should cater to picking up on sev, xlator/component, and based
on the message ID, don't panic ;)
On Thu, Apr 10, 2014 at 10:50 PM, Paul Cuzner <pcuzner at redhat.com> wrote:
> This is really interesting - I've worked on systems (z series) that used
> msgid's across a mass of products, based on a <product
> prefix><seq#><severity> format
> That worked really well, since operations picked up on the prefix and
> immediately new what subsystem the message related to....and whether to
> panic or not :) The messages could also be sent to the same logging
> subsystem, and then automation could just pick the one file and get a view
> across all products.
> Ahhh - good times :)
> From: "Shyamsundar Ranganathan" <sam.somari at gmail.com>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> Cc: "Ravishankar Narayanankutty" <ranaraya at redhat.com>, "Gluster Devel"
> <gluster-devel at nongnu.org>, "Shyamsundar Ranganathan"
> <shyamsundarr at gmail.com>
> Sent: Friday, 11 April, 2014 1:10:26 PM
> Subject: Re: [Gluster-devel] regarding gluster msg ids
> Updating the thread with some more context from discussions offline
> between Pranith, Krutika and myself.
> The issue(s) that led to moving from a numeric ID to a string notation
> of the #define was due to
> - fragmentation of the message range once allocated segments were full
> - Ability to define more developer friendly #define names, making
> code better understandable
> - Based on the #define adding better meaning to the message itself
> Based on this it was discussed and concluded that we will standardize
> on numbers as an externally visible entity rather than have developer
> defined strings as the ID,
> - so that it looks and feels consistent across components
> - as we do not need to add more meaning to the message ID but
> rather to the message when required and,
> - also we need to leverage the ID as potential candidate for
> journald/systemd subsystem when moving to that (potentially) in the
> Developers still have the flexibility to use any define names for
> messages in their component, so that code reading is better.
> Message range fragmentation would continue, but that is a smaller
> problem which can be avoided taking larger/more segments as the
> component may need/choose.
> A compile time step would be added to prevent multiple definitions of
> message defines (as suggested by Jeff) by adding a precompile script
> to each message file to generate a conversion from #define to const
> char * variants of the message.Then do a compile of this generated
> header, which would fail in case there are duplicate const char *
> defines. (rereading this line does seem like a lot of information in a
> single line, so will follow this with a code submission to elaborate
> the concept better :) ).
> On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan
> <sam.somari at gmail.com> wrote:
>> On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri
>> <pkarampu at redhat.com> wrote:
>>> hi Shyam,
>>> Instead of printing numbers as msg-ids, could we print the
>>> stringification of macro itself as the msg-id? Reasons why I feel this is
>>> - No need to worry about msg-id range segment overlaps as we are not
>>> dealing with numbers anymore.
>> What is the current problem in segment overlaps? The intention is to
>> get separate segments per component, so that way each segment is
>> Why wont these message names rather than numbers not clash? IOW, if 2
>> components choose the same macro names then an entire name space would
>> Look at these message ID segments like the mem types assignments.
>>> - macro re-use in same file will cause compilation error. Different
>>> msg-id.h files will have different prefixes for msg-ids so there should not
>>> be any collisions across components.
>> Macro reuse (as stated in the followup by you) is a separate problem,
>> which needs to be dealt with using gcc preprocessing of the headers
>> during compile time, to eliminate the possibility of duplicate macro
>> names within a single header.
>> const char * definitions will not help catch preprocessing time format
>> and types error with the __attribute__ ((__format__ (__printf__, 9,
>> 10)) check.
>>> - We can choose to give easy-to-remember msg-ids like AFR-SPLIT-BRAIN
>>> if we want to. No need to lookup what msg-id means etc.
>> Admins who are looking at logs are not looking for clues from message
>> ID per se, they are looking at an ID to look up and understand what it
>> means, hence any unique string/number can serve as the ID. Please note
>> this is not for developers to look at and debug from the logs.
>> Here is a broader overview of the message ID versus the string proposal
>> from me.
>> - Other similar systems use and ID, which in systemd parlance can be a
>> GUID or some such distinct identifier per message (say message
>> catalogs for systems from Cisco etc.)
>> - A string of the form suggested is still a unique message ID, but
>> when we integrate to systems like systemd, such IDs may not work, we
>> need definite numbers
>> - When it comes to documentation, which the admins would refer to, an
>> ID is easier than a string in the message to simply put a list of
>> messages up for the administrator to look at and search
>> In short, what is the segment clash issue, and what is the code
>> maintenance issue that is being discussed with the current mechanism,
>> moving to a string does not seem to satisfy the requirements for this
>> framework at the moment from my perspective. So it is better to
>> understand what the segment allocation issue is first.
>>> I sent a first-cut patch at: http://review.gluster.org/7398
>>> TODO: Remove segment related macros if you guys also like the change.
>>> This is one of the messages with and without patch above:
>>> [2014-04-04 07:08:53.113969] I [MSGID: glusterfsd_msg_30]
>>> [glusterfsd.c:1914:main] 0-glusterd: Started running glusterd version 3git
>>> (args: glusterd --debug)
>>> [2014-04-04 07:10:49.687053] I [MSGID: 100030] [glusterfsd.c:1914:main]
>>> 0-glusterd: Started running glusterd version 3git (args: glusterd --debug)
>>> Gluster-devel mailing list
>>> Gluster-devel at nongnu.org
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel