notification_period not honoured on host config?

[mikej]

Thanks for that abrist, I think I'm almost there.

If I have the generic-host template:

Code: Select all

define host{
        name                            generic-host    ; The name of this host template
        notifications_enabled           1               ; Host notifications are enabled
        event_handler_enabled           1               ; Host event handler is enabled
        flap_detection_enabled          1               ; Flap detection is enabled
        failure_prediction_enabled      1               ; Failure prediction is enabled
        process_perf_data               1               ; Process performance data
        retain_status_information       1               ; Retain status information across program restarts
        retain_nonstatus_information    1               ; Retain non-status information across program restarts
        notification_period             24x7            ; Send host notifications at any time
        register                        0               ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEM

Followed by a linux-server template:

Code: Select all

define host{
        name                            linux-server    ; The name of this host template
        [b]use                            generic-host[/b]    ; This template inherits other values from the generic-host template
        check_period                    24x7            ; By default, Linux hosts are checked round the clock
        check_interval                  5               ; Actively check the host every 5 minutes
        retry_interval                  1               ; Schedule host check retries at 1 minute intervals
        max_check_attempts              10              ; Check each Linux host 10 times (max)
        check_command                   check-host-alive ; Default command to check Linux hosts
        notification_period            workhours       ; Linux admins hate to be woken up, so we only notify during the day
                                                        ; Note that the notification_period variable is being overridden from
                                                        ; the value that is inherited from the generic-host template!
        notification_interval           120             ; Resend notifications every 2 hours
        notification_options            d,u,r           ; Only send notifications for specific host states
        contact_groups                  admins          ; Notifications get sent to the admins by default
        register                        0               ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }

In this case, the use generic-host directive is causing any host that is labeled as linux-server, to grab the notification_period directive from generic-host (which is 24x7, which is why i'm always getting emails).

But what you are saying is that it the inheritance actually happens for each service check? As in, I cannot have a service check using the generic-service check if I want each custom service to have it's own notification period?

More aptly - it's best not to define the notification_period directive in the generic-service template because I want custom notifications for each service? IE comment out the notification_period directive as per below and custom define it on every service check?

Code: Select all

define service{
        name                            generic-service         ; The 'name' of this service template
        active_checks_enabled           1                       ; Active service checks are enabled
        passive_checks_enabled          1                       ; Passive service checks are enabled/accepted
        parallelize_check               1                       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1                       ; We should obsess over this service (if necessary)
        check_freshness                 0                       ; Default is to NOT check service 'freshness'
        notifications_enabled           1                       ; Service notifications are enabled
        event_handler_enabled           1                       ; Service event handler is enabled
        flap_detection_enabled          1                       ; Flap detection is enabled
        failure_prediction_enabled      1                       ; Failure prediction is enabled
        process_perf_data               1                       ; Process performance data
        retain_status_information       1                       ; Retain status information across program restarts
        retain_nonstatus_information    1                       ; Retain non-status information across program restarts
        is_volatile                     0                       ; The service is not volatile
        check_period                    24x7                    ; The service can be checked at any time of the day
        max_check_attempts              3                       ; Re-check the service up to 3 times in order to determine its final (hard) state
        normal_check_interval           5                       ; Check the service every 10 minutes under normal conditions
        retry_check_interval            1                       ; Re-check the service every two minutes until a hard state can be determined
        contact_groups                  admins                  ; Notifications get sent out to everyone in the 'admins' group
        notification_options            w,u,c,r,f               ; Send notifications about warning, unknown, critical, and recovery events
        notification_interval           60                      ; Re-notify about service problems every hour
        #notification_period             24x7                    ; Notifications can be sent out at any time
         register                        0                      ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

Thank you kindly for your help.

[abrist]

More aptly - it's best not to define the notification_period directive in the generic-service template because I want custom notifications for each service? IE comment out the notification_period directive as per below and custom define it on every service check?

Yes. The local object will always take precedence.

The order of precedence for time periods for a service is:

1. service object itself
2. service template
3. host object itself
4. host template
5. Defaults (for time periods it is 24x7)

[mikej]

Okay so one last follow-up then.

If I leave the notification_period directive in the generic-service template definition, <-- that will be honoured even if I specificy a notification_period directive on each specific service check defined in server.domain.com.cfg? IE no matter what is in the specific service check, the notification_period will be taken from the generic-service template if it's defined there?

[abrist]

No. If it is defined on the service check (what I called the service object in the previous post), that "local" definition will take precedence over all others. The service template will only effect settings which are not defined on the service itself.

[mikej]

Thanks, abrist.

After adding a notification_period directive to a specific service check within the server.domain.com.cfg file, I was no longer receiving notifications outside the timeperiod indicated. This really helped me clear up this issue. Thank you for your assistance, much appreciated.

Mike

[slansing]

Awesome, glad to hear you got this resolved.