[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some feature notes for monit, volume II

From: Martin Pala
Subject: Re: Some feature notes for monit, volume II
Date: Sat, 10 Jul 2004 00:13:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.7-4


thanks for another feautures proposal :) My votes and some comments are in text.

Vlada Macek wrote:

### LED blinks, speaker screams on (some?) alerts

Something like this:

    set ledalert on        # constant keyboard LED blink
    set beepalert on    # let's say three beeps each 15 seconds

The alert e-mail does not necessatily reach the target box, cellphone,
... on time. In case of nasty situation is detected, the server should
IMHO try to catch the human eye or ear as soon as and any way possible.

This alert would also be handy in case of unreachable mailserver,
network connection, in short in situations where something nasty _might_
happen but the monit knows it wont be able to inform about it.

The ongoing beep or blink state could be presented on the HTML/XML/TEXT
output too together with the HTML button and console command to shut
them off immediatelly until the next state change.

-1 for led alert
0 for beep alert

It makes sense to support led and beep alert when you monitor services on your own workstation, but i think most monit deployments are on servers. Servers are usualy placed in datacenters and don't have any keyboard or human operator (datacenter is usualy 'human-unfriendly-environment' ;) so led alert is not very practical in my book.

### depends on groupname

Not really sure whether such thing may be useful, but again, it would
increase the configuration freedom. This way, the action may be
triggered by any service in the dependant group.

0 ... according to extreme programming guidelines, it is better to not complicate the code by any 'possibly useful' feature ;)

### Password hash directly on the ALLOW line

Something like this:

    allow user:0ec8266c6fbd441ea707864855f0368a20e82c36 sha1 read-only

I don't like to reveal my password to any reader, but using external
file like htpasswd is too uphill. I consider this way a reasonable


### New check: i-node number change
### Symlink target change (target string checksum?)

The first check could detect a hard link target change. The second one
allows one to detect whether the symlink was tampered with. These checks
mostly fall into the security measures category and are marginal here. I
just mention it as a small ideas.


### Multiple actions after THEN

AFAIK there is possible to define only one action now. EventAction_T in
monitor.h suggests it. I imagine the *next member in EventAction_T. :-)
For example

    if loadavg(1min) > 10.0 for 8 cycles then
        { exec "/usr/local/sbin/", stop }


### Variables in exec action

There are situations where it can become handy to pass the addition
infomation to underlaying utilities. Variables like $ACTION, $SERVICE...
used in mail-format might be expanded in exec command line too if wished...

    if loadavg(1min) > 10.0 for 8 cycles then
        exec '/usr/local/sbin/ "$SERVICE" "$ACTION"'

Environment variables are supported already, however action description is missing. For environment variables description see manual (for example:

+1 for adding MONIT_ACTION environment variable (to identify which particular action - start, stop, restart or exec, caused the script to execute).

### ifhost "dilbert" or "ginger" ... endif

I think I'm not the only one who uses monit to keep an eye on several
servers, not only one. Even when using INCLUDE and CVS to manage
multiple control files, there are still many same lines remaining. Such
feature of conditional compilation would allow me to have only one
monitrc for all my servers, which could lead me to systematic unified
configuration and helps to reveal the configuration mistakes.


There is a security disadvantage in this. A cracker who gets root access
on one of my servers would know exact monitoring configuration on the
rest of them. That's bad.

Instead I'm considering now using some general preprocessor e.g. GNU M4
to produce the set of monitrc files for particular servers after the CVS
checkout. Using M4 there is possible advanced magic like parametrized
macros, etc. I'll probably use it and can contribute a tutorial or
examples if anyone interested.

Sounds interesting :)

And now for something completely different:

### Encryption of all mail alerts using given PGP public key

I'm proposing later in this text that monit may be able to send some
sensitive data in the mail alerts and therefore it should be possible to
hide the alert body from the unintended eyes. It is possible to keep the
public key (even multiple ones) in ASCII armored form in control file.
This feature may deploy gnupg or similar package. The fact, that the
Subject line cannot be encrypted and still alerts any recipient could be
taken as an advantage.

In case the encryption is not possible by accident, the rich body would
not be sent, of course.

I'm not sure, but I think it is possible to encrypt data by multiple
public keys and decrypt it with any of them. This feature would fit this
application. Alerts could be encrypted by admin's key together with
company's key stored somewhere safe.


### Advanced e-mail alerting

In previous e-mail, there was a proposal about the rich XML report
(_status?format=xml request), where every <service> provides exhaustive
information about the tests being applied, the currently expected and
received values (for example checksums, send/expect x received strings).

In case this proposal will be implemented, then it might be interesting,
if monit puts entire XML report (or just the systemwide part and the
failed/recoveres services) into the encrypted e-mail message body. No
special mail structure need to be invented, XML form is already the best
one for technical processing and it will contain all information.
Nevertheless it may be possible to select HTML or TXT format too to be
put into the e-mail message body.

This way we are sending the detailed historical diagnostic and forensic
information somewhere far far away for deposit (perhaps out of the
touched domain). Everything may be cracked or shut down by unknown
reason, but once the data leave the domain, we are better informed

0, but interesting solution :)

Here are plans to add something very similar - standalone channel to upstream central monitoring servers which will collect data from monit agents.

### Embedding a Python interpreter

I'm going slightly mad... :-]

... i'm sure fridge managment and chess machine are important features too %-]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]