zabbix 1.8.6 is affected too.
I just checked it.
Please, fix it before zabbix-1.8.7 release
it's currently not scheduled for 1.8.7
it's very painful bug.
For example, Nagios and Zenoss doesn't do such notifications.
- vi src/zabbix_server/timer/timer.c
/******************************************************************************
*
- Function: generate_events
* - Purpose: generate events for triggers after maintenance period
- The events will be generated only in case of trigger was FALSE
- before maintenance and became TRUE after maintenance, also in
- case if it was TRUE before and FALSE after.
..................................
Following this purpose current event generates is wrong.
That's what I mean.
Folks, this is really stupid and obvious bug!
Here is the one line patch.
- cat files/patch-src_timer.c
-
- src/zabbix_server/timer/timer.c.orig 2011-08-31 11:49:08.000000000 +0400
+++ src/zabbix_server/timer/timer.c 2011-08-31 11:49:48.000000000 +0400
@@ -433,7 +433,7 @@
get_trigger_values(triggerid, maintenance_from, maintenance_to,
&value_before, &value_inside, &value_after);
- src/zabbix_server/timer/timer.c.orig 2011-08-31 11:49:08.000000000 +0400
-
- if (value_before == value_inside && value_inside == value_after)
+ if (value_before == value_after)
continue;
/* Preparing event for processing */
Is it right?
I'd love to see it in 1.8.7 release
Just confirm the bug at least
it can't be confirmed until properly tested
ok, so thanks to explanation from server dev sasha, the problem in this case - it works as designed 
it's not a bug. initial requirements specifically asked for an ok event to be generated if a trigger flapped in the maintenance to ensure that this happening is not missed.
personally, i agree that in majority of cases that's not needed, though.
so there should be some way to configure whether flap during the maintenance should be alerted upon or not. whether it's a maintenance level option, action condition or something else, that's to be researched and decided.
> ok, so thanks to explanation from server dev sasha, the problem in this case - it works as designed
sorry, what did you mean? I didn't understand.
Because comment for generate_events says the opposite
>it's not a bug. initial requirements specifically asked for an ok event to be generated if a trigger flapped in the maintenance to ensure that this happening is not missed.
>
>personally, i agree that in majority of cases that's not needed, though
Yea, there is no monitoring system which behave this way. This feature useless in 99%.
When I set maintenance (aka downtime) period for server I DO NOT want to receive messages for given server. Because generally I do maintenance actions on this server and, of course, some trigger will switch.
This is why maintenance periods (downtimes) was invented.
I think default events generation should be changed.
>so there should be some way to configure whether flap during the maintenance should be alerted upon or not. whether it's a maintenance level option, action condition or something else, that's to be researched and decided.
My boss looked at me like %) and laughed when I told him about this bug/feature.
P.S. Sorry for my english.It's difficult to explane somethig.
turns out, it's the comment that is wrong.
please note that i fully agree that majority of users wouldn't want to receive such notifications, but that's the original specification... so the solution might be to introduce some way to control this behaviour.
ok, here's a workaround idea from alexei. add "trigger value=problem" condition and enable recovery message. should help you to get rid of that unwanted ok message
Thank you!
I hope this will be resolved in 2.0
given that 2.0 always enables escalations and adds "trigger value=problem" condition by default, this might just get "fixed" that way...
Shouldn't this be closed? Using the 'Trigger value=PROBLEM' solution seems to work and it is included by default in ZBX2.0 now.
sounds reasonable, closing
comment was fixed in r32354 for 2.0 and in r32355 for trunk
So, is it going to be changed?
Solution with "'Trigger value=PROBLEM' + 'recovery message'" isn't fix, but temporary workaround obviously.
I can create new ZBXNEXT to introduce some way to control such behaviour.
since 2.0 actions are enabled always, thus actions without "trigger value=problem" would probably result in really strange and unexpected behaviour. i don't think anybody will have such actions, so this solution seems sufficient.
I don't know whether I understand you. Sorry!
But it wouldn't result strange or unexpected behaviour.
http://img-fotki.yandex.ru/get/6433/16519813.0/0_9f447_51d9cb9f_orig
As you can see there is no "Trigger value" definition in this action.
I/We have been using such configuration for actions since Zabbix 1.4. There was no maintenance feature in Zabbix in those days.
And it works as exprected: no "Trigger value" definition -> so alerts on OK and PROBLEM.
And this way is less labour-intensive than your way. You don't need to fill recovery message)
I do not know, but I think it's more logical.
that's why i said "since 2.0", you use 1.8 
So, you want to say that doesn't work for 2.0? =)
Really, I want to descuss. Maybe forum is better place?
Your explanation leads to idea that 'Trigger value' condition doesn't make sense. Like there is no need for such condition at all.
it indeed changed in 2.0. feel free to discuss it on irc, but note the usual irc rules
Richlv, after closing this ticket it got worse on 2.0 version =(
Now on 2.0, even if "trigger state when maintenance period starts" is NOT EQUAL "trigger state when maintenance period ends" zabbix doesn't send notification!
It's very bad. It worked on 1.8. Described behavior in this ticket was great, excluding sutiation when "trigger state when maintenance period starts" is EQUAL "trigger state when maintenance preiod ends".
I'd like to discuss https://www.zabbix.com/forum/showthread.php?t=38875
I see in trunk there is still similar explanation of generate_events function in src/zabbix_server/timer/timer.c file.
Any plans to rework notifications after maintenance?
ZBXNEXT-3196 might change this behaviour