Table of Contents
- Host doesn't show up in M/Monit
- Jabber "Authentication failed"
- Systems settings and scaling
- M/Monit Software Version Scheme
- Bulk remove Inactive hosts
- License Quota
Keywords: mmonit settings configuration host top
Each Monit instance is identified by a unique ID, stored in the file, $HOME/.monit.id on the host running Monit. $HOME is the home directory of the user running Monit. This file is automatically created at startup by Monit if it does not exist. Care should be taken not to delete or change this file as the ID is used to pair messages from Monit with a host entry in M/Monit.
If the ID file is duplicated on multiple machines (this can happen if you clone the system including the Monit ID file) then several Monit instances will update the same host entry in M/Monit.
If this is the case, you will need to change or generate a new Monit ID file for those machines that does not show up in M/Monit:
- Stop monit on the host with the duplicate ID
- Change the Monit ID. If you use Monit 5.8 or newer, use monit -r to reset the ID. For older Monit versions just remove the ID file. For example: rm -f ~/.monit.id (the location can have been changed with the "set idfile" statement in .monitrc),
- Start monit (it will automatically generate a new ID file)
Keywords: jabber auth login top
M/Monit use the SASL PLAIN authentication mechanism to login to a jabber server. If M/Monit reports an "Authentication failed" error, please make sure that you have this authentication mechanism enabled in your server. Also make sure that your jabber server software is updated. Several jabber servers (jabberd, prosody, ejabber) have a bug in their SASL PLAIN implementation which only recently has been fixed. For instance, ejabberd before version 2.1.2 had this bug.
Keywords: mmonit settings configuration scaling top
The sketch below describe the basic architecture of the M/Monit Connector. The Connector is the main processing component in M/Monit and is responsible for reading requests and creating responses. Many more sub-components are in use, but here we focus on the parts of the Connector which are configurable from server.xml via the <Connector> element; in practice, the number of processor threads (processors) and processorTimeout. Of these, the processors attribute is the most important.
Contrary to what one may think, increasing the number of processor threads may not help with scaling nor speed up M/Monit. In fact the effect is often the opposite. The reason is that M/Monit uses locking internally and adding more threads may lead to lock contention, that is, threads may fight over the same lock which can slow down the server. In addition, and to a lesser extent, the OS kernel has to do context-switching between threads, that is, pause a running thread, wake up and start the next thread in the queue etc. This context switching can also lead to a slowdown if there are many threads.
As a rule of thumb we recommend using the following settings in server.xml:
- Set the processor attribute of <Connector> to 10 or to the number of CPU cores on the machine M/Monit is running if this number is higher.
- The Database connection pool defined in <Realm>. Set maxConnections to 25. Adding more connections might only slow down the system.
Short description: 1. When a new request is received it is put in a first-in-first-out (FIFO) request queue. 2. The first available processor thread will dequeue the request, process it and create the response. If no threads are available, a new thread is created if the pool contains less than processor number of threads. Otherwise, the request waits in the queue and as soon as a processor thread becomes available it will dequeue and process the first request in the queue. If there are no more incoming requests, a processor thread will hang around for processorTimeout seconds, waiting for more work before it exit. This means that during peak hours, the pool will have max processor threads available to handle requests. and during slow periods, threads will be closed down and thereby reduce the resources used by M/Monit. 3. and 4. Once a response is created it is put on an outbound i/o queue. One I/O thread is used to flush the queue and write output non-blocking. This means that a processor thread works fast because there normally is no read or write i/o done by the thread.
The system's per process file descriptor limit defines a hard limit on how many concurrent connections M/Monit is allowed to handle as each connection to the M/Monit server requires at least one file descriptor.
In the old days, many Unix systems had the number of file descriptors allowed per process set to a low number. Today the opposite can be a problem. A too high limit can make M/Monit use unnecessary resources. M/Monit allocates a file descriptor table at startup based on available descriptors. At run-time, M/Monit polls the same table. We recommend setting the limit to
"#Monit Agents + 1024". This is best done by using
ulimit -n on the same command line before starting M/Monit. For example;
ulimit -n 4096; /opt/mmonit/bin/mmonit
Keywords: mmonit version numbers top
The version number scheme used by M/Monit and Monit is, major.minor.revision, for example M/Monit version 3.2.1 . Where Major is a major update to the software, Minor is a small update to the software and Revision is any change made (bug fixes, small updates). Minor and Revision releases are free while Major releases typically requires a License upgrade. M/Monit releases can seen here
Keywords: mmonit inactive bulk top
With the rise of use of virtualization clouds like Amazon EC2, you might find your M/Monit application overcome with too many inactive hosts, here is one simple solution for bulk removal using the M/Monit API https://github.com/tsaavik/remove-inactive-mmonit
Keywords: mmonit license exception top
If your M/Monit license has a Host quota and an extra Host was inadvertently added, M/Monit might fail to restart with a License exception. To correct the problem, you can delete the last host from the database this way:
cd <mmonit's directory> ./bin/sqlite3 ./db/mmonit.db PRAGMA foreign_keys = ON; DELETE FROM host WHERE id=(SELECT MAX(id) FROM host);
DELETE FROM host ORDER BY id DESC LIMIT 1;
DELETE FROM host WHERE id=(SELECT MAX(id) FROM host);
You should now be able to start M/Monit again.