last straw, then I’m out of ideas: Is the time where you expect the notifications inside the configured time period?
1 Like
I had defined the time periods on a Timeperiod template and havn’t got any notifications. moved the timeperiods from template to actual timperiods in director and it worked.
1 Like
I added the timeperiods trying to get working. They weren’t initial present, and not really needed at this stage.
Just spotted adding // include_recursive "conf.d" has stopped my generic-service pings, I’ve added back through Director but now the graphs are bust. 
I dont have any timeperiod templates either.
you can move the required conf files do /etc/icinga2/zones.d/yourMasterZoneNameFolder, so you do not need to recreate this in the director, if you don’t want it. Sadly, I have not idea for you other problem.
1 Like
been on this two weeks, now nearly 700 services monitored, but can’t get an alert out… : 
is this working too?
Though it needs to be
object TimePeriod "24x7" {
import "legacy-timeperiod"
import "24x7_template"
ranges = {
"friday" = "00:00-24:00"
"monday" = "00:00-24:00"
"saturday" = "00:00-24:00"
"sunday" = "00:00-24:00"
"tuesday" = "00:00-24:00"
"wednesday" = "00:00-24:00"
}
}
1 Like
Not sure why my time ranges wouldnt work, but will try your 24x7 suggest just in case.
I’ve removed the // include_recursive "conf.d" and my ping graphs now work again.
good catch, this does not work afaik! Strange that the config validation does not complain.
You have to define time periods like @unic posted, at least that’s how I have always done it
1 Like
I’ve now got.
zones.d/director-global/timeperiods.conf
object TimePeriod "24x7_template" {
import "legacy-timeperiod"
display_name = "24x7_template"
ranges = {
"friday" = "00:00-24:00"
"monday" = "00:00-24:00"
"saturday" = "00:00-24:00"
"sunday" = "00:00-24:00"
"thursday" = "00:00-24:00"
"tuesday" = "00:00-24:00"
"wednesday" = "08:00-18:00"
}
}
Same. not sent out to any contact why is this so difficult!
Just to be sure: You don’t get any information about a send notification in the history of the service?
If you send a custom message from the service “send notification” with “forced” enabled, do you still don’t get a message?
I would start over with the service notification and clone as much as possible from the Host notification. Same Users, same Timeperiod, etc. I’pretty sure something is missing there, like a user with an emailaddress, a proper timerange ore something else. I’am not 100% sure but your error . not sent out to any contact is likly because of wrong user groups/users and/or timeranges.
edit: what you can do is to post an updates version of your service notification configuration including user, usergroup, timerange and templates involved. The Thread has advanced for a while and its now a little bit puzzling.
1 Like
That’s where the not sent out to any contact is listed
That worked… a forced service message was received.
If a forced message works to the address, surely that means the addresses are good.
I’ve redone the time range, not sure what else to try
Compare your host and service notification. there must be a difference in it. Different Timerange, Users etc. Also compare all templates that are involved (notification and timerange). Check that the timeranges are correct in the timerange, not in the timerange template. Thats all i have. Post your actual (resolved) notification config for host and service including users, if we should take a look too.
It does. Just tested this here.
michi@mbpmif /usr/local/icinga/icinga2/etc/icinga2/tests $ icinga2 daemon -C
Closed FD 6 which we inherited from our parent process.
[2020-01-24 16:53:51 +0100] information/cli: Icinga application loader (version: v2.11.0-473-g18eb06e33; debug)
[2020-01-24 16:53:51 +0100] information/cli: Loading configuration file(s).
[2020-01-24 16:53:51 +0100] information/ConfigItem: Committing config item(s).
[2020-01-24 16:53:51 +0100] information/ApiListener: My API identity: mbpmif.int.netways.de
[2020-01-24 16:53:51 +0100] critical/config: Error: Validation failed for object 'invalid' of type 'TimePeriod'; Attribute 'ranges': Invalid time specification 'monday, tuesday, wednesday, thursday, friday': Invalid time specification: monday, tuesday, wednesday, thursday, friday
Location: in /usr/local/icinga/icinga2/etc/icinga2/tests/tps.conf: 2:1-2:75
/usr/local/icinga/icinga2/etc/icinga2/tests/tps.conf(1): object TimePeriod "invalid" {
/usr/local/icinga/icinga2/etc/icinga2/tests/tps.conf(2): ranges = { "monday, tuesday, wednesday, thursday, friday" = "08:00-18:00" }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/icinga/icinga2/etc/icinga2/tests/tps.conf(3): }
/usr/local/icinga/icinga2/etc/icinga2/tests/tps.conf(4):
[2020-01-24 16:53:51 +0100] critical/config: 1 error
[2020-01-24 16:53:51 +0100] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.
Within the Director, the deployment will then fail. This is what I would check in the first place, if the configuration actually is deployed to production.
Please add the output of
icinga2 object list --type TimePeriod --name 24x7_template
icinga2 object list --type Notification --name 'host.fqdn.com!winservice Windows Remote Desktop Services!MIS_MainNotification_Service'
icinga2 object list --type User --name MIS
Cheers,
Michael
1 Like
Here’s the config, there’s a few differences but on as a result of trying things.
zones.d/director-global/timeperiods.conf
object TimePeriod "24x7_template" {
import "legacy-timeperiod"
display_name = "24x7_template"
ranges = {
"friday" = "00:00-24:00"
"monday" = "00:00-24:00"
"saturday" = "00:00-24:00"
"sunday" = "00:00-24:00"
"thursday" = "00:00-24:00"
"tuesday" = "00:00-24:00"
"wednesday" = "08:00-18:00"
}
}
zones.d/cyllene/usergroups.conf
object UserGroup "misGroup" {
display_name = "msiGroup"
}
zones.d/director-global/user_templates.conf
template User "MisUser" {
enable_notifications = true
period = "24x7_template"
states = [ Down, Up ]
types = [
Acknowledgement,
Custom,
DowntimeEnd,
DowntimeRemoved,
DowntimeStart,
FlappingEnd,
FlappingStart,
Problem,
Recovery
]
groups = [ "misGroup" ]
}
zones.d/cyllene/users.conf
object User "MIS" {
import "MisUser"
display_name = "MIS"
email = "MIS@fqdn.com"
period = "24x7_template"
groups = [ "misGroup" ]
}
zones.d/cyllene/notification_templates.conf
template Notification "MIS_Gen_Services" {
command = "mail-service-notification"
interval = 15m
period = "24x7_template"
user_groups = [ "misGroup" ]
users = [ "MIS" ]
}
template Notification "MIS_General_Host" {
command = "mail-host-notification"
interval = 15m
user_groups = [ "misGroup" ]
users = [ "MIS" ]
}
zones.d/cyllene/notification_apply.conf
apply Notification "MIS_MainNotification_Service" to Service {
import "MIS_Gen_Services"
assign where host.address
states = [ Critical, OK, Warning ]
types = [
Acknowledgement,
Custom,
DowntimeEnd,
DowntimeRemoved,
DowntimeStart,
FlappingEnd,
FlappingStart,
Problem,
Recovery
]
user_groups = [ "misGroup" ]
}
apply Notification "MIS_MainNotification_Host" to Host {
import "MIS_General_Host"
assign where host.address || host.enable_notifications
states = [ Down, Up ]
types = [
Acknowledgement,
Custom,
DowntimeEnd,
DowntimeRemoved,
DowntimeStart,
FlappingEnd,
FlappingStart,
Problem,
Recovery
]
user_groups = [ "misGroup" ]
users = [ "MIS" ]
}
I want to see the compiled final objects hence my question specifically for icinga2 object list.
Also, if that wasn’t asked already in this topic, enable the debug log and trace the notification object until it tries to fire notifications for the users.
Your User is configured to only get UP and Down for Host, as a service is newer going down, but critical,warning, etc. you will not get notified…
You posted that user before, which is correct.
zones.d/cyllene/users.conf
object User "myname" {
display_name = "my name"
email = "email@fqdn. com"
enable_notifications = true
states = [ Critical, Down, OK, Up, Warning ]
types = [
Acknowledgement,
DowntimeEnd,
DowntimeRemoved,
DowntimeStart,
Problem,
Recovery
]
groups = [ "MIS" ]
}
But he/she are not in the group you defined for the servicenotifications. At least not anymore
1 Like