[Nagios-devel] template config syntax - some comments

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

[Nagios-devel] template config syntax - some comments

Post by Guest »

Hi,

I have only used nagios for a few days (and it is working fine) but I
have a few comments on the new template syntax I would like to share in
the hope they prove useful. I'm sorry this message is so long.

Firstly the new system is much much better than the old positional format
but has some anoying aspects (all IMHO):

1. The naming of service_description and host_name fields. As these
are both primary keys I expected them to be consistent so would have
expected service_name instead and also an alias in much the same
way as hosts have a host_name and an alias.

2. The use of host_ and service_ redundant prefixes given the define XXXX
already gave the context.

3. The inheritance syntax seems very awkward (i.e. the register field
and the strange extra "name" field). I would have thought something like

define service {
register 0
service_description foo
host_name somehost
check_period 24x7
...
}

define service {
use foo
service_description bar
...
}

would be better with a more C++/Java like system:

define template foo {
host_name somehost
check_period 24x7
...
}

define service bar extends foo {
check_freshness 1
...
}

The template is really just a named collection of tag/value pairs
so does not have to be syntax checked until it is "inserted" into
any object derived from it. I.e. define template is the same as having
register set to zero.

4. Macro naming. Why is the service_description field available as
$SERVICEDESC$ rather than $SERVICE_DESCRIPTION$ ? Consistency is
much easier to remember. If this is for backward compatability consider
adding new consistent-with-field-name macros as well.

5. Macro expansion not universal. Why does macro expansion work in
some places but not others? For example $SERVICEDESC$ will expand
in a command_line within a command but not in a check_command within
a service.

For example, If I have 20 disks I want to check I can use inheritance
as follows to try and cut down on typing:

# check disk space (uses service name as the path to check)
define command {
command_name my-check-diskspace
command_line $USER1$/check_disk -w 5% -c 1% -p /$SERVICEDESC$
}

# Base service which is inherited by all disk space checks
define service {
register 0
name df_base
hostname somehost
check_command my-check-diskspace
...
}

# for disk 1
define service {
use df_base
service_description /root
}
# for disk 2
define service {
use df_base
service_description /usr
}
etc. etc.

Rather than having to define my-check-diskspace command just to get
the macro expansion I would have liked to define df_base as:

define service {
register 0
name df_base
check_command check-diskspace!$SERVICEDESC$
...
}

6. Grouping/clustering. This is a big one and I have read the cluster
docs but they seem to be an almost external trick to group services
together when it ideally should be supported by the main config syntax.

Currently if I have a set of service tests I would like to group
I invent a new host_name (which shares address with some other real
host) and use it for those services. This seems like a kludge and
I would much prefer some form of service_group structure. A nested
service_group structure would be even better...

7. The Backup Job example service in the docs is just what I want
to do but because you have to set active_checks_enabled to 0
the CGI displays a large cross next to the service. This makes it look
like something is wrong. Is it possible to have some new flag like
check_only_if_stale for cases like this so can leave active_checks_enabled
and hence get a pretty display?

8. All time units should have optional suffix so can say "1d" instead
of 1440. See http://www.kernel.org/software/mon/example.cf for example
config file from a similar system.

Cheers,

--
Phil Davis





This post was automatically imported from historical nagios-devel mailing list archives
Original poster: pmd@hazy.org.uk
Locked