Scheduler¶
Use this to schedule check commands and jobs in conjunction with for instance passive monitoring through NSCA
Enable module¶
To enable this module and and allow using the commands you need to ass Scheduler = enabled to the [/modules] section in nsclient.ini:
[/modules]
Scheduler = enabled
Samples¶
Feel free to add more samples on this page
Using the scheduler¶
The scheduler will run commands ate given intervals (or schedules) and submit the result to a module (such as NRDP or NSCA) which will submit the result to a remote monitoring server. This is in the Nagios(TM) world referred to as passive monitoring.
A simple schedule looks like this:
[/settings/scheduler/schedules/default]
interval = 5s
channel = log
[/settings/scheduler/schedules]
eventlog=check_eventlog log=application
CPU Load=check_cpu
The above configuration use the inherited default section to set some defaults and then adds two schedules this is convenient if you want to add many schedules which are similar. It is identical to the following:
[/settings/scheduler/schedules/default]
interval = 5s
channel = log
[/settings/scheduler/schedules/eventlog]
command=check_eventlog log=application
[/settings/scheduler/schedules/CPU Load]
command=check_cpu
Interval or schedules?¶
There are two way to schedule things:
. interval - The command will be run at around ever x seconds (or minutes)¶
. schedule - The command will be executed at given times.¶
The interval is the normal scenario if you do not care when something ix executed as long as it is reoccurring. You can even set randomness to make sure the time is random. The reason shy most people want this is that it makes the network load more even. If you schedule your entire server infrastructure to run the checks at 13:00 you will have a network spike.
The following example use interval to schedule the check ever 10 minutes:
[/settings/scheduler/schedules/CPU Load]
interval = 5s
channel = log
command=check_cpu
The following does the same using schedule instead:
[/settings/scheduler/schedules/CPU Load]
schedule=0,10,20,30,50 * * * *
channel = log
command=check_cpu
The syntax of the schedule is similar to a cron expression in that you have:
| Name | Allowed Values | Allowed Special Characters |
|---|---|---|
| Seconds | 0-59 | , * |
| Minutes | 0-59 | , * |
| Hours | 0-23 | , * |
| Day of month | 1-31 | , * |
| Month | 0-11 | , * |
| Day of week | 1-7 | , * |
Running a check at startup¶
Both interval and schedule only report for the first time once the interval (or
the next matching time) has elapsed. With a long interval that leaves the
monitoring server with the old result for a long time after a reboot - exactly
when the status is most likely to have changed. Set run on startup to run the
command once as soon as the agent has started:
[/settings/scheduler/schedules/uptime]
interval = 1h
channel = NSCA
command = check_uptime
run on startup = true
The schedule is otherwise unaffected: the next run follows an hour after the startup run. The startup run also happens after a configuration reload, so a schedule you just changed reports its new status right away.
Setting it on the default section turns it on for every schedule which does not override it:
[/settings/scheduler/schedules/default]
interval = 1h
channel = NSCA
run on startup = true
If you have a lot of schedules and do not want all of them to report at the very same instant, spread the startup runs out over a window:
[/settings/scheduler]
startup window = 30s
Configuration¶
| Path / Section | Description |
|---|---|
| /settings/scheduler | Scheduler |
| /settings/scheduler/schedules | Schedules |
Scheduler ¶
Section for the Scheduler module.
| Key | Default Value | Description |
|---|---|---|
| startup window | 0s | Startup window |
| threads | 5 | Threads |
| timezone | local | Timezone |
# Section for the Scheduler module.
[/settings/scheduler]
startup window=0s
threads=5
timezone=local
Startup window ¶
Time over which schedules with ‘run on startup’ are spread out when the agent starts. The default (0s) runs them all immediately; raise it if you have many startup schedules and do not want to hit the monitoring server with all of them at once.
| Key | Description |
|---|---|
| Path: | /settings/scheduler |
| Key: | startup window |
| Default value: | 0s |
Sample:
[/settings/scheduler]
# Startup window
startup window=0s
Threads ¶
Number of threads to use.
| Key | Description |
|---|---|
| Path: | /settings/scheduler |
| Key: | threads |
| Default value: | 5 |
Sample:
[/settings/scheduler]
# Threads
threads=5
Timezone ¶
Reference clock for cron expressions. Accepts ‘local’ (default — standard cron semantics), ‘utc’/’gmt’ (restores the pre-0.13 behaviour), or any POSIX TZ string such as ‘EST-05EDT,M3.2.0,M11.1.0’. Unparseable values fall back to UTC and are flagged in the tz label as ‘UTC?’.
| Key | Description |
|---|---|
| Path: | /settings/scheduler |
| Key: | timezone |
| Default value: | local |
Sample:
[/settings/scheduler]
# Timezone
timezone=local
Schedules ¶
Section for the Scheduler module.
This is a section of objects. This means that you will create objects below this point by adding sections which all look the same.
Keys:
| Key | Default Value | Description |
|---|---|---|
| alias | ALIAS | |
| channel | SCHEDULE CHANNEL | |
| command | SCHEDULE COMMAND | |
| interval | SCHEDULE INTERVAL | |
| is template | false | IS TEMPLATE |
| parent | default | PARENT |
| randomness | RANDOMNESS | |
| report | REPORT MODE | |
| run on startup | RUN ON STARTUP | |
| schedule | SCHEDULE | |
| source | SOURCE | |
| target | TARGET |
Sample:
# An example of a Schedules section
[/settings/scheduler/schedules/sample]
#alias=...
#channel=...
#command=...
#interval=...
is template=false
parent=default
#randomness=...
#report=...
#run on startup=...
#schedule=...
#source=...
#target=...