Monitoring Actions

This chapter covers how to manage monitoring-driven actions with cmsh.

3.1 Actions And Triggers

A monitoring action is a script that is executed by CMDaemon. It runs when triggered by the monitored data.

An action by itself does nothing—it needs a trigger (section 12.4.5 of the Administrator Manual) to be defined to execute the action.

By default, several actions (section 12.4.4 of the Administrator Manual) are predefined:

• Drain: Drain node (node refuses new WLM jobs)

• Event: Send an event to users with connected client

• ImageUpdate: Update the image on the node

• PowerOff: Power off a device

• PowerOn: Power on a device:

• PowerReset: Power reset a device

• Reboot: Reboot a node

• Send e-mail to administrators: Send e-mail

• Shutdown: Shutdown a node

• Undrain: Undrain node (node accepts new WLM jobs)

• killprocess: /cm/local/apps/cmd/scripts/actions/killprocess.pl

• remount: /cm/local/apps/cmd/scripts/actions/remount

• testaction: /cm/local/apps/cmd/scripts/actions/testaction

A new action script can be created as follows:

Example

[basecm10]% monitoring action
[basecm10->monitoring->action]% add script MyScript
[...MyScript*]% set script /path/to/MyScript
[...MyScript*]% commit

3.2 Time Restrictions

It is possible to allow actions to only be executed at certain times, with the allowedtime setting.

Example

[basecm10]% monitoring action
[basecm10->monitoring->action]% add script MyScript
[...MyScript*]% set script /path/to/MyScript
[...MyScript*]% set allowedtime "9:00-17:00"
[...MyScript*]% commit

More complex timing restrictions are possible:

Example

monday-friday{9:00-17:00}
monday-friday{00:00-09:00;17:00-00:00};saturday-sunday
november-march{monday-saturday{13:00-17:00}}
may-september{monday-friday{09:00-18:00};saturday-sunday{13:00-17:00}}

Further examples can be seen in section 12.4.4 of the Administrator Manual, here.

3.2.1 Time Restriction Syntax In EBNF Notation

The allowed values can be written as a not-very-rigorous EBNF grammar:

Example

<start> ::= <time_intervals> | ""
<time_intervals> ::= <time_interval> (";" <time_interval>)*
<time_interval> = <inner_time_interval> "{" <time_intervals> "}"
<inner_time_interval> ::=
  | <day_of_week_interval>
  | <time_of_day_interval>
  | <day_of_month_interval>
  | <month_interval>
<day_of_week_interval> ::=
  | (<day_of_week> "-" <day_of_week>)
  | (<day_of_week> ("," day_of_week)*)
<day_of_week> ::=
  | "sunday" | "monday" | "tuesday" | "wednesday" | "thursday"
  | "friday" | "saturday"
<time_of_day_interval> ::= <time_of_day> "-" <time_of_day>
<time_of_day> ::= { <digit> } <digit> ":" <digit> <digit>
<digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "0"
<month_interval> ::= (<month> "-" <month>) | (<month> ("," <month>)*)
<month> ::=
  | "january" | "february" | "march" | "april" | "may" | "june" | "july"
  | "august" | "september"
  | "october" | "november" | "december"
<day_of_month_interval> ::= (<day_of_month> "-" <day_of_month>)
  | (<day_of_month> ("," <day_of_month>)*)
<day_of_month> ::= { <digit> } <digit>

The shortcomings in the rigor can be fixed, but then the description would be much longer.

For example, the <time_interval> definition should have the time that is specified in the curly brackets be lesser than the one specified by the time outside the curly brackets. So the form

month_interval{day_of_month_interval} (okay)

would be correct, but not:

day_of_month_interval{month_interval} (not okay)

Keeping the description non-rigorous provides a useful enough guide for developers.

3.3 CMDaemon Environment Variables

3.3.1 Standard Environment Variables Available In Action Scripts

All action scripts have the preceding standard environment variables set.

In cmsh, if the action object has its node environment parameter set to the value yes, then scripts running on a node are enabled with an extended environment that provides many more CMD_* environment variables. Otherwise they run in the standard environment. There are more environment variables besides the standard and node environment ones.

A list of the standard or extended environment variables can be dumped by running the system command env > /tmp/dumpfile within an action script, such as the test example script, and triggering the script to run.

Many of the environment variables are similar to the ones used by initialize and finalize scripts (section E.3 of the Administrator Manual) in the node-installer environment.

3.3.2 Extended Environment Variables Available To Action Scripts

If the action object has its node environment parameter set to the value yes, then scripts run in an extended environment that provides many more CMD_* environment variables. Otherwise they run in the standard environment of section 3.3.1.

The following table shows the extended as well as the standard environment variables, with some example values:

3.3.3 Environment Variables Useful For Debugging

The following environmental variables can be handy for debugging:

Examples of their use are given in sections 2.3, 2.4, and 2.13.