...
Here's what the definition for the check looks like:
| Property | Value | Note |
|---|---|---|
| Description | Backup Job | |
| Active checks enabled | False | Active checks are NOT enabled |
| Passive checks enabled | True | Passive checks are enabled (this is how results are reported) |
| Check freshness | True | |
| Freshness threshold | 93600 | 26 hour threshold, since backups may not always finish at the same time |
| Check command | no-backup-report | This command is run only if the service results are “stale" |
Notice that active checks are disabled. This is because the results for the checkare check are only made by an external application using passive checks. Freshness checking is enabled and the freshness threshold has been set to 26 hours. This is a bit longer than 24 hours because backup jobs sometimes run late from day to day (depending on how much data there is to backup, how much network traffic is present, etc.). The no-backup-report command is executed only if the results of the service are determined to be stale. The definition of the no-backup-report command might look like this...
| Property | Value |
|---|---|
| Name | no-backup-report |
| Command Line | /var/lib/shinken/libexec/check_dummy 2 "CRITICAL: Results of backup job were not reported!" |
If Shinken detects that the service results are stale, it will run the no-backup-report command as an active check. This causes the check_dummy plugin to be executed, which returns a critical state to Shinken. The check will then go into to a Critical state (if it isn't already there) and someone will probably get notified of the problem.
...