Exporting Raw Data

Raw monitoring data is, by default, purged from the database every week. To save the raw data, export it using the CLI.

The Measurem entDataManager class has a method to find the metric values for a specific resource within a certain time range:

findDataForResource(resourceId,[metricId],startTime,endTime,numberOfRecords) For example, for a resource with the ID 10003 and a metric ID of 10473:

exporter.file = '/export/metrics/metrics.csv' exporter.format = 'csv'

var start = new Date() - 8* 3600 * 1000; var end = new Date()

var data = MeasurementDataManager.findDataForResource(10003,[10473],start,end,60) exporter.write(data.get(0))

Both approaches are equally valid and equally useful, depending on your environment, management processes, and plans. Putting a little effort into planning your alerts — simple and complex — can make your overall management much easier.

11.1.1. What's the Condition?

This is probably the single most important thing to determine. What event do you want to know about? An alert definition can have one condition or multiple conditions, and those conditions can trigger an alert if only one is true or only if all are true. One of the easiest things to do is picture the scenario that needs to be reported and work backward to determine what condition or set of conditions best represents that scenario.

Alerts can be very general ("there was a change") or very specific. General conditions are more informational. Very specific conditions can allow very specific responses — meaning that detailed and useful responses can be automated until an administrator can review and intervene.

There is no limit on the number of alert definitions that can be configured, apart from reasonable performance constraints. It may make sense to have one alert that sends a notification for a simple metric value change, while a series of other alerts look at, say, the change for that metric in relation to a different metric, and then runs a certain JBoss ON CLI script depending on what other factors are involved.

11.1.2. What's the Frequency?

A condition can occur and recur, across multiple monitoring scans. How many times do you need to be informed of the same condition?

There are a lot of factors to consider: what kind of response will be taken, what kind of audit trail you need to keep, how common a condition is likely to be, and how long a condition may exist.

Some factors in the alert definition such as dampening rules and disable/recover alert settings throttle how many notifications are sent.

One thing to remember is that an alert notification is every response that the JBoss ON server takes when an alert is triggered. It can be sending an email, posting a message in the UI, running a CLI script, or initiating an operation.

For common, relatively low-priority alerts, probably a single notification is sufficient, so dampening and disable rules can be set to prevent spamming administrators with emails or flooding the recent alerts portlet.

For infrequent issues, critical failures, or high priority resources, the frequency of the alert notification depends on what actions you need to take. Informational alerts may sent for as along as the condition persists, while an alert with an aggressive response like running a CLI script may only be run once and then disabled to prevent from repeatedly running the same script.

11.1.3. What's the Response to Take?

Responding to an alert has two phases: the immediate response and then long-term mitigation. When an alert for a certain condition or event on your resource is fired, what is the very first thing that should happen? Should there be an email to an administrator? Should the JBoss ON server take some action to manage the resource? JBoss ON supports SNMP traps, so should an SNMP notification be sent to an external auditing/monitoring application?

Like conditions, there is no limit to the number of notifications that can be sent when an alert occurs. Multiple responses may make sense in some cases, where JBoss ON should email an administrator and restart a resource can simultaneously.

Operations and CLI script allow administrators to automate responses, and particularly for business- critical systems, this allows JBoss ON to take an immediate action before an administrator may even be aware there is a problem.

Once an immediate action has been taken (either by JBoss ON or by an administrator), then the administrator can acknowledge the alert, essentially dismissing it. That final step can be an important procedure, a way of stating that an administrator has reviewed the alert, identified what caused it, and

found a solution.

Having a way of reviewing and signing off on events — not just as a JBoss ON task, but in real life — establishes a reliable procedure for handling IT problems and improving overall maintenance strategies. 11.1.4 . How Many Resources Does This Affect?

Alert definitions can be set for an individual resource, for a group of compatible resources, or for an entire resource type.

Being able to apply the same definition to multiple resources is invaluable because of how easy it is to manage complex definitions.