Alarm System: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4">
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4">
* [[/Alarms ODB tree]]
* [[/Alarms ODB tree]]
* [[Midas_documentation|Midas Documentation]]
* [[Feature_listing|Feature Listing]]
* [[Feature_listing|Feature Listing]]
* [[Application_listing|Application Listing]]
* [[Application_listing|Application Listing]]
Line 7: Line 8:




= Links =
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[/Alarms ODB tree]]
* [[Alarms Page]]
* [[Mhttpd|mhttpd MIDAS web server]]
</div>


MIDAS provides an alarm system, which by default is turned off. When the alarm system is activated and an alarm condition is detected, alarms messages are sent by the system which appear as an alarm banner on the mhttpd main status page, and as a message on any windows running odbedit clients. The alarm system is flexible and can be extensively customized for each experiment
= Introduction =
using [[odbedit]] or the [[mhttpd]] Alarm page. Some of the features (such as colour) are applicable only to mhttpd.
MIDAS provides an alarm system, which by default is turned off. When the alarm system is activated and an alarm condition is detected, alarms messages are sent by the system which appear as an alarm banner on the mhttpd main status page, and as a message on any windows running [[odbedit]] clients. The alarm system is flexible and can be extensively customized for each experiment
using [[odbedit]] or the [[Alarm Page|mhttpd Alarm Page]]. Some of the features (such as colour) are applicable only to the [[Alarm Page]].


The alarm system is built-in and part of the main experiment scheduler. This means no separate task is necessary to benefit from the alarm system. Its setup and activation is done through the '''[[/Alarms ODB tree]]'''. The alarm system includes several other features such as sequencing and control of the experiment. The alarm capabilities are:
The alarm system is built-in and part of the main experiment scheduler. This means no separate task is necessary to benefit from the alarm system. Its setup and activation is done through the '''[[/Alarms ODB tree]]'''. The alarm system includes several other features such as sequencing and control of the experiment. The alarm capabilities are:
Line 22: Line 30:




== Implementation of the MIDAS Alarm System ==
= Implementation of the MIDAS Alarm System =


Alarms are checked inside alarm.c::al_check(). This function is called by cm_yield() every 10 seconds and by rpc_server_thread(), also every 10 seconds. For remote MIDAS clients, their al_check() issues an RPC_AL_CHECK RPC call into the MIDAS server utility mserver, where rpc_server_dispatch() calls the local al_check(). As result, all alarm checks run inside a process directly attached to the local MIDAS shared memory (inside a local client or inside an mserver process for a remote client). Each and every MIDAS client runs the alarm checks. To prevent race conditions between different MIDAS clients, access to al_check() is serialized using the ALARM semaphore. Inside al_check(), alarms are triggered using al_trigger_alarm(), which in turn calls al_trigger_class(). Inside al_trigger_class(), the alarm is recorded into an elog or into [[Message System|midas.log]] using cm_msg(MTALK).
The alarm system source code is [http://ladd00.triumf.ca/~daqweb/doc/midas/doc/html/alarm_8c_source.html alarm.c].
Alarms are checked inside [http://ladd00.triumf.ca/~daqweb/doc/midas/doc/html/group__alfunctioncode.html#gaf31864a8bc5fe779057e81bde12167a9 alarm.c::al_check()]. This function is called by cm_yield() every 10 seconds and by rpc_server_thread(), also every 10 seconds. For remote MIDAS clients, their al_check() issues an RPC_AL_CHECK RPC call into the MIDAS server utility [[mserver]], where rpc_server_dispatch() calls the local al_check(). As result, all alarm checks run inside a process directly attached to the local MIDAS shared memory (inside a local client or inside an mserver process for a remote client). Each and every MIDAS client runs the alarm checks. To prevent race conditions between different MIDAS clients, access to al_check() is serialized using the ALARM semaphore. Inside al_check(), alarms are triggered using  
[http://ladd00.triumf.ca/~daqweb/doc/midas/doc/html/group__alfunctioncode.html#gac024cd8160dc8b9418f05a63678f6c68&nbsp al_trigger_alarm()], which in turn calls al_trigger_class(). Inside al_trigger_class(), the alarm is recorded into an elog or into [[Message System|midas.log]] using cm_msg(MTALK).


Special note should be made of the ODB setting [[/Alarms ODB tree#System message interval|system message interval]]", which has a surprising effect - after an alarm is recorded into system messages (using cm_msg(MTALK)), no record is made of any subsequent alarms until the time interval set by this variable elapses. With default value of 60 seconds, after one alarm, no more alarms are recorded for 60 seconds. Also, because all the alarms are checked at the same time, '''only the first''' triggered alarm will be recorded.
Special note should be made of the ODB setting [[/Alarms ODB tree#System message interval|system message interval]], which has a surprising effect - after an alarm is recorded into system messages (using cm_msg(MTALK)), no record is made of any subsequent alarms until the time interval set by this variable elapses. With default value of 60 seconds, after one alarm, no more alarms are recorded for 60 seconds. Also, because all the alarms are checked at the same time, '''only the first''' triggered alarm will be recorded.


As of alarm.c rev 4683, "System message interval" is set to 0 ensures that every alarm is recorded into the MIDAS log file. (In previous revisions, this setting may still miss some alarms).
As of alarm.c rev 4683, "System message interval" is set to 0 ensures that every alarm is recorded into the MIDAS log file. (In previous revisions, this setting may still miss some alarms).


There are 3 types of alarms:
There are 3 main types of alarms:


1) "program not running" alarms.
1) "program not running" alarms.
Line 38: Line 48:
If the program has not been running for longer than the time set in ODB key /Programs/ppp/Check interval, an alarm is triggered (if enabled by /Programs/ppp/Alarm class and the program is restarted (if enabled by /Programs/ppp/Auto restart).
If the program has not been running for longer than the time set in ODB key /Programs/ppp/Check interval, an alarm is triggered (if enabled by /Programs/ppp/Alarm class and the program is restarted (if enabled by /Programs/ppp/Auto restart).


The "not running" condition is tested every 10 seconds (each time al_check() is called), but the frequency of "program not running" alarms can be reduced by increasing the value of /Alarms/Alarms/ppp/Check interval (default value 60 seconds). This can be useful if System message interval is set to zero.
The "not running" condition is tested every 10 seconds (each time al_check() is called), but the frequency of "program not running" alarms can be reduced by increasing the value of  
[[ /Alarms ODB tree#Check interval|Check interval]] (default value 60 seconds). This can be useful if System message interval is set to zero.


2) "evaluated" alarms
2) "evaluated" alarms
Line 44: Line 55:
3) "periodic" alarms
3) "periodic" alarms


There is nothing surprising in these alarms. Each alarm is checked with a time period set by /Alarm/xxx/Check interval. The value of an evaluated alarm is computed using al_evaluate_condition().
There is nothing surprising in these alarms. Each alarm is checked with a time period set by ODB key [[ /Alarms ODB tree#Check interval|Check interval]]. The value of an evaluated alarm is computed using al_evaluate_condition().
 
= Setting up the Alarm system =
See the [[/Alarms ODB tree]] for details and [[/Alarms ODB tree#Examples|Examples]]. See also 
[[/Alarms ODB tree#/Alarms tree structure|Alarms tree structure]].

Revision as of 17:46, 11 August 2014


Links

Introduction

MIDAS provides an alarm system, which by default is turned off. When the alarm system is activated and an alarm condition is detected, alarms messages are sent by the system which appear as an alarm banner on the mhttpd main status page, and as a message on any windows running odbedit clients. The alarm system is flexible and can be extensively customized for each experiment using odbedit or the mhttpd Alarm Page. Some of the features (such as colour) are applicable only to the Alarm Page.

The alarm system is built-in and part of the main experiment scheduler. This means no separate task is necessary to benefit from the alarm system. Its setup and activation is done through the /Alarms ODB tree. The alarm system includes several other features such as sequencing and control of the experiment. The alarm capabilities are:

  • Alarm setting on any ODB variable against a threshold parameter.
  • Alarm triggered by evaluated condition
  • Selection of Alarm check frequency
  • Selection of Alarm trigger frequency
  • Customization alarm scheme; under this scheme multiple choices of alarm type can be selected
  • Selection of alarm message destination (to system message log or to elog)
  • email or SMS alerts can be sent
  • Program control on run transition


Implementation of the MIDAS Alarm System

The alarm system source code is alarm.c. Alarms are checked inside alarm.c::al_check(). This function is called by cm_yield() every 10 seconds and by rpc_server_thread(), also every 10 seconds. For remote MIDAS clients, their al_check() issues an RPC_AL_CHECK RPC call into the MIDAS server utility mserver, where rpc_server_dispatch() calls the local al_check(). As result, all alarm checks run inside a process directly attached to the local MIDAS shared memory (inside a local client or inside an mserver process for a remote client). Each and every MIDAS client runs the alarm checks. To prevent race conditions between different MIDAS clients, access to al_check() is serialized using the ALARM semaphore. Inside al_check(), alarms are triggered using al_trigger_alarm(), which in turn calls al_trigger_class(). Inside al_trigger_class(), the alarm is recorded into an elog or into midas.log using cm_msg(MTALK).

Special note should be made of the ODB setting system message interval, which has a surprising effect - after an alarm is recorded into system messages (using cm_msg(MTALK)), no record is made of any subsequent alarms until the time interval set by this variable elapses. With default value of 60 seconds, after one alarm, no more alarms are recorded for 60 seconds. Also, because all the alarms are checked at the same time, only the first triggered alarm will be recorded.

As of alarm.c rev 4683, "System message interval" is set to 0 ensures that every alarm is recorded into the MIDAS log file. (In previous revisions, this setting may still miss some alarms).

There are 3 main types of alarms:

1) "program not running" alarms.

These alarms are enabled in ODB by setting /Programs/ppp/Alarm class. Each time al_check() runs, every program listed in /Programs is tested using "cm_exist()" and if the program is not running, the time of first failure is remembered in /Programs/ppp/First failed.

If the program has not been running for longer than the time set in ODB key /Programs/ppp/Check interval, an alarm is triggered (if enabled by /Programs/ppp/Alarm class and the program is restarted (if enabled by /Programs/ppp/Auto restart).

The "not running" condition is tested every 10 seconds (each time al_check() is called), but the frequency of "program not running" alarms can be reduced by increasing the value of Check interval (default value 60 seconds). This can be useful if System message interval is set to zero.

2) "evaluated" alarms

3) "periodic" alarms

There is nothing surprising in these alarms. Each alarm is checked with a time period set by ODB key Check interval. The value of an evaluated alarm is computed using al_evaluate_condition().

Setting up the Alarm system

See the /Alarms ODB tree for details and Examples. See also Alarms tree structure.