121 |
file (and of course, do not use the -l switch) |
file (and of course, do not use the -l switch) |
122 |
|
|
123 |
|
|
124 |
=head1 LOCKING VIA PIDFILE |
=head1 MONIT LOCK FILE |
125 |
|
|
126 |
monit will write down its own pid number a pid lock file. |
monit utilize a lock file to prevent concurrent runs. That is, |
127 |
Depending on the operating system the default location of |
only one monit process is permitted per user. The lock file |
128 |
this file is whether /var/run/monit.pid or /etc/monit.pid. |
contains the process id (pid) from the current running monit |
129 |
|
process and if monit is run by the root user the location of the |
130 |
|
lock file is either I</var/run/monit.pid> or I</etc/monit.pid> |
131 |
|
depending on the operating system. If monit is run by a non-root |
132 |
|
user the location of the lock file is in the users home |
133 |
|
directory, I<$HOME/.monit.pid>. When a monit process is stopped |
134 |
|
it removes the lock file before it exit. |
135 |
|
|
136 |
In order to change this behavior add the following global |
If you want, you can change the location of the monit lock file |
137 |
set-statement to the control file: (keywords are in capital) |
via this global set-statement in the monitrc control file: |
138 |
|
(keywords are in capital) |
139 |
|
|
140 |
SET PIDFILE {pidfile} |
SET PIDFILE {pidfile} |
141 |
|
|
142 |
|
For instance, I<set pidfile /run/monit.pid> |
143 |
|
|
144 |
|
|
145 |
=head1 DAEMON MODE |
=head1 DAEMON MODE |
146 |
|
|
238 |
|
|
239 |
=head1 MONITORING MODE SELECTION |
=head1 MONITORING MODE SELECTION |
240 |
|
|
241 |
Monit supports three monitoring modes: active, passive and |
Monit supports three monitoring modes per service: active, |
242 |
manual. |
passive and manual. See also the example section below for usage |
243 |
|
of the mode statement. |
244 |
In I<active> mode, monit will monitor the program - in the |
|
245 |
case that the program is not running it will start/restart |
In I<active> mode, monit will monitor a service and in case of |
246 |
it (this is the default behaviour). |
problems monit will act and raise alerts, start, stop or restart |
247 |
|
the service. Active mode is the default mode. |
248 |
In I<passive> mode, monit will only monitor the service. |
|
249 |
Resource related restart and stop options are ignored in |
In I<passive> mode, monit will passively monitor a service and |
250 |
this mode as well and will only send alert. |
specifically B<not> try to fix a problem, but it will still raise |
251 |
|
alerts in case of a problem. |
252 |
For clustered environments there is I<manual> option. If it |
|
253 |
is defined, monit will enter I<active> mode only if the |
For clustered environments there is also a I<manual> mode. In |
254 |
service was started under monit's control, for example by: |
this mode, monit will enter I<active> mode only if a service was |
255 |
|
started under monit's control, for example by: |
256 |
|
|
257 |
monit start sybase |
monit start sybase |
258 |
|
|
260 |
|
|
261 |
monit -g database start (for service group) |
monit -g database start (for service group) |
262 |
|
|
263 |
If the service wasn't started by monit or was stopped for |
If the service wasn't started by monit or was stopped for example |
264 |
example by: |
by: |
265 |
|
|
266 |
monit stop sybase |
monit stop sybase |
267 |
|
|
269 |
|
|
270 |
monit -g database stop (for service group) |
monit -g database stop (for service group) |
271 |
|
|
272 |
it woun't monitor the service at all. It allows to have |
monit will not monitor the service at all. This allows for having |
273 |
service configured in monitrc and start it along with its |
services configured in monitrc and start it with monit only if it |
274 |
process monitor only if it should run. It could be used for |
should run. This could be used for building simple failsafe |
275 |
building simple cluster. You can use for example heartbeat |
clusters. For instance, using the I<heartbeat> system |
276 |
to watch health of nodes and in the case of one machine |
(http://linux-ha.org/) to watch the health of nodes and in the |
277 |
failure start the service on secondary node. |
case of one machine failure start services on a secondary node. |
278 |
|
|
279 |
Appropriate scripts that can call monit to start/stop |
Appropriate scripts that can call monit to start/stop specific |
280 |
specific service are needed on both nodes - typical usage: |
services are needed on both nodes - typical usage: |
281 |
|
|
282 |
FILE DESCRIPTION |
FILE DESCRIPTION |
283 |
----------------------------------- |
----------------------------------- |
286 |
/etc/init.d/monit-node1 execute "monit -g node1 start" |
/etc/init.d/monit-node1 execute "monit -g node1 start" |
287 |
/etc/init.d/monit-node2 execute "monit -g node2 start" |
/etc/init.d/monit-node2 execute "monit -g node2 start" |
288 |
|
|
289 |
so hearbeat can control easy the cluster state and if one |
This way hearbeat can easily control the cluster state and if one |
290 |
node fails, hearbeat starts monit-xxxxx of the failing |
node fails, hearbeat will start monit-xxxxx on the failing node |
291 |
node => monit is instructed to start the services of the |
=> monit is instructed to start the services of the failing node |
292 |
failing node and monitor them... |
and monitor them... |
293 |
|
|
294 |
|
|
295 |
=head1 ALERT MESSAGES |
=head1 ALERT MESSAGES |
296 |
|
|
297 |
monit will send an email alert if: |
monit will raise an email alert if: |
298 |
|
|
299 |
o The program timed out |
o A program timed out |
300 |
o Monit restarted the program |
o A program was restarted |
301 |
o Monit stopped the program |
o A program was stopped |
302 |
o Timestamp test didn't passed |
o A timestamp test didn't pass |
303 |
o Resource statement matches (see also the section RESOURCE |
o A resource statement match (see also the section RESOURCE |
304 |
TESTING below) |
TESTING below) |
305 |
o Checksum error occurred (see also the section MD5 CHECKSUM |
o A checksum error occurred (see also the section MD5 CHECKSUM |
306 |
below) |
below) |
307 |
|
|
308 |
More than one alert statement can be used in a process entry. |
More than one alert statement can be used in a process entry. |
344 |
alert security@bar on { checksum, stop } |
alert security@bar on { checksum, stop } |
345 |
alert manager@bar |
alert manager@bar |
346 |
|
|
347 |
This will send an alert message to foo@bar when a timeout or |
This will send an alert message to foo@bar when a timeout, |
348 |
restart occurs and a message to security@bar if a checksum error |
resource or restart occurs and a message to security@bar if a |
349 |
occurs. And finally, a message to manager@bar whenever any error |
checksum error or stop occurs. And finally, a message to |
350 |
event occurs. |
manager@bar whenever any error event occurs. |
351 |
|
|
352 |
The following alert-statement: |
The following alert-statement: |
353 |
|
|
363 |
alert foo@bar |
alert foo@bar |
364 |
|
|
365 |
which as stated above, will send a message when a timeout, a |
which as stated above, will send a message when a timeout, a |
366 |
restart, checksum, resource, stop or timestamp error occurs. |
restart, checksum, resource, stop or timestamp error occurs. (If |
367 |
(If the post fix variant is used, then note that the parenthesis |
the postfix variant is used, then note that the parenthesis are |
368 |
are I<mandatory>). |
I<mandatory>). |
369 |
|
|
370 |
A restart alert is also sent I<if monit fails to execute> the |
A restart alert is also sent I<if monit fails to execute> a start |
371 |
start or the stop program for an entry. B<It is therefor strongly |
or stop program for an entry. B<It is therefor strongly advised> |
372 |
advised> that at least one alert statement register interest for |
that at least one alert statement register interest for restart |
373 |
restart alerts. |
alerts. |
374 |
|
|
375 |
monit will provide a default mail message layout that is short |
monit will provide a default mail message layout that is short |
376 |
and to the point. Here's an example of a standard alert mail sent |
and to the point. Here's an example of a standard alert mail sent |
504 |
Monit can examine how much system resources a service or the |
Monit can examine how much system resources a service or the |
505 |
system is using. |
system is using. |
506 |
|
|
507 |
Depending on this indicators services can be stopped or restarted |
Depending on this indicator services can be stopped or restarted |
508 |
and alerts can be generated. Thus it is possible to utilize |
and alerts can be generated. Thus it is possible to utilize |
509 |
systems which are idle and to spare system under high load. |
systems which are idle and to spare system under high load. |
510 |
|
|
558 |
start apache' if you want the monit daemon to monitor the service |
start apache' if you want the monit daemon to monitor the service |
559 |
again. |
again. |
560 |
|
|
561 |
To calculate the cycles a counter is raised whenever the |
To calculate the cycles, a counter is raised whenever the |
562 |
expression above is true and it is lowered whenever it is false |
expression above is true and it is lowered whenever it is false |
563 |
(but not below 0). All counters are reseted in case of a |
(but not below 0). All counters are reseted in case of a |
564 |
restart. |
restart. |
578 |
|
|
579 |
=head1 TIMESTAMP TESTING |
=head1 TIMESTAMP TESTING |
580 |
|
|
581 |
Monit can watch timestamp of any file or directory associated |
Monit can watch the timestamp of any file or directory associated |
582 |
with monitored program. |
with a program. |
583 |
|
|
584 |
Full syntax for the timestamp statements is as follows (keywords |
The full syntax for the timestamp statement is as follows |
585 |
are in capital and optional statements in [brackets]): |
(keywords are in capital and optional statements in [brackets]): |
586 |
|
|
587 |
TIMESTAMP object [operator] value [unit] [action] |
TIMESTAMP object [operator] value [unit] [action] |
588 |
|
|
589 |
I<object> is path to the associated file or directory to watch. |
I<object> is a path to the associated file or directory to watch. |
590 |
|
|
591 |
I<operator> is a choice of "<",">","!=","==" in c notation, "GT", |
I<operator> is a choice of "<",">","!=","==" in c notation, "GT", |
592 |
"LT", "EQ", "NE" in shell sh notation and "GREATER", "LESS", |
"LT", "EQ", "NE" in shell sh notation and "GREATER", "LESS", |
593 |
"EQUAL", "NOTEQUAL" in human readable form (if not specified, |
"EQUAL", "NOTEQUAL" in human readable form (if not specified, |
594 |
default is EQUAL). |
default is EQUAL). |
595 |
|
|
596 |
I<value> is time watermark. |
I<value> is a time watermark. |
597 |
|
|
598 |
I<unit> is either "SECOND", "MINUTE", "HOUR" or "DAY" (it is also |
I<unit> is either "SECOND", "MINUTE", "HOUR" or "DAY" (it is also |
599 |
possible to use "SECONDS", "MINUTES", "HOURS", or "DAYS"). |
possible to use "SECONDS", "MINUTES", "HOURS", or "DAYS"). |
611 |
the console, like: 'monit start apache' if you want the monit |
the console, like: 'monit start apache' if you want the monit |
612 |
daemon to monitor the service again. |
daemon to monitor the service again. |
613 |
|
|
614 |
It is useful for example for monitoring processes, that are able |
The timestamp statement is useful for monitoring systems, that |
615 |
to report its task state by changing timestamp of state files |
are able to report it's state by changing the timestamp of |
616 |
such as iPlanet Messaging server stored process. It updates |
certain state files. For instance the I<iPlanet Messaging server |
617 |
timestamp of: |
stored process> system update the timestamp of: |
618 |
|
|
619 |
o stored.ckp |
o stored.ckp |
620 |
o stored.lcu |
o stored.lcu |
621 |
o stored.per |
o stored.per |
622 |
|
|
623 |
whenever it runs appropriate task. If the task failed, it keeps |
whenever it runs tasks and if a task failed, the system keeps the |
624 |
timestamp. |
timestamp. |
625 |
|
|
626 |
To report stored problems you can use following statements: |
To report stored problems you can use following statements: |
627 |
|
|
628 |
timestamp "/ip/msg-foo/config/stored.ckp" > 1 minute then alert |
if timestamp "/ip/msg/config/stored.ckp" > 1 minute then alert |
629 |
timestamp "/ip/msg-foo/config/stored.lcu" > 5 minutes then alert |
if timestamp "/ip/msg/config/stored.lcu" > 5 minutes then alert |
630 |
timestamp "/ip/msg-foo/config/stored.per" > 1 hour then alert |
if timestamp "/ip/msg/config/stored.per" > 1 hour then alert |
631 |
|
|
632 |
or equivalent less verbose form: |
or the equivalent less verbose form: |
633 |
|
|
634 |
timestamp "/ip/msg-foo/config/stored.ckp" > 60 |
timestamp "/ip/msg-foo/config/stored.ckp" > 60 |
635 |
timestamp "/ip/msg-foo/config/stored.lcu" > 300 |
timestamp "/ip/msg-foo/config/stored.lcu" > 300 |
636 |
timestamp "/ip/msg-foo/config/stored.per" > 3600 |
timestamp "/ip/msg-foo/config/stored.per" > 3600 |
637 |
|
|
638 |
As mentioned, you can use it also for monitoring some directory |
As mentioned above, you can also use the timestamp statement for |
639 |
for changes. If files are added or removed to/from directory, its |
monitoring directories for changes. If files are added or removed |
640 |
timestamp is changed: |
to/from a directory, it's timestamp is changed: |
641 |
|
|
642 |
timestamp "/foo/directory" > 1 hour then alert |
if timestamp "/foo/directory" > 1 hour then alert |
643 |
|
|
644 |
or |
or |
645 |
|
|
646 |
timestamp "/foo/secure/directory" < 1 hour then alert |
if timestamp "/foo/secure/directory" < 1 hour then alert |
647 |
|
|
648 |
Next example shows, how to restart some process after 7 days of |
The following example is a neat trick for restarting a process |
649 |
life It is not very "must have" feature, but sometimes it is |
after a certain time. Sometimes this is a necessary workaround |
650 |
needed as workaround mainly for commercial products, until |
for some products, until the vendor fix a problem: |
|
process vendor will fix its problem: |
|
651 |
|
|
652 |
timestamp "/var/run/pidfile.process" > 7 days then restart |
if timestamp "/var/run/crappy_program.pid" > 7 days then restart |
653 |
|
|
654 |
|
|
655 |
=head1 CONNECTION TESTING |
=head1 CONNECTION TESTING |
1170 |
will only monitor and send alerts (resource |
will only monitor and send alerts (resource |
1171 |
related restart and stop options are ignored |
related restart and stop options are ignored |
1172 |
in this mode also). If manual, monit will enter |
in this mode also). If manual, monit will enter |
1173 |
active mode only if service was started under |
active mode only if a service was started under |
1174 |
monit's control otherwise the service isn't |
monit's control otherwise the service isn't |
1175 |
monitored. |
monitored. |
1176 |
cpuusage Must be followed by a compare operator, a |
cpuusage Must be followed by a compare operator, a |