My proposal is to change the host to service relationship setup.
Instead of two record types, make it into three.
Service
ping-linux-server
Host
linux-server1
and
host_service
linux-server1
ping-linux-server
A host can have many services.
A service can have many hosts
In a many to many relationship, you create a third relationship
containing both items.
So you would have something like this:
define host {
host_name linux-server1
address 10.0.0.1
parent ...
notes ...
notes_url ...
icon_image ...
icon_image_alt ...
vrml_image ...
statusmap_image ...
2d_coords ...
3d_coords ...
}
define command{
service ping-server
description ping test a server
check_command_line ping $HOSTNAME$
timeout 10
}
define service {
service ping-linux-server
description ping test a linux server
check_command ping-server
normal_check_interval 5
freshness_threshold 30
Active_enabled 1
passive_enabled 0
parallelize 1
freshness_enabled 1
notes ...(generic instructions about what to do if ping fails =E2=80=93 i=
f the
host-service record does not contain details, info from here could be
used)
notes_url ...
}
define service {
service ping-windows-server
description ping test a windows server
check_command ping-server
normal_check_interval 4
freshness_threshold 20
Active_enabled 1
passive_enabled 0
parallelize 1
freshness_enabled 1
notes ...(generic instructions about what to do if ping fails =E2=80=93 i=
f the
host-service record does not contain details, info from here could be
used)
notes_url ...
}
define service {
service smtp-linux-servers
check_command
etc...
}
define host_service{ # only have things directly related to this
particular host-service combination
host linux-server1
service ping-linux-server
alias check linux-server is responding to a ping
notes ...(what to do if ping fails on this particular host)
notes_url ...
icon_image ...
icon_image_alt ...
action_url ...
statusmap_image ...
retain_staus_info
retain_non_status_info
process_perf_data
event_handler=20
event_handler_enabled
flap_threshold_low
flap_threshold_high
flap_threshold_enabled
notification_enabled
notification_command
notification_options
notification_retry_interval
notification_contact_group
execute_on_failure 1
}
Now, you can reuse the service definition for more hosts.
define host_service{
host linux-server2
service ping-linux-server
etc ...
}
define host_service{
host linux-server3
service ping-linux-server
}
You do not have to store all the service information again, against
every host.
Now if I decide my normal test interval needs to be changed, I change
one entry. Or, currently, I would craft a search and replace command to
do it. The same end result can be achieved, but if things are split
more, it is easier to accomplish.
In theory, the notification details should be removed into their own
section as well.
define notification{
notification_name email-linux-admins
notification_command mail ...
notification_options whatever
notification_retry_interval 5
notification_contact_group linux-admins
}
so the host_service definition becomes
define host_service{ # only have things directly related to this
particular host-service combination
host linux-server
service ping-linux-server
alias check linux-server is responding to a ping
notes ...(what to do if ping fails on this particular host)
notes_url ...
icon_image ...
icon_image_alt ...
action_url ...
statusmap_image ...
retain_staus_info
retain_non_status_info
process_perf_data
event_handler=20
event_handler_enabled
flap_threshold_low
flap_threshold_high
flap_threshold_enabled
notification_enabled
notification_name email-linux-admins
}
If a =E2=80=9Cexecute_on_failure=E2=80=9D flag is added to the host-servi=
ce record, it
would actually allow more than one test if a servi
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]