ALERT MESSAGES

ALERT MESSAGES

Monit will raise an email alert in the following situations:


 o A service timed out
 o A service does not exist
 o A service related data access problem
 o A service related program execution problem
 o A service is of invalid object type
 o A program status failed
 o A icmp problem
 o A port connection problem
 o A resource statement match
 o A file checksum problem
 o A file size problem
 o A file/directory timestamp problem
 o A file/directory/filesystem permission problem
 o A file/directory/filesystem uid problem
 o A file/directory/filesystem gid problem
 o An action is done per administrator's request
Monit will send an alert each time a monitored object changed. This involves:


 o Monit started, stopped or reloaded
 o A file checksum changed
 o A file size changed
 o A file content match
 o A file/directory timestamp changed
 o A filesystem mount flags changed
 o A process PID changed
 o A process PPID changed
You use the alert statement to notify Monit that you want alert messages sent to an email address. If you do not specify an alert statement, Monit will not send alert messages.


PS:使用alert statement 去通知monit发送email
There are two forms of alert statement:


 o Global - common for all services
 o Local  - per service
In both cases you can use more than one alert statement. In other words, you can send many different emails to many different addresses.


Recipients in the global and in the local lists are alerted when a service failed, recovered or changed. If the same email address is in the global and in the local list, Monit will only send one alert. Local (per service) defined alert email addresses override global addresses in case of a conflict. Finally, you may choose to only use a global alert list (recommended), a local per service list or both.


It is also possible to disable the global alerts locally for particular service(s) and recipients.


PS：可以使用多个alert statement，可以发送很多不同的emails到不懂得地址
当global 和 local 中都存在一个地址的时候，monit 只发送一个alert
可以为特定的服务或者接受者而禁用global
Setting a global alert statement


If a change occurred on a monitored services, Monit will send an alert to all recipients in the global list who has registered interest for the event type. Here is the syntax for the global alert statement:


SET ALERT mail-address [ [NOT] {events}] [MAIL-FORMAT {mail-format}] [REMINDER number]
Simply using the following in the global section of  monitrc:


 set alert foo@bar
will send a default email to the address foo@bar whenever an event occurred on any service. Such an event may be that a service timed out, a service doesn't exist and so on. If you want to send alert messages to more email addresses, add a set alert 'email' statement for each address.


For explanations of the events, MAIL-FORMAT and REMINDER keywords above, please see below.


You can also use the NOT option ahead of the events list which will reverse the meaning of the list. That is, only send alerts for events not in the list. This can save you some configuration bytes if you are interested in most events except a few.
PS：使用not，也就是非，你懂得！MAIL-FORMAT and REMINDER后面会介绍
Setting a local alert statement


Each service can also have its own recipient list.


ALERT mail-address [ [NOT] {events}] [MAIL-FORMAT {mail-format}] [REMINDER number]
or


NOALERT mail-address


If you only want an alert message sent for certain events and for certain service(s), for example only for timeout events or only if a service died, then postfix the alert-statement with a filter block:


 check process myproc with pidfile /var/run/my.pid
   alert foo@bar only on { timeout, nonexist } 
   ...
(only and on are noise keywords, ignored by Monit. As a side note; Noise keywords are used in the control file grammar to make an entry resemble English and thus make it easier to read (or, so goes the philosophy). The full set of available noise keywords are listed below in the Control File section).


You can also setup to send alerts for all events except some by putting the word not ahead of the list. For example, if you want to receive alerts for all events except Monit instance events, you can write (note that the noise words 'but' and 'on' are optional):


 check system myserver
   alert foo@bar but not on { instance } 
   ...
instead of:


   alert foo@bar on { action
                      checksum
                      connection
                      content
                      data
                      exec
                      fsflags
                      gid
                      icmp
                      invalid
                      nonexist
                      permission
                      pid
                      ppid
                      resource
                      size
                      status
                      timeout
                      timestamp
                      uid
                      uptime }
This will send alerts for all events to foo@bar, except Monit instance events. An instance event BTW, is an event fired whenever the Monit program start or stop.


Event filtering can be used to send an email to different email addresses depending on the events that occurred. For instance:


 alert foo@bar { nonexist, timeout, resource, icmp, connection }
 alert security@bar on { checksum, permission, uid, gid }
 alert manager@bar
This will send an alert message to foo@bar whenever a nonexist, timeout, resource or connection problem occurs and a message to security@bar if a checksum, permission, uid or gid problem occurs. And finally, a message to manager@bar whenever any error event occurs.
PS：可以进行事件的排除


Here is the list of events you can use in a mail-filter: action, checksum, connection, content, data, exec, fsflags, gid, icmp, instance, invalid, nonexist, permission, pid, ppid, resource, size, status, timeout, timestamp, uid, uptime


You can also disable the alerts locally using the NOALERT statement. This is useful if you have lots of services monitored and are using the global alert statement, but don't want to receive alerts for some minor subset of services:


 noalert appadmin@bar
For example, if you stick the noalert statement in a 'check system' entry, you won't receive system related alerts (such as Monit instance started/stopped/reloaded alert, system overloaded alert, etc.) but will receive alerts for all other monitored services.


The following example will alert foo@bar on all events on all services by default, except the service mybar which will send an alert only on timeout. The trick is based on the fact that local definition of the same recipient overrides the global setting (including registered events and mail format):


 set alert foo@bar
 
 check process myfoo with pidfile /var/run/myfoo.pid
   ...
 check process mybar with pidfile /var/run/mybar.pid
   alert foo@bar only on { timeout }
Alert message layout


Monit provides a default mail message layout that is short and to the point. Here's an example of a standard alert mail sent by monit:


 From: monit@tildeslash.com
 Subject: Monit alert -- Does not exist apache 
 To: hauk@tildeslash.com
 Date: Thu, 04 Sep 2003 02:33:03 +0200
 Does not exist Service apache
        Date:   Thu, 04 Sep 2003 02:33:03 +0200
        Action: restart
        Host:   www.tildeslash.com
 Your faithful employee,
 monit
If you want to, you can change the format of this message with the optional mail-format statement. The syntax for this statement is as follows:


 mail-format {
      from: monit@localhost
  reply-to: support@domain.com
   subject: $SERVICE $EVENT at $DATE
   message: Monit $ACTION $SERVICE at $DATE on $HOST: $DESCRIPTION.
            Yours sincerely,
            monit
 }
Where the keyword 
from: is the email address Monit should pretend it is sending from. It does not have to be a real mail address, but it must be a proper formatted mail address, on the form: name@domain. 
The reply-to: keyword can be used to set the reply-to mail header. 
The keyword subject: is for the email subject line. The subject must be on only one line. 
The message: keyword denotes the mail body. 
If used, this keyword should always be the last in a mail-format statement. The mail body can be as long as you want, but must not contain the '}' character.


All of these format keywords are optional, but if used, you must provide at least one. Thus if you only want to change the from address Monit is using you can do:


 set alert foo@bar with mail-format { from: bofh@bar.baz }
From the previous example you will notice that some special $XXX variables were used. If used, they will be substituted and expanded into the text with these values:


$EVENT
 A string describing the event that occurred. The values are
 fixed and are:
 Event:    | Failure state:           | Success state:              
 -------------------------------------------------------------------
 ACTION    | "Action done"            | "Action done"               
 CHECKSUM  | "Checksum failed"        | "Checksum succeeded"        
 CONNECTION| "Connection failed"      | "Connection succeeded"      
 CONTENT   | "Content failed",        | "Content succeeded"
 DATA      | "Data access error"      | "Data access succeeded"     
 EXEC      | "Execution failed"       | "Execution succeeded"       
 FSFLAG    | "Filesystem flags failed"| "Filesystem flags succeeded"
 GID       | "GID failed"             | "GID succeeded"             
 ICMP      | "ICMP failed"            | "ICMP succeeded"            
 INSTANCE  | "Monit instance changed" | "Monit instance changed not"
 INVALID   | "Invalid type"           | "Type succeeded"            
 NONEXIST  | "Does not exist"         | "Exists"                    
 PERMISSION| "Permission failed"      | "Permission succeeded"      
 PID       | "PID failed"             | "PID succeeded"
 PPID      | "PPID failed"            | "PPID succeeded"
 RESOURCE  | "Resource limit matched" | "Resource limit succeeded"  
 SIZE      | "Size failed"            | "Size succeeded"            
 STATUS    | "Status failed"          | "Status succeeded"            
 TIMEOUT   | "Timeout"                | "Timeout recovery"          
 TIMESTAMP | "Timestamp failed"       | "Timestamp succeeded"       
 UID       | "UID failed"             | "UID succeeded"             
 UPTIME    | "Uptime failed"          | "Uptime succeeded"
$SERVICE
 The service entry name in monitrc
$DATE
 The current time and date (RFC 822 date style).
$HOST
 The name of the host Monit is running on
$ACTION
 The name of the action which was done. Action names are fixed
 and are:
 Action:  | Name:
 --------------------
 ALERT    | "alert"
 EXEC     | "exec"
 RESTART  | "restart"
 START    | "start"
 STOP     | "stop"
 UNMONITOR| "unmonitor"
$DESCRIPTION
 The description of the error condition
Setting a global mail format


It is possible to set a standard mail format with the following global set-statement (keywords are in capital):


SET MAIL-FORMAT {mail-format}
Format set with this statement will apply to every alert statement that does not have its own specified mail-format. This statement is most useful for setting a default from address for messages sent by monit, like so:


 set mail-format { from: monit@foo.bar.no }


PS：上面两个部分讲解mail-format，可以不看
Setting an error reminder


Monit by default sends just one error notification if a service failed and another when it recovered. If you want to be notified more then once if a service remains in a failed state, you can use the reminder option to the alert statement (keywords are in capital):


ALERT ... [WITH] REMINDER [ON] number [CYCLES]
For example if you want to be notified each tenth cycle if a service remains in a failed state, you can use:


  alert foo@bar with reminder on 10 cycles
Likewise if you want to be notified on each failed cycle, you can use:


  alert foo@bar with reminder on 1 cycle


PS：也就是查看service的状态，如果10个sycles以后还没有恢复，则进行notified。
Setting a mail server for alert messages


The mail server Monit should use to send alert messages is defined with a global set statement (keywords are in capital and optional statements in [brackets]):


 SET MAILSERVER {hostname|ip-address [PORT port]
                [USERNAME username] [PASSWORD password]
                [using SSLV2|SSLV3|TLSV1] [CERTMD5 checksum]}+ 
                [with TIMEOUT X SECONDS]
                [using HOSTNAME hostname]
The port statement allows one to use SMTP servers other then those listening on port 25. If omitted, port 25 is used unless ssl or tls is used, in which case port 465 is used by default.
如果缺省，默认使用25端口，如果使用ssl或者tls，默认使用465端口




Monit supports AUTH PLAIN and AUTH LOGIN for SMTP authentication. You can set a username and a password using the USERNAME and PASSWORD options.
支持使用username和password


To use secure communication, use the SSLV2, SSLV3 or TLSV1 options, you can also specify the server certificate checksum using CERTMD5 option.
使用安全交流，可以使用ssl协议和MD5


As you can see, it is possible to set several SMTP servers. If Monit cannot connect to the first server in the list it will try the second server and so on. Monit has a default 5 seconds connection timeout and if the SMTP server is slow, Monit could timeout when connecting or reading from the server. If this is the case, you can use the optional timeout statement to explicit set the timeout to a higher value if needed. Here is an example for setting several mail servers:
可以set多个SMTP服务器 ，轮询多个server，可以设置timeout的时间
 set mailserver mail.tildeslash.com, mail.foo.bar port 10025
     username "Rabbi" password "Loew" using tlsv1, localhost
     with timeout 15 seconds


Here Monit will first try to connect to the server "mail.tildeslash.com", if this server is down Monit will try "mail.foo.bar" on port 10025 using the given credentials via tls and finally "localhost". We also set an explicit connect and read timeout; If Monit cannot connect to the first SMTP server in the list within 15 seconds it will try the next server and so on. The set mailserver .. statement is optional and if not defined Monit will not send email alerts. Not setting a mail server is recommended only if alert notification is delegated to M/Monit.
如果不defined，Monit不会发送email alerts 。


Monit, by default, use the local host name in SMTP HELO/EHLO and in the Message-ID header. Some mail servers check this information against DNS for spam protection and can reject the email if the DNS and the hostname used in the transaction does not match. If this is the case, you can override the default local host name by using the HOSTNAME option:


 set mailserver mail.tildeslash.com using hostname
     "myhost.example.org"
可以通过邮件的HELO/EHLO进行过滤
Event queue


If the MTA (mail server) for sending alerts is not available, Monit can queue events on the local file-system until the MTA recover. Monit will then post queued events in order with their original timestamp so the events are not lost. This feature is most useful if Monit is used together with M/Monit and when event history is important.
PS:如果mail server不能发送alerts，Monit能够保存events，在本地的文件系统上。
这个很重要，如果monit与M/Monit一起使用
The event queue is persistent across Monit restarts and provided that the back-end filesystem is persistent too, across system restart as well.
不论Monit还是filesystem重启，event queue都会一直存在
By default, the queue is disabled and if the alert handler fails, Monit will simply drop the alert message. To enable the event queue, add the following statement to the Monit control file:
默认情况下，queue是disalbed，要able，需要添加以下
 SET EVENTQUEUE BASEDIR <path> [SLOTS <number>]
The <path> is the path to the directory where events will be stored. Optionally if you want to limit the queue size, use the slots option to only store up to number event messages. If the slots option is not used, Monit will store as many events as the backend filesystem allows.


Example:


  set eventqueue
      basedir /var/monit
      slots 5000
Events are stored in a binary format, with one file per event. The file size is ca. 130 bytes or a bit more (depending on the message length). The file name is composed of the unix timestamp, underscore and the service name, for example:


 /var/monit/1131269471_apache
If you are running more then one Monit instance on the same machine, you must use separated event queue directories to avoid sending wrong alerts to the wrong addresses.


If you want to purge the queue by hand, that is, remove queued event-files, Monit should be stopped before the removal.
先stop monit 然后再进行手动清除queue的操作

原文来自：http://mmonit.com/monit/documentation/monit.html