Back to files

INTRODUCTION

LVSmon is a cluster monitoring daemon written originally with the intention of replacing tools like ldirectord and mon with regards to maintaining LVS tables.

GETTING LVSMON

The lvsmon website is at:

http://www.scaramanga.co.uk/lvsmon/

To get a specific version of lvsmon you can download from:

http://www.scaramanga.co.uk/lvsmon/vX.Y.Z/lvsmon-X.Y.Z.tar.gz

USAGE

The following command will give you correct information on lvsmon usage (I cannot always promise to keep these docs up to date).

lvsmon --help

The usual invocation will go something like this:

lvsmon --file /etc/lvsmon.conf --interval 10

This tells lvsmon to use the file /etc/lvsmon.conf as the config file and to check all services once every ten seconds.

KNOWN BUGS (FEATURES)

failure count stops counting after 4 billion failures, this is because if it carrys on the variable will wrap. There isn't much that can be done about this... With default settings this problem will occur after 1268 years of operation.

WHY USE LVSMON?

It's secure and reliable. It will never run away. It will never give you the wrong output. It will not allow people to take over system. I would put money on it.

Performance. It uses very little CPU time, has a small footprint and scales better than most even considering the fact that it runs in a single thread.

FEATURES

Edge triggered status notification
Runs in a single non-blocking thread
Does no dynamic allocation after entering main loop Uses very little memory (about 60B per service on a 32bit platform) Scales reasonably well (poll driven)
Provably correct design, LVSmon will never run away with resources Pauses 500ms before exiting with errors, stops runaway interactions Portable (ANSI C/POSIX)
Timeouts enforced on connection and receive events Report nature of failures (eg: conn refused, 404 error etc..) HTTP plugin, checks response according to RFC 1945 Banner checker plugin - will work for SSH, SMTP, POP3, etc...

PHASES

What follows is a brief description of each phase in a monitors life cycle. A monitor is essentially a state machine

PHASE_CONNECT
Create a socket if necessary and initiate a connection. Poll for writing.

PHASE_CONRESULT
getsockopt() to see if the connection succeeded. If it did, the socket is now writable so go to query.

PHASE_QUERY
Send a query, this usually won't block because the last poll() told us the socket is writable. Now poll for input.

PHASE_RECV
Poll tells us we have input so a recv() will not block. Do the recieve and get out of there. If the plugin requires it, then check the results, otherwise the fact that poll for readability succeeds is indication enough of success.

PHASE_WAIT
Check results of the last cycle and act accordingly. Wait until we are needed again, then go to PHASE_CONNECT.

TODO

Features: Better event reporting mechanism Allow failure timeouts (eg: 3 strikes and your out) Allow failure timeouts (eg: no success for 5 minutes) Support plugins that dont use TCP Make timing more accurate Support complex transactions Make plugins plugins :) Use getopt in plugins for option passing http: Support full URLs Drop root privileges and chroot if started as root