[Gluster-devel] Troubleshooting and Diagnostic tools for Gluster

Shyam srangana at redhat.com
Thu Oct 29 13:26:05 UTC 2015


On 10/27/2015 11:12 PM, Sankarshan Mukhopadhyay wrote:
> On Mon, Oct 26, 2015 at 7:04 PM, Shyam <srangana at redhat.com> wrote:
>> Older idea on this was, to consume the logs and filter based on the message
>> IDs for those situations that can be remedied. The logs are hence the point
>> where the event for consumption is generated.
>>
>> Also, the higher level abstraction uses these logs, it can *watch* based on
>> message ID filters that are of interest to it, than parse the log message
>> entirely to gain insight on the issue.
>
> Are all situations usually atomic? Is it expected to have specific
> mapping between an event recorded in a log from one part of an
> installed system to a possible symptom? Or, do a collection of events
> lead up to an observed failure (which, in turn, is recorded as a
> series of events on the logs)?
>
>

logs are from a point in the code, at a point in time (just stating the 
obvious). So to detect a genuine failure or that an event has occurred, 
it may need multiple messages to detect the same. Pattern for such 
events need to be called out, for it to make sense.

But, *some* log messages from higher layers, do denote failure as a 
collection point.

Overall to answer your question, it is a combination of all, depending 
on the event/situation.

But I did not understand the _atomic_ part in the question and also I am 
not sure I answered what you are thinking about.


More information about the Gluster-devel mailing list