Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

25.3. Alert Responses

Alert conditions define when an alert is supposed to be triggered. An alert notification defines how that alert notification is communicated. An alert notification can be a way of informing administrators and users of the condition, but it can also be a way of having JBoss ON itself address an issue.
A single alert can have multiple responses, to make managing potential problems easier.
Important
Alert notifications cannot be edited after they are added to an alert definition. To change an alert notification, delete the original notification and create a new one with the desired settings.
Report a bug

25.3.1. Notifying Administrators and Responding to Alerts
Copia collegamento

Every alert is recorded and viewable in the JBoss ON GUI. Alerts have an optional configuration, though, of sending an external notification whenever the alert is issued.
Once an incident occurs, there has to be a way to let a systems administrator know what is going on, so they can respond to an issue. This is done by configuring a notification. Alert notifications fall into two categories: a way of communicating the alert and an action to take in response to an alert.
There are three methods, by default, of communicating that an alert has been fired:
  • Email, to one or multiple addresses
  • SNMP traps
  • Messages to JBoss ON users
There are also a few default methods of having JBoss ON respond to an alert:
  • Running a resource operation (on the alerting resource or any other resource in inventory)
  • Running a resource script (specific type of resource operation)
  • JBoss ON CLI scripts
Note
It is also possible to write custom alert methods, which are implemented as server-side plug-ins. Creating custom plug-ins is described in the JBoss Operations Network Plug-ins Writing Guide.
Alert notifications can be clustered. That just means that the same alert can be broadcast through several different methods at the same time. For example, if a public website goes down, then a company may want notifications to be sent to their head web administrator and to have the web server restarted at the same time.
Note
A single alert can initiate multiple notifications. Alert notifications are run in the order they are listed in the alert definition.
Report a bug

25.3.2. Detailed Discussion: Initiating an Operation
Copia collegamento

A parallel response to an alert is to launch an operation. Resource operations (which, like metrics, are defined in the resource type agent plug-in) are launched, like a notification, in response to a triggered alert. Alert operations can be run on the resource that issued the alert or on any other resource in the inventory, which allows immediate and automatic responses to alert conditions. For instance, a JBoss server may begin performing badly because its JVM is out of memory. The JVM is the resource which issues its alert, but the response by the agent is to restart the JBoss server.
When a certain alert condition occurs, the JBoss ON agent can respond by initiating an operation on a resource. This is part of the alert definition configuration, but it is worth calling out because it is such a useful tool for managing responses to alerts. Whenever an alert is fired, the agent can perform some kind of action, like restarting a server. This can be done either on the resource which issued the alert or on another resource.
Remote operations can be exceedingly useful (and versatile). For example, a JBoss server may begin performing badly because its JVM is out of memory. The JVM is the resource which issues its alert, but the response by the agent is to restart the JBoss server.
Regular operations are either initiated immediately or run on defined schedules for a specific configured resource. Alert operations are even more flexible than regular operations for two reasons:
  • Alert operations are fired responsively to address any alert or event.
  • Alert operations can be initiated on any resource in the JBoss ON inventory, not only the resource which sent the alert. That means that an operation can be run for a different application on the same host server or even on an entirely different server.
The operations performed in response to an alert are the same as the operations which can be scheduled to run on a resource. The operations available for an alert depend on the target resource on which the operation will run — not the resource where the alert is set.
Alert operations senders can be used to run scripts on remote resources. For example, if a resource goes down, a diagnostic script can be run on its parent platform or another resource can be brought online and properly configured to take its place.
Report a bug

25.3.2.1. Using Tokens with Alert Operations
Copia collegamento

Alert operations can use tokens to either send information or supply information about the event. For example, tokens can be used to supply resource information in a command-line script.
Alert operations can accept tokens to fill in certain values automatically. These tokens have the following form: 
<%space.param_name%>
Copy to Clipboard Toggle word wrap
The space gives the JBoss ON configuration area where the value is derived; this will commonly be either alert or resource. The param_name gives the entry value that is being supplied. For example, to point to the URL of the specific fired alert, the token would be <%alert.url%>, while to pull in the resource name, the token would be <%resource.name%>.
JBoss ON has pre-defined token values that relate to the fired alert, the resource which issued the alert, the resource which is the target of the operation, and the operation that was initiated. These are listed in Table 25.2, “Available Alert Operation Tokens”. All of these potential token values are Java properties the belong to the operation's parent JBoss ON server.
The alert operations plug-in resolves the token value itself when the alert operation is processed to find the value. The realized value is sent to the script service, which ultimately plugs the value into the command-line argument or script which referenced the token.
Expand
Table 25.2. Available Alert Operation Tokens
Information about ... Token Description
Fired Alert alert.willBeDisabled Will the alert definition be disabled after firing?
Fired Alert alert.id The id of this particular alert
Fired Alert alert.url Url to the alert details page
Fired Alert alert.name Name from the defining alert definition
Fired Alert alert.priority Priority of this alert
Fired Alert alert.description Description of this alert
Fired Alert alert.firedAt Time the alert fired
Fired Alert alert.conditions A text representation of the conditions that led to this alert
Alerting Resource resource.id ID of the resource
Alerting Resource resource.platformType Type of the platform the resource is on
Alerting Resource resource.platformName Name of the platform the resource is on
Alerting Resource resource.typeName Resource type name
Alerting Resource resource.name Name of the resource
Alerting Resource resource.platformId ID of the platform the resource is on
Alerting Resource resource.parentName Name of the parent resource
Alerting Resource resource.parentId ID of the parent resource
Alerting Resource resource.typeId Resource type id
Target Resource targetResource.parentId ID of the target's parent resource
Target Resource targetResource.platformName Name of the platform the target resource is on
Target Resource targetResource.platformId ID of the platform the target resource is on
Target Resource targetResource.parentName Name of the target's parent resource
Target Resource targetResource.typeId Resource type of the target resource id
Target Resource targetResource.platformType Type of the platform the target resource is on
Target Resource targetResource.name Name of the target resource
Target Resource targetResource.id ID of the target resource
Target Resource targetResource.typeName Resource type name of the target resource
Operation operation.id ID of the operation fired
Operation operation.name Name of the operation fired
Report a bug

25.3.2.2. Setting Alert Operations
Copia collegamento

Note
A single alert can initiate multiple operations. All alert operations, as with all alert notifications, are run in the order they are listed in the alert definition.
The Notifications tab has a Resource Operations method.

Figure 25.5. Senders

Senders
View larger image
Senders
There are two parts to the operation. First is selecting which resource the operation will run on. The resource type determines what operations are available.
The default is the resource that the alert is set for; it is also possible to set it on another specific resource or on the results of a search.

Figure 25.6. Resource Selection

Resource Selection
View larger image
Resource Selection
Important
If you select a relative resource and do not enter a specific resource name, then the operation will run on every resource which matches that resource type in the relative path. If no resource matches, then it is logged into the audit trail and the alert process proceeds.
For a relative resource, the resource name is not required. For a specific resource, it is.
The second half is selecting the operation type. The available operations and their configuration parameters depend on the type of resource selected as the target of the operation.

Figure 25.7. Operation Settings

Operation Settings
View larger image
Operation Settings
Report a bug

25.3.3. Detailed Discussion: Initiating Resource Scripts
Copia collegamento

Scripts, such as shell and bat scripts, can be imported into the JBoss ON inventory and managed as resources (Section 5.4, “Importing New Resources Manually”). These scripts can include start scripts, configuration scripts, or diagnostic scripts.
As described in Section 25.3.2.2, “Setting Alert Operations”, an alert notification can run an operation on a resource (even a different resource than the one which triggered the alert). A specific usage scenario is to run a resource script as an operation.
Note
The script must be uploaded to the resource and added into the JBoss ON inventory before it can be used in an alert operation. This is covered in Section 5.4, “Importing New Resources Manually”.
Running a resource script is the same as running an operation. The resource script is selected as the resource for the operation, and then the start or restart operation for the script is set and, optionally, any command-line arguments to pass to the script.

Figure 25.8. Resource Script Settings

Resource Script Settings
View larger image
Resource Script Settings
Important
If you select a relative resource and do not enter a specific script name in the name filter field, then the operation will run on every script resource that is in the relative path with the command arguments that are given. If no script matches, then it is logged into the audit trail and the alert process proceeds.
For a relative resource, the resource name is not required. For a specific resource, it is. To limit script execution to a single specific script, select the specific resource option and select the precise script from the list.
Report a bug

25.3.4. Detailed Discussion: Launching JBoss ON CLI Scripts from an Alert
Copia collegamento

JBoss ON has its own command-line client that can be used to manage server instances in the same way that the web UI manages servers. Much like running a script resource or launching an operation in response to an alert condition, a server CLI script can be run in response to an alert condition.
Report a bug

25.3.4.1. Notes for Using CLI Script Notifications
Copia collegamento

CLI Scripts Are Content

Unlike resource scripts, CLI scripts are not treated as resources in the inventory. These are tools available to and used by the JBoss ON server itself (not limited or associated with any given resource).

Server CLI scripts must be uploaded to the server as content within a repository before it can be run.

CLI Scripts and the Remote API

The CLI script must use the proper API to perform the operation on the server. JBoss ON has several different API sets, depending on the task being performed. To connect to a server and run a script requires the remoting API, which allows commands to be executed on the server remotely.

Writing CLI scripts is covered more in Writing JBoss ON Command-Line Scripts.

Referencing Alert Objects in a CLI Script

The CLI script can actually reference an alert object for the alert which triggers the script by using a pre-defined alert variable.

The alert variable implicitly identifies the alert definition and specific alert instance which has been fired. This allows you to create a proxy resource definition in the script that could be applied to any resource which uses that alert script. 
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)
Copy to Clipboard Toggle word wrap
The resource ID is pulled from the fired alert, and the script can reference the resource from there.

Limits on CLI Scripts

The resources themselves may impose limits on where a CLI script can be run or what operations it can perform. For example, for security reasons, a CLI script cannot perform a JNDI lookup on a local resource (performing a lookup on the server running the CLI script), but it can perform a remote JNDI lookup. Another common issue is that a JBoss ON server cannot run a restart operation on itself.

Be aware of potential security implications or resource constraints when writing a CLI script to be used as an alert response.
Report a bug

25.3.4.2. Writing Alert-Relevant CLI Scripts
Copia collegamento

Server-side scripts are both powerful and versatile. They can touch almost any server functionality and any resource, group, or other object and run a series of commands. This versatility makes CLI scripts very useful to responding to alerts in proactive ways, but it means that the alert should be planned to notify on specific conditions and the script should be designed to respond to that specific set of circumstances.
In other words, make the alert specific and the CLI script relevant.
This script checks the recent monitoring statistics for a web application and restarts the web server database if there are connection problems: 
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)

var definitionCriteria = new MeasurementDefinitionCriteria()
definitionCriteria.addFilterDisplayName('Sessions created per Minute')
definitionCriteria.addFilterResourceTypeId(myResource.resourceType.id)

var definitions = MeasumentDefinitionManager.findMeasurementDefinitionsByCriteria(definitionCriteria)

if (definitions.empty) {
   throw new java.lang.Exception("Could not get 'Sessions created per Minute' metric on resource "
      + myResource.id)
}

var definition = definitions.get(0)

var startDate = new Date() - 8 * 3600 * 1000 //8 hrs in milliseconds
var endDate = new Date()

var data = MeasurementDataManager.findDataForResource(myResource.id, [ definition.id ], startDate, endDate, 60)

exporter.setTarget('csv', '/the/output/folder/for/my/metrics/' + endDate + '.csv')

exporter.write(data.get(0))

var dataSource = ProxyFactory.getResource(10411)

connectionTest = dataSource.testConnection()

if (connectionTest == null || connectionTest.get('result').booleanValue == false) {
    //ok, this means we had problems connecting to the database
    //let's suppose there's an executable bash script somewhere on the server that
    //the admins use to restart the database
    java.lang.Runtime.getRuntime().exec('/somewhere/on/the/server/restart-database.sh')
}
Copy to Clipboard Toggle word wrap
Commands, options, and variables for the JBoss ON CLI are listed in Writing JBoss ON Command-Line Scripts.
An example alert script is included with the server files in serverInstallDir/alert-scripts/.
Report a bug

25.3.4.3. Configuring a CLI Script Notification
Copia collegamento

  1. Upload the script to a content repository.
    View larger image
    Note
    Create a separate repository for alert CLI scripts.
  2. Search for the resource, and configure the basic alert definition, as in Section 25.1.2, “Basic Procedure for Setting Alerts for a Resource”.
  3. In the Notifications tab for the alert definition, give the notification method a name, and select the CLI Script method from the Alert Senders drop-down menu.
    View larger image
  4. First, select the JBoss ON user as whom to run the script. The default is as the user who is creating the notification.
    View larger image
  5. Select the repository which contains the CLI script. If you are uploading a new script, this is the repository to which the script will be added.
  6. Select the CLI script to use from the drop-down menu, which lists all of the scripts in the specified repository. Alternatively, click the Upload button to browse to a script on the local machine.
  7. Click OK to save the notification. The line in the Notifications tab shows the script, the repository, and the user as whom it will run.
    View larger image
Report a bug

25.3.5. Configuring SNMP for Notifications
Copia collegamento

Configuring JBoss ON to send SNMP alerts has two parts:
  • Configuring the SNMP alert plug-in for the server.
  • Configuring the actual alert with an SNMP notification.
Report a bug

25.3.5.1. JBoss ON SNMP Information
Copia collegamento

JBoss ON can send SNMP traps to other management stations and systems as part of alerting notifications. The data transmitted contain details about the alert, such as the name of the alert that was triggered and the resource name.
The data to include in the traps, as with other SNMP notifications, are defined in the JBoss ON MIB file, in serverRoot/etc/RHQ-mib.txt. The default configuration for the MIB is shown in Example 25.1, “Default Alert Object in JBoss ON MIB”. The base OID for the JBoss ON alert is 1.3.6.1.4.1.18016.2.1 (org.dod.internet.private.enterprise.jboss.rhq.alert).

Example 25.1. Default Alert Object in JBoss ON MIB

--internet(1.3.6.1) 
+--private(4) 
| +--enterprises(1) 
| +--jboss(18016) 
| +--rhq(2) 
| +--alert(1) 
| | +-- r-n DisplayString alertName(1) 
| | +-- r-n DisplayString alertResourceName(2) 
| | +-- r-n DisplayString alertPlatformName(3) 
| | +-- r-n DisplayString alertCondition(4) 
| | +-- r-n DisplayString alertSeverity(5) 
| | +-- r-n DisplayString alertUrl(6) 
| | +-- r-n DisplayString alertHierarchy(7) 
| +--alertNotifications(2) 
| | +--alertNotifPrefix(0) 
| | +--alertNotification(1) [alertName,alertResourceName,alertPlatformName,alertCondition,alertSeverity,alertUrl,alertHierarchy] 
| +--rhqServer(3) 
+--snmpV2(6) 
+--snmpModules(3) 
+--rhqMIB(1) 
+--rhqTraps(3) 
+--rhqTrapPrefix(0)
Copy to Clipboard Toggle word wrap
Note
With the default MIB file, each trap sends the alert definition name, resource name, platform, alert conditions, severity, and a URL to the alert details page. The location of the MIB can be passed to the SNMP trap server to view the translated MIBs. For example, using NetSNMP: 
[root@server ~]# snmptrapd -m RHQ-MIB -M/opt/local/share/mibs/ietf
Copy to Clipboard Toggle word wrap
The -M gives the path to the SNMP server's MIB directory.
In that case, an alert notification is recorded in the trap like this: 
Jul 8 15:13:31 snert snmptrapd[42372]: 127.0.0.1: Enterprise Specific Trap (.0) Uptime: 0:00:00.00, RHQ-MIB::alertName = STRING: test, RHQ-MIB::alertResourceName = STRING: snert, RHQ-MIB::alertPlatformName = STRING: snert, RHQ-MIB::alertCondition = STRING: 
- Condition 1: Free Memory < 1.024,0MB 
- Date/Time: 2013/07/08 15:13:05 MESZ 
- Details: 12,9MB 
, RHQ-MIB::alertSeverity = STRING: medium, RHQ-MIB::alertUrl = STRING: http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/12204, RHQ-MIB::alertHierarchy = STRING: snert
Copy to Clipboard Toggle word wrap
The output is similar in tcpdump, just all on the same line: 
22:06:19.043208 IP localhost.56445 > localhost.snmptrap: Trap(352) E:18016.2.3 0.0.0.0 enterpriseSpecific s=0 0 E:18016.2.1.1="test" E:18016.2.1.2="snert" E:18016.2.1.3="snert" E:18016.2.1.4="^J- Condition 1: Free Memory < 4,0GB^J- Date/Time: 2013/07/10 22:06:01 MESZ^J - Details: 179,2MB^J" E:18016.2.1.5="medium" E:18016.2.1.6="http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/10038" E:18016.2.1.7="snert"
Copy to Clipboard Toggle word wrap
Report a bug

25.3.5.2. Configuring the SNMP Alert Plug-in
Copia collegamento

The SNMP alert sender plug-in is the only alert notification plug-in that requires additional configuration before the notification method can be used. The SNMP plug-in has to be configured with the appropriate SNMP version and SNMP agent information.
  1. In the top menu, select the Administration tab.
  2. In the System Configuration menu, select the ServerPlugins item.
    View larger image
  3. Click the name of the SNMP plug-in in the list.
    View larger image
  4. In the plug-in details page, expand the Plugin Configuration section.
  5. Fill in the required SNMP configuration:
    • Select the appropriate SNMP version.
    • Give the hostname, port number, and transport protocol for the SNMP trap server. The default settings point to the localhost for the JBoss ON server and port 162.
    • Set the trap OID. This is, by default, the RHQ OID.
    • For SNMP 1 and 2. Give the name of the community.
    View larger image
    Note
    This sets global defaults for SNMP alert notifications. Different settings can be given to individual alert notifications when an alert definition is created.
  6. SNMP version 1 and version 3 both require additional configuration, as listed in Table 25.3, “SNMP v1 Configuration Settings” and Table 25.4, “SNMP v3 Configuration Settings”. Expand the version-specific configuration section and fill in the information about the SNMP agent.
    View larger image
    It may be necessary to unselect the Unset checkbox to allow the fields to be edited.
Expand
Table 25.3. SNMP v1 Configuration Settings
Field Description
Generic ID The ID of the trap. The SNMP standards defines numbers from 0-6, with 6 meaning "enterprise specific," which is the default.
Enterprise OID The OID of the JBoss ON server itself. The default value is taken from the RHQ MIB as SMIv2.enterprise.jboss.rhq.rhqServer.
Specific OID A custom OID to use with the trap notification. This can be empty.
Agent address The IP address of the alert sender, which means the IP address of the JBoss ON server.
Expand
Table 25.4. SNMP v3 Configuration Settings
Field Description
Auth protocol The encryption algorithm for authentication requests. Setting this requires a corresponding authentication passphrase to be set. If there is no passphrase, this value must be none.
Privacy protocol Sets the encryption method used with trap messages. This is used with the authentication proocol.
Engine Id
Target Context name
Auth passphrase Sets the password used for authentication; this has a miminum length of eight (8) characters. This is required if an Auth Protocol value is set.
Privacy passphrase Sets the password used for managing encrypted communication. This is required if authentication is used.
Security name Gives the username to use for authentication to the trap receiver.
Report a bug

25.3.5.3. Configuring the SNMP Alert Notification
Copia collegamento

Before JBoss ON can send any SNMP notifications, SNMP traps have to be configured for the server.
When configuring the alert, select the SNMP Trap notification type, and fill in the JBoss ON SNMP information.

Figure 25.9. JBoss ON SNMP Trap Information

JBoss ON SNMP Trap Information
View larger image
JBoss ON SNMP Trap Information
  • The hostname for the SNMP manager. If this is not set, the default from the global configuration is used.
  • The port number for the SNMP manager. If this is not set, the default from the global configuration is used.
  • A variable binding prefix. Optional. This prepends the given string to the beginning of the individual variables sent by the trap. This can be a way to identify the JBoss ON server, resource, or alert which is sending the trap. The default is set in the RHQ MIB, SMIv2.enterprise.jboss.rhq.alert.
  • The trap OID. This is the specific OID to use with the trap definition. If this is not set, the default from the global configuration is used; by default, this is the RHQ-MIB, 1.3.6.1.4.1.18016.2.1.
Report a bug
Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat