Bizarrely and somewhat contradictory to the behaviour below is the behaviour of DURATION well inside of the times specified with the TIME rule. Is DURATION not reset when the colour of the alert changes??? That seems to be the only explanation for what I'm seeing (though it is early days to be certain). Or, to put it another way, is DURATION the non-green DURATION, rather than the duration of being in a certain colour?
The config I currently have is:
$pg-sebsms=me AT mysms2emailprovider.com TIME=W:0845:2355
HOST=DbR1 SERVICE=Special MAIL me AT work.co.uk COLOR=red DURATION>2 REPEAT=30 RECOVERED MAIL $pg-sebsms COLOR=red DURATION>15 REPEAT=300 RECOVERED
I was hoping (and expecting) the above rules to only alert after 2 minutes and 15 minutes repectively of being red, given that COLOR=red is part of the rule. I do, however, acknowledge that there may be (rare) cases where you would want to include the yellow time in the DURATION. In which case, we really need REDDURATION, YELLOWDURATION and PURPLEDURATION rules. Or perhaps just a way of specifying how you want the DURATION to be calculated in that rule: DURATIONTYPE=<NONGREEN|LASTCHANGE> (that's either or). Or even more powerfully: DURATIONCALC=color[,color] (adds up the duration of being in these colour states). (However, this could become resource intensive if you specify DURATIONCALC=red,yellow,purple,green or something! On the other hand, one only needs to check back as far as DURATION, rather than calculate the total time in these colour states.)
I am using Hobbit 4.3 (trunk) from Dec 9 2008.
Looking carefully at 'man hobbitd_alert' this appears to be most relevant part: 'When a status first goes to one of the ALERTCOLORS, hobbitd_alert is notified of this change. It notes that the status is now in an alert state, and records the timestamp when this event started, and adds the alert to the list statuses that may potentially trigger one or more alert messages.' I do not, however, think that this timestamp should be what is used by the DURATION rule (it being far too simplistic), but it looks like it may very well be. Maybe this explains the behaviour I have with Big Brother's rules that I always considered a weird bug: sometimes the 'initial page delay' is not respected. This actually happened twice today and I got SMSes simultaneously from BB and Hobbit when they had 5 minute and 15 minute initial page delays respectively, and I got the SMS immediately after the red. It had however been yellow for some time before, but on BB my pagelevels is set to "red purple", so the yellow should have been ignored and not come into the equation. How frustrating! One of the main reasons I wanted to move to Hobbit was to eliminate this 'bug' in Big Brother!
Still awaiting a reply on my message below BTW. Given my unfortunate theory, above, on what is going here, I suspect the TIME rule is causing this magic timestamp to never be recorded! Somehow it appears to be taking precedence over the DURATION rule when I wish the DURATION rule to take precedence (and I think that is more logical: if I wanted to mark it as downtime, I'd have put the TIME rule into bb-hosts not hobbit-alerts.cfg!). ;)
'man hobbitd_alert' could be clearer, e.g. on how rules interact with each other!
Many thanks,
SebA
From: SebA [mailto:spa at syntec.co.uk] Sent: 27 January 2009 14:35 To: hobbit at hswn.dk Subject: [hobbit] hobbit-alerts.cfg: behaviour of TIME and DURATION together
It seems the combination of TIME=W:0845:2355 and DURATION>15 in hobbit-alerts.cfg means the earliest an alert can be sent out is 9 am. Is this what you would expect? I would have expected these two rules to mean the test should be in an alarm colour for more than 15 minutes and be between the times of 08:45 and 23:55, weekdays. Instead it seems to be relating the DURATION with the time such that the DURATION only applies _during_ the TIME.
If the current behaviour is intended, than will using EXTIME instead of TIME be what I want? Oh! There is no EXTIME?! I assumed there was but I see no documentation for it apart from Henrik's suggestion that he might add it:
<http://www.hswn.dk/hobbiton/2006/06/msg00417.html> http://www.hswn.dk/hobbiton/2006/06/msg00417.html
Kind regards,
SebA