[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: timestamp monitoring + code simplification patch
From: |
Martin Pala |
Subject: |
Re: timestamp monitoring + code simplification patch |
Date: |
Fri, 29 Nov 2002 17:13:24 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 |
Jan-Henrik Haukeland wrote:
Christian Hopp <address@hidden> writes:
The syntax is right now,
CHECK name PIDFILE path ...options... (1)
If we want to be "compatible" with (1) we need the following,
CHECK name [PIDFILE|DEVICE|DIRECTORY|FILE] path ...options...
But do we want to be quite that compatible? since it makes for some
awkward statement like.
CHECK iplanet_stored FILE "/usr/iplanet/msg-ims1/config/stored.ckp"
CHECK foo_dir DIRECTORY "/foo/directory"
CHECK mylittlebigharddisk DEVICE /dev/hda1
IMO it looks better, simply to say:
CHECK FILE "/usr/iplanet/msg-ims1/config/stored.ckp"
CHECK DIRECTORY "/foo/directory"
CHECK DEVICE /dev/hda1
[FILE, DIRECTORY and DEVICE will become reserved keywords.]
that way you are spared for making up imaginary descriptive names for
the file, directory and device like 'iplanet_stored'.
It will not crash with the current check statement either (1):
CHECK name PIDFILE PATH
To summarize, I vote +1 for using the following check statements:
CHECK name PIDFILE PATH
CHECK [FILE|DIRECTORY|DEVICE] PATH
In addition maybe include this variant for the process check statement
for symetrical reasons:
CHECK PROCESS name PIDFILE PATH
What do you think?
I agree, so we can have:
CHECK [FILE|DIRECTORY|DEVICE] PATH options,...
CHECK [PROCESS] name options,...
Next possibility can be to make name standalone option such as "NAME
name". It could be required (for PROCESS only) or optional statement
(for all major statement types). If it will be defined for PROCESS as
optional too and the "NAME name" won't be defined, monit can take its
name from common required option (path) or map the process's pid to its
name from process table. PIDFILE will come in such case empty helper
word. Syntax:
CHECK [PROCESS|FILE|DIRECTORY|DEVICE] PATH options,...
1.) example (verbose version):
CHECK PROCESS [WITH PIDFILE] "/var/run/sshd.pid"
NAME sshd
START "/etc/init.d/sshd start"
[...]
CHECK FILE "/data/customer"
NAME journal ( ... FILE type needn't support for this statement - it
can be completely avoided in the parser)
SIZE > 10 MB ALERT
TIMESTAMP > 1 DAY ALERT
[...]
2.) example (less verbose version):
CHECK PROCESS "/var/run/sshd.pid"
[NAME sshd] ( ... it could be >optional< there as well OR it can be
PROCESS type >required< option)
START "/etc/init.d/sshd start"
[...]
CHECK FILE "/data/customer"
SIZE > 10 MB ALERT
TIMESTAMP > 1 DAY ALERT
[...]
I'm inclined maybe more for this syntax and to make "NAME name" optional
for PROCESS too. In the case that the user won't define "NAME name", we
can use just required path to the pidfile as process/object's name - the
user should know what he does, when he don't use NAME statement, so as
described above, extra mapping the process PID to the name won't be
needed. Optional NAME statement for other types can be usefull to have
shortcut for the event of error message (it could be used to avoid
receiving path to the file/device/etc. on the mobile phone).
What about it? If it won't be acceptable for you, i agree with Jan's
syntax (not to require name for other major statements such as FILE, etc.)
Martin
Re: timestamp monitoring + code simplification patch, Martin Pala, 2002/11/29