-
Notifications
You must be signed in to change notification settings - Fork 17
Centreon ignores notification period #75
Comments
We can confirm the Issue, one of our customers reported same behavior. |
Same here, contact with empty notification period defined, are contacted with centreon-engine 1.5.1 |
Could you check if you have the same behavior with Centreon Engine 1.5.3 / Centreon Broker 2.11.8 ? |
Sorry, my mistake. For me it is with centreon-web-2.8.9, centreon-broker-3.0.8 and centreon-engine-1.7.2.. |
We will test/use a newer version at some point but don't have a set schedule for it yet. However if grosbedos has the same behaviour with an even newer version it's safe to assume the suggested ones are also still affected. |
Tested Centreon 2.8.12, engine 1.7.2, broker 3.0.8, similar issue: If I delete all fields for the timeperiod (i.e. they had values before but are now empty), notifications are sent. I didn't test this a lot though, just noted the single occurrence while testing exceptions with the latest version. This is slightly different from the original issue in that notifications are only erroneously sent if none of the fields have data, whereas in 2.7.x it also happened if you had data in other fields. |
Which information do you need to solve this problem? We are expecting the same problem on Centreon Engine 20.04.4. We searched for problems that may be solve the problem, but nothing worked. We found a workaround: Fill a field within the notification template which is empty (Wednesday or something from 11:58 - 11:59). Till Centreon 2.6, empty fields were associated with 'do not send message'. This kind of handling notifications are more efficient. Is it possible to get this behavior again? |
Looking back through the event logs, notification mail is always sent, regardless of time period defined.
Example: we have a host "1234x" with a defined service "Windows_CPU" and both host/service notification period "workhoursxy":
$ mysql -NBr centreon_storage -e "select services.service_id,services.notification_period,hosts.notification_period from hosts join services on services.host_id = hosts.host_id where name='"1234x"' and description='"Windows_CPU"' and services.enabled=1"
5678 workhoursxy workhoursxy
The time period it uses:
$ mysql -t centreon -e "select * from timeperiod where tp_name='workhoursxy';"
Instead of just the first, a mail is sent for all 4 of the below critical service states, even though the notification period ends at 18:00. As an aside, similar notifications were also sent on the 16th, which is a Sunday, and not defined in the workhoursxy time period, i.e. no notifications should be sent that day at all.
$ mysql -NBr centreon_storage -e "select from_unixtime(start_time),from_unixtime(end_time) from servicestateevents where state=2 and in_downtime=0 and in_ack=0 and service_id=5678;"
[..]
2017-04-17 14:01:37 2017-04-17 14:06:27
2017-04-17 19:56:37 2017-04-17 20:01:27
2017-04-17 20:36:37 2017-04-17 20:41:27
2017-04-17 21:16:37 2017-04-17 21:21:27
[..]
The service "Windows_CPU" has the workhoursxy notification period defined (but a 24x7 monitoring time period), and uses the generic-host template, which also has workhoursxy notification period (with also 24x7 monitoring time period).
Centreon 2.7.7
Centreon Engine 1.5.1
Centreon Broker 2.11.5
The text was updated successfully, but these errors were encountered: