Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

2.3. Anatomy of Alert Sender Server-Side Plug-ins

An alert notification sender is simply the method used to send an alert. Each sender is implemented through an alert sender plug-in. Multiple instances of the same type of plug-in can be configured with different settings; all the plug-in provides is the functionality of sending an alert in that way.
Alert senders are implemented as server-side plug-ins (with the same general configuration concepts as those covered in Section 2.2, “The Breakdown of Server-Side Plug-in Configuration”. The server-side plug-in framework allows the alert sender configuration to be easily extended through custom plug-ins or even by editing the configuration of the default server-side plug-ins.
This section deconstructs the elements of one of the default server-side plug-ins — the email alert sender — to make the process of creating an alert sender clear and simple.

2.3.1. Default Alert Senders

JBoss ON provides multiple alert sender plug-ins with the default installation, which cover some of the most common ways of sending an alert.

Table 2.7. Default Alert Senders

Alert Method Description Plug-in Name
Email Sends emails with the alert information to a user or list of users. alert-email
Roles Sends an internal message to a JBoss ON user role. alert-roles
SNMP Sends a notification to an SNMP trap. alert-snmp
Operations Initiated a JBoss ON-supported task on a target resource. alert-operations
Subject Sends a notification to a user in JBoss ON. alert-subject
Plug-in developers and administrators can create and deploy custom alert sender plug-ins to cover other scenarios or formats that are specific to an organization, such as additional instant messaging systems.

2.3.2. Breakdown of a Real Alert Sender Plug-in

As described in Section 2.2, “The Breakdown of Server-Side Plug-in Configuration”, any server-side plug-in uses three types of files for its configuration:
  • An XML plug-in descriptor that conforms to a given XML schema file (XSD)
  • Java files
The XML plug-in descriptor and the Java files are unique to every plug-in. All of the default alert senders, however, use the same three schema files to provide attributes for the descriptor.
Section 3.4, “Deploying Server-Side Plug-ins” covers the process for building and deploying plug-ins. This section annotates the elements of each of the configuration files used to define a default alert sender (alert-email) as an example of how to write an alert plug-in.

2.3.2.1. Descriptor

Every plug-in descriptor is a file called rhq-serverplugin.xml in the src/main/resources/META-INF/ file for that plug-in.
Note
The default alert schema has to be used with the plug-in descriptor for the alert plug-in validator to work and for the alert to tie into the monitoring system successfully.
The header in the plug-in descriptor pulls in the schema files to use with the plug-in and defines the package information (class, description, version number) for the plug-in. The displayName flag contains the name to give for the plug-in in the list of installed server-side plug-ins.
<alert-plugin
     name="alert-email"
     displayName="Alert:Email"
     xmlns="urn:xmlns:rhq-serverplugin.alert"
     xmlns:c="urn:xmlns:rhq-configuration"
     xmlns:serverplugin="urn:xmlns:rhq-serverplugin"
     package="org.rhq.enterprise.server.plugins.alertEmail"
     description="Alert sender plug-in that sends alert notifications via email"
>
The next section supplies help text for the alert.
<serverplugin:help>
     Used to send notifications to direct email addresses.
</serverplugin:help>
The help text is displayed in a help description section in the UI.

Figure 2.2. Alert Help Text

Alert Help Text
The next section in the descriptor is filler for the alert-email plug-in.
<!-- startup & tear down listener, + scheduled jobs
<serverplugin:plugin-component />
-->
For other types of server-side plug-ins, this area could contain scheduling information in a <scheduled-jobs> element or implement a Java class in a <plugin-component> element. There's no reason to schedule any jobs with an alert sender since the plug-ins do not perform tasks; they provide methods of sending message from the server when an event is detected.
The global preferences define parameters that apply to every single instance of the alert, meaning it applies to every notification which is configured to use that alert sender. These global configuration parameters can be configured in the XML file, but they can also be edited through the JBoss ON GUI, as described in Section 3.8, “Setting Plug-in Configuration Properties”.
For the alert-email plug-in, these parameters include the sender mail address to use for notifications, the mail server, and any login credentials.
<!-- Global preferences for all email alerts -->

<serverplugin:plugin-configuration>
     <c:simple-property name="mailserver" displayName="Mail server address" type="longString"
          description="Address of the mail server to use (if not the default JBoss ON one )"
          required="false"/>
     <c:simple-property name="senderEmail" displayName="Email of sender" type="string"
          description="Email of the account from which alert emails should come from"
          required="false"/>
     <c:simple-property name="needsLogin" displayName="Needs credentials?"
          description="Mark this field if the server needs credentials to send email and give them below" type="boolean"
          default="false"/>
     <c:simple-property name="user" type="string" required="false"/>
     <c:simple-property name="password" type="password" required="false"/>
</serverplugin:plugin-configuration>
If defaults are set, then there is a default value given in the configuration itself. The alert-email plug-in, however, doesn't have defaults set for any of its parameters, so the values for the plug-in configuration have to be added through the plug-in configuration page.
The <short-name> element is required for every alert sender plug-in. This gives the name that is used for the alert sender type in the notification area of the alert definition.
<!-- How does this sender show up in drop downs etc -->

<short-name>Email</short-name>
Since the <short-name> value is used in drop-down menus and other user-oriented areas, this value is much more human-friendly than the displayName value.
The next section gives the plug-in class used to send the alert notification. The component for server-side plug-ins is typically org.rhq.enterprise.server.plugins.pluginName, taken from the package element in the <plugin> element of the descriptor. For the alert-email plug-in, the full package name is org.rhq.enterprise.server.plugins.alertEmail, pointing to the EmailSender.java class.
 <!-- Class that does the actual sending -->

<plugin-class>EmailSender</plugin-class>
The last section in the alert-email descriptor provides the other half to the communication configuration. The global parameters set things that apply to every notification, like the mail server that the JBoss ON server used to send the email notification. The <alert-configuration> entry provides information that is configured individually, for every notification instance which uses that alert sender type. For alert-email, this is a field which allows a list of email addresses that will receive the emailed notifications.
 <!-- What can a user configure when defining an alert -->

<alert-configuration>
     <c:simple-property name="emailAddress" displayName="Receiver Email Address(es)" type="longString"
          description="Email addresses (separated by comma) used for notifications."/>
     </alert-configuration>

2.3.2.2. Java Resource

The first part of the Java file identifies the package name and imports whatever properties are required for that type of sender. For the email sender Java file, this includes configuration to pull in the alert send plug-in container, the notification templates, and other classes to define alerts.
package org.rhq.enterprise.server.plugins.alertEmail;

import java.util.ArrayList;
import java.util.Collection;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

import org.rhq.core.domain.alert.Alert;
import org.rhq.core.domain.alert.notification.SenderResult;
import org.rhq.enterprise.server.plugin.pc.alert.AlertSender;
import org.rhq.enterprise.server.util.LookupUtil;
The rest of the EmailSender.java file pulls data from the notification configuration and the plug-in's global configuration.
The opening sets up the sender.
public class EmailSender extends AlertSender {

    @Override
    public SenderResult send(Alert alert) {
        String emailAddressString = alertParameters.getSimpleValue("emailAddress", null);
        if (emailAddressString == null) {
            return SenderResult.getSimpleFailure("No email address given");
        }
The next lines pull in the email address to receive the notification from the notification configuration and the mail server to send the notification and the sender's email account from the global configuration.
        List<String> emails = AlertSender.unfence(emailAddressString, String.class, ",");
        try {
            Set<String> uniqueEmails = new HashSet<String>(emails);
            Collection<String> badEmails = LookupUtil.getAlertManager()
                .sendAlertNotificationEmails(alert, uniqueEmails);

            List<String> goodEmails = new ArrayList<String>(uniqueEmails);
            goodEmails.removeAll(badEmails);

            SenderResult result = new SenderResult();
            result.setSummary("Target addresses were: " + uniqueEmails);
            if (goodEmails.size() > 0) {
                result.addSuccessMessage("Successfully sent to: " + goodEmails);
            }
            if (badEmails.size() > 0) {
                result.addFailureMessage("Failed to send to: " + badEmails);
            }
            return result;
        } catch (Throwable t) {
            return SenderResult.getSimpleFailure("Error sending email notifications to " + emails + ", cause: "
                + t.getMessage());
        }

    }

    @Override
    public String previewConfiguration() {
        String emailAddressString = alertParameters.getSimpleValue("emailAddress", null);
        if (emailAddressString == null || emailAddressString.trim().length() == 0) {
            return "<empty>";
        }
        return emailAddressString;
    }
}
The last part configures the responses for the email alert plug-in, simple failure or success.
      catch (Exception e) {
         log.warn("Sending of email failed: " + e);
         return SenderResult.getSimpleFailure("Sending failed :" + e.getMessage());

      }
      return SenderResult.getSimpleSuccess("Send notification to " + txt + ", msg-id: " + status.getId());
   }
}

2.3.2.3. Schema Elements

The alert-email plug-in (as all of the default alert sender plug-ins) uses three schema files:
  • rhq-configuration.xsd, which is used by all JBoss ON plug-ins
  • rhq-serverplugin.xsd, which is used by all server-side plug-ins
  • rhq-serverplugin-alert.xsd, which is used by alert plug-ins
The schema in these files build on and expand each other.
The rhq-serverplugin-alert.xsd file is required for any alert sender plug-in. While additional schema files can be added to contain other elements, the alert schema already contains several very useful schema elements for the alert sender plug-ins.

Table 2.8. Useful Alert Schema Elements

Schema Element Description Parent Tag
alert-plugin The root element for a single alert plug-in definition. None.
short-name The display name for the plug-in, which is used in the UI. alert-plugin
plugin-class The class which implements the plug-in's functionality. alert-plugin
alert-configuration A (default) configuration element to display in the UI when the alert instance is configured. This includes general data like a user name, password, URL, server name, or port. alert-plugin