Projects / MoSSHe

MoSSHe

MoSShE (MOnitoring in Simple SHell Environment) is a simple, lightweight (both in size and system requirements) server monitoring package designed for secure and in-depth monitoring of a handful of typical/critical Internet systems. It supports email alerts and SLA monitoring out of the box, and whatever you can script. The system is programmed in plain (Bourne) SH, and made to be compatible with BASH and Busybox so it can easily be deployed on embedded systems. Monitoring is designed to be distributed over multiple systems, usually running locally. As no parameters are accepted from the outside, checks cannot be tampered or misused from outside. The system is designed to allow decentralized checks and evaluation as well as classical agent-based checks with centralized data accumulation. Agent data is transferred via HTTP, so available Web servers can be co-used for agent data transfer. Each agent creates simple (static) HTML pages with full and condensed status reports on each system, allowing simple local checks.

Tags
Licenses
Operating Systems
Implementation

RSS Recent releases

  •  21 Feb 2014 03:49

Release Notes: This release adds NetworkLinuxBandwidth, checking against /proc/net/dev. It adds NetworkTrafficCheck, checking against /proc/net/dev. ServerInfo() did not delete old data, leading to increasing transfer and disk exhaustion (in the long rung); this has been fixed.

  •  04 Feb 2014 11:27

Release Notes: This release added a monthly NetworkBandwidth check with GB/month. HDCheckGB was added. It is like HDCheck but in GB. HDparmState was added to check whether a disc is spun down. ImportServerInfo and a FileLines check were added. Server info placement was corrected. A new functions.virtual module was added, and VServer-checks were moved into that module. Virtuzzo/OpenVZ VZbeancounter checks were added.

  •  15 May 2013 21:53

Release Notes: This release adds VSERVER load check + graph generation on the client side using HTML5-JavaScript (also fixes broken AVG graph generation and is less CPU-intensive on the server). It corrects WWWDIR-handling (now using a variable instead of a fixed value), and fixes a missing SERVER headline in group entry. CheckVserverUp/Down is now listed under the vserver name instead of the host server name. ReapPassive is now listed under the reaped name instead of the host server name. HTML section identification is independent of time.

  •  20 Sep 2012 21:04

Release Notes: This release fixes a copy-paste error in the MailQueue check. It fixes an incorrect CUT parameter in ReapPassiveChecks. It has a more stable memory check. HTTPcontentmatch is done with wget instead of nc. More stable when encountering Web applications. The template automatically configures %WWWDIR%. VServer-related checks have been added.

  •  29 Jun 2011 16:05

Release Notes: Bugs were fixed in SAMBAcheck to remove CRON chatter and to correct server name. Lock message and internal logging were improved to find lockups. A typographical error in the example mosshe script was fixed and it was extended. A typographical error in ImportAgents was fixed. A generic hardware sensor check was added (HardwareTemp and HardwareFan will be deprecated). IPv6 pings were added: Ping6Partner, Ping6Loss, Ping6Time. Average graphing/plotting were added.

RSS Recent comments

23 Apr 2014 04:45 Avatar starstube

wondeful

23 Jun 2010 08:54 vtanger

The older comments (below) are for 1.x tree which was based on a completely different application architecture.

06 Nov 2007 13:00 vtanger

Re: MoSSHe != Nagios by purpose

> False. Nagios would only be able execute commands for which it has permission.

MoSSHe likewise - but while MoSSHe's default setup does not need any extra command limitation, the whole Nagios' check_by_ssh security depends on the proper keyfile setup.

> % (2) MoSSHe cannot become overloaded by too many checks - Nagios can.

> The first two paragraphs of your readme contradict that. "A handful of hosts..."

> I've had nagios doing check_by_ssh with far more than a handful with no performance issues.

MoSSHe is "... *intended* to..." - but can do more. A small but important difference.

What happens if you set the poll interval in Nagios way too low, so that a check cycle has not yet finished before the next starts (or was that issue finally resolved)? MoSSHe is implicity un-overloadable.

> % (3) MoSSHe uses far less ressources.

>

> They're both making an ssh connection [...]

As for SSH, okay, CPU-wise the remaining processing won't matter much. But see the overload issue above.

Web-niceties aside MoSSHe only needs a shell (even runs on busybox) and as such needs less memory - which is not unimportant if monitoring embedded devices esp. on the client side (one quick external hint on that might be Nagios: 1.7M tarball - MoSSHe: 28k tarball).

> Without reviewing your actual source code, I still don't understand how it can be any safer...

See the configuration of client-side checks. There is the difference.

Back to initial question: why did Nagios reinvent the wheel when there already was BigBrother, MRTG et al.? I guess as each NMT has its own strengths, each one fills its own niche - as does MoSSHe, as does Nagios.

06 Nov 2007 11:50 AHinMaine Thumbs down

Re: MoSSHe != Nagios by purpose

>

> Three big differences

> (1) Someone hacking the Nagios host can

> execute *any* command on the remote host

> with check_by_ssh. With MoSSHe he can

> only get the newest status, nothing

> else.

False. Nagios would only be able execute commands for which it has permission.

> (2) MoSSHe cannot become overloaded by

> too many checks - Nagios can.

The first two paragraphs of your readme contradict that. "A handful of hosts..."

I've had nagios doing check_by_ssh with far more than a handful with no performance issues.

> (3) MoSSHe uses far less ressources.

They're both making an ssh connection and running a simple command. Resource consumption and the difference between them is negligible at best.

> I do know Nagios - I even wrote the

> first SSH-based plugins for it ~5 years

> ago, see e.g.

> www.wyae.de/software/R...

> Both systems have their merit - MoSSHe

> is safer, leaner and leaning more

> towards checking internet servers,

> whereas Nagios has more functions and is

> oriented more towards network

> management.

Without reviewing your actual source code, I still don't understand how it can be any safer...

06 Nov 2007 10:35 vtanger

MoSSHe != Nagios by purpose

> This seems like a whole lot of wheel

> reinvention for something that can

> already be done with nagios and its

> check_by_ssh plugin.

Three big differences

(1) Someone hacking the Nagios host can execute *any* command on the remote host with check_by_ssh. With MoSSHe he can only get the newest status, nothing else.

(2) MoSSHe cannot become overloaded by too many checks - Nagios can.

(3) MoSSHe uses far less ressources.

I do know Nagios - I even wrote the first SSH-based plugins for it ~5 years ago, see e.g. www.wyae.de/software/R...

Both systems have their merit - MoSSHe is safer, leaner and leaning more towards checking internet servers, whereas Nagios has more functions and is oriented more towards network management.

Screenshot

Project Spotlight

ncdc

An NCurses-based Direct Connect client.

Screenshot

Project Spotlight

NetStats Baseball

A simulation of major league baseball.