[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: event ratio patch updated
From: |
Martin Pala |
Subject: |
Re: event ratio patch updated |
Date: |
Mon, 05 Sep 2005 09:53:13 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6 (Windows/20050716) |
Jan-Henrik Haukeland wrote:
I have only browsed through the patch and it looks fine by me, although
I'm not quite sure what is going on with the Event.state_map
bit-flicking :-)
The state is kept in in the bitmap which workes similar to the
ringbuffer - it is rotated to the left by one bit automaticaly when the
new event appeared and the current state (failed or passed) is set to
the right-most bit.
Then the bitmap is compared whether the state change can be triggered
(i.e. passed->failed ot failed->passed). The testing rule ("x times
within y cycles") says how many occurences during how many cycles are
needed to change the state and apply the action (independently for
failed and passed state change). The <cycles> limit defines how many
bits are compared from the right to the left. Then the appropriate count
of bits (i.e. last corresponding cycles state) are compared. Just bit
rate of the same state as current event is counted. When the final rate
corresponds to the rule and the current service state is inverse, the
state is changed.
It is quite simple and self-managing :)
Since you use a long long (could uint64_t be used
instead?) does this mean that there are only room for 64 failed/ passed
events?
Right. The bitmap is adaptive - depending on how large the 'long long'
type is on given architecture, then the corresponding cycles count
history are kept.
The parser checks for 'long long' size vs. cycles count in the rule and
reports the corresponding maximal value when the cycles count is greater
then can be described by the 'long long' bitmap.
Even on usual 32-bit architectures, last 64 cycles are available, which
is sufficient i think ;)
It should be more than enough but should maybe be documented
(if I'm right).
OK, i will add some notice to the documentation.
Martin