gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] regarding gluster msg ids


From: Shyamsundar Ranganathan
Subject: Re: [Gluster-devel] regarding gluster msg ids
Date: Fri, 11 Apr 2014 09:49:13 -0400

Paul,

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 ;)

Shyam

On Thu, Apr 10, 2014 at 10:50 PM, Paul Cuzner <address@hidden> 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" <address@hidden>
> To: "Pranith Kumar Karampuri" <address@hidden>
> Cc: "Ravishankar Narayanankutty" <address@hidden>, "Gluster Devel"
> <address@hidden>, "Shyamsundar Ranganathan"
> <address@hidden>
> 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
> future.
>
> 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 :) ).
>
> Shyam
>
> On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan
> <address@hidden> wrote:
>> On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri
>> <address@hidden> 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
>>> better:
>>>     - 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
>> unique.
>>
>> 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
>> clash.
>>
>> 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)
>>>
>>>
>>> Pranith
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]