← Using Ad Hoc Alert SourcesDefining Escalation Routes →

Monitor Alert Sources

Monitor alert sources raise alerts when a system component reaches a specific severity, like the host running the central Redwood Server is running out of swap space or a queue is held. The system monitor displays a visual representation of the status of all components, all nodes and leaf-nodes can be monitored with monitor alerts. When you monitor a node, all its children are also monitored. You can monitor the entire system, by monitoring the /System/ node, for example.

All criteria must be met for the alert to fire.

Tabs & Fields

The following table illustrates the fields of each tab of Monitor Alert Sources editor dialogs.

TabFieldDescription
Monitor Alert SourcePartitionThe Partition where you wish to store the monitor alert source
Monitor Alert SourceNameThe name of the monitor alert source can contain any combination of US ASCII letters, digits, and underscores; limited to 80 characters.
Monitor Alert SourceApplicationThe Application of the monitor alert source
Monitor Alert SourceDescriptionThe description of the monitor alert source can contain any combination of printable UTF-8 characters, limited to 255 characters.
Monitor Alert SourceRaise an alert for monitorSelect a monitor node.
Monitor Alert SourceRaise alerts only at certain timesTime Window and Time Zone allow you specify that alerts should only be fired when the time window is open or closed, depending on the Time Window Status.
Monitor Alert SourceRaise a custom operator messageSpecify a custom Operator Message Expression and Operator Message Reply Expression. The reply expression can use regular expressions to force the user to select a reply.
Monitor Alert SourceSent toSpecify an Address and a Default Alert Escalation; the alert will be sent to the specified address and escalated, if necessary, using the specified escalation. You may use substitution parameters in the address. If you do not provide a Default Alert Escalation you must specify a dynamic one - see below.
Monitor Alert SourceUse a dynamic escalation pathSpecify an alert escalation using substitution parameters, if no escalation can be found, the default specified above will be used.
DocumentationDocumentationA comment about the object, can be used for documentation purposes.
RulesProcessing OrderThe order in which the rules are processed.
RulesSeveritySeverity that will fire the alert.
RulesRisingWhen checked, this alert will fire only when the severity has risen to the previously specified severity.
RulesDelay AmountThe amount of Delay Units to wait until the alert is sent.
RulesDelay UnitsThe units of time used in the Delay Amount.
RulesOperator Message ExpressionStatus-specific operator message expression, overrides default.
RulesAlert EscalationThe rule-specific escalation, overrides default.
Alert Source EmailBodyThe body of the email to send, see Customizing email messages for information on how you can customize it.
Alert Source ActionsTypeThe type of action, limited to Post Alert on alert sources, they fire after an alert is sent. You must reply to the operator message and delete it if you want to suppress it.
Alert Source ActionsEnabledThis checkbox allows you to enable or disable the action; when unchecked, the action will never fire.
Alert Source ActionsLibraryYou can specify a library here containing methods you would like to use. It is recommended to save your code in libraries so you can use it elsewhere.
Alert Source ActionsAction SubjectThe user under which the code in the action is performed. You must set an action subject if you want to use jcsSession
Alert Source ActionsSourceThe source of your code.
Alert Source ActionsStub SourceThis code shows you where the action will be performed.
Security*This is where you can specify who can access/change/remove the monitor alert source.

Criteria

Monitor alert sources raise alerts or notifications when system components change status.

They match on two criteria:

  • The name of the monitor.
  • The current severity of the monitor and the trend (raising or falling).
  • An escalation

When you do not specify an escalation for a specific rule, then the severity change is ignored.

note

Some monitors have a latency; this may impact the response-time of the alert. If you set a delay amount on swiftly changing monitors, the alert will only fire once the condition has been met for the duration of the delay.

note

When you delete or rename an object which you are watching with a monitor alert source, the monitor of that object will not be deleted immediately and a warning will be logged. The monitor path of the alert source will not be updated; you will have to perform this task.

Operator message and reply expressions

The operator message to use is specified as an expression that allows substitution parameters below. The message can be specified at the alert source level, and overridden per status. If no message is specified at any level, the default message is Acknowledge.

The reply expression works the same way as the reply expression for the System_OperatorMessage process definition. This can be specified at the alert source level, and overridden per status. If no reply expression is specified, the default reply expression is Acknowledge.

  • ${data} - the current severity
  • ${alertSourceType} - Alert Source Type
  • ${alertSourceUniqueId} - Alert Source Unique ID

Escalation

Escalations send operator messages and emails (via Email Alert Gateways). When a specific condition does not have an escalation, no operator message is sent and the condition is ignored.

When nobody has resolved the alert in a timely fashion, you can escalate the alert to another operator. This is done with escalations.

Monitor alert sources use two rules to determine the alert escalation to use:

  • An expression to determine a dynamic escalation name. This expression supports ${variable} substitutions and the Redwood Expression Language syntax for expressions.
  • A default alert escalation
  • Rules

The expression is always evaluated first. If the escalation returned by the expression exists, then it is used. If it does not exist, then the default is used. This allows the escalation path to be dynamic.

Promotion

When you promote monitor alert sources, the watched monitors must exist prior to importing the alert source. This is due to the fact that monitor nodes are not created during the import of an object. For example, if you have a monitor alert source that uses a monitor node belonging to a process server, you will have to import the process server separately before you import the monitor alert source or the import will fail.

Renaming Objects

When you rename objects for which a monitor alert source is watching a monitor node, the path to the monitor node will change independently of the monitor alert source; this means that you will have to update the monitor alert source. For example, if your monitor alert source is watching System.ProcessServer.MSLN_WINS3 and you rename the process server MSLN_WINS3 to MSLN_WINS16, the monitor node will not change to System.ProcessServer.MSLN_WINS16 automatically so you must update the monitor alert source.

Procedure

Creating a Queue Alert Source

  1. To enable monitoring, you will need to create the registry entry below and set the value for the entry:
    /configuration/jcs/monitoring/enabled
  2. Navigate to Configuration > Registry and choose New > Registry by path from the context-menu of configuration.
  3. Choose Save & Close.
  4. Restart the environment.

Example

Prerequisite

  • Active Monitoring is configured and has been tested to work.
  • For email, email is configured and an email alert gateway has been configured for the address to use; both have been tested to work.
tip

If you need to set up active monitoring, see the Active Monitoring JumpStart Guide.

Creating the Monitoring Alert Source for the Queue

  1. To enable monitoring, you will need to create the registry entry below and set the value for the entry:
    /configuration/jcs/monitoring/enabled
  2. Navigate to Configuration > Registry and choose New > Registry by path from the context-menu of configuration.
  3. Choose Save & Close.
  4. Restart the environment.
  5. After the environment has been restarted, in the UI navigate to Monitoring > Monitor Tree and make sure you can navigate to /System/Queue/<queue_name> where <queue_name> is the <partition>.<name> of the queue to be monitored.
  6. Choose the Queue, choose "New Monitor Alert Source" and specify a name on the Rules tab, then add a rule with the below properties.
  7. Choose Save & Close.
Processing Order: 1
Severity: 75
Rising <true> (activate box)
Delay Amount: 0 (Default)
Delay Units: Minutes (Default)
Select an Alert Escalation:  jdoe@example.com

The alert above will be sent to jdoe@example.com which of course does not exist.

Validate the Alert Source is Functional

  1. Navigate to Environment > Queues.
  2. From the context-menu of your queue to be monitored, choose Hold.
  3. Wait 30 seconds and navigate to Monitoring > Monitor Tree, then navigate to your queue: /System/Queue/<queue_name>.
  4. Make sure the Severity field reads 75 for your queue.
  5. Navigate to Monitoring > Operator Messages, you should see an operator message with Title Acknowledge from Sender /System/Queue/<queue_name> Severity rising to or above 75.
    Active Monitoring is working.
  6. Check your email client for an email.
  7. Navigate to Environment > Queues.
  8. From the context-menu of your queue to be monitored, choose Release.

See Also

MonitorAlertSource

← Using Ad Hoc Alert SourcesDefining Escalation Routes →