The key purpose of alerts is to bring your attention to the status of the resources. Alerts are the responsive component of the OpenEdge Management Console that are trigged based on abnormal conditions or when the values fall outside the threshold.

You can configure alerts to actively monitor and manage problems by programmatically triggering follow-up actions based on the threshold violations. With OpenEdge Management, you can customize alerts flexibly as suits your business needs by defining how and when to receive alerts by email or flash them on application page. An alert contains information about which resource is most likely in a problem situation. An alert's severity level, category, and source details can help you decide what course of action to take.

This helps you to use the OpenEdge Management monitoring system and associated tooling such as log files to investigate the cause of the problem and implement a mitigation strategy..

You can perform the following tasks with alerts:

  • Configure alerts using monitoring plans
  • Define actions for alerts
  • View alert information
  • Edit alert properties
  • Specify the conditions or threshold values to trigger an alert
  • Assign severity level to an alert
  • Enable and disable alerts
  • Access alert information from the command line

Severity levels of alerts

The severity of an alert varies based on the specific abnormal condition that triggered it, to indicate the level of problem seriousness. The severity levels are indicative of a problem situation and allow you to determine which alerts are assigned highest severity based on the specific needs of your organization.

You can assign the following severity levels to an alert from the Alert severity drop-down menu located in the Rule definition section of a monitoring plan page:

  • Information
  • Warning
  • Error
  • Severe

Types of alerts

Every alert may not necessarily lead to an action. Consider a scenario in which you configure an alert to notify you when the database crashes. In this case, to start the database automatically, you can create a script to start the database and run it as an action when the database crash alert is triggered.

As such, consider the following types of alerts to help you depending on your need

Internal alerts

OpenEdge Management internal alerts automatically inform you of events that occur internally to OpenEdge Management and for which you cannot set up specific alert definitions.

Consider these scenarios:

  • If the disk space is going down (less than 300MB) OEM throws an internal alert.
  • If the fathom trend database is not up and running, all your trending info is not stored; in such scenario an alert will be throw as an internal alert.

Although OpenEdge Management automatically generates alerts for internal events, the alerts associated with internal situations appear on the Management Console and are processed like asynchronous and polled alerts.

External alerts

External alerts are categorized into asynchronous and threshold alerts.

  • Asynchronous alerts - An asynchronous alert is generated by a resource the moment a specific condition is detected, regardless of the polling interval set for that resource. Many asynchronous alerts identify violations related to mission-critical and time-sensitive activities. Others, such as DB_AgentStartup, function as confirmations of normal, or expected, operational status. Some common mission-critical conditions for which you can define an asynchronous alert include:
    • Database abnormal shutdown
    • OpenEdge Management Trend Database Unavailable
    Other events for which you can define asynchronous alerts are greatly time-dependent. For example, if a running job is not completed in a specified duration, you can be notified by an asynchronous alert. This situation could indicate that there is either a runaway or a hung job. In these types of instances, the firing of an asynchronous alert would inform you immediately of the situation so that you could take appropriate action.
  • Polling alerts - A polling alert is generated when the scheduled evaluation of a monitored resource detects an error or a condition or threshold violation in the resource. Polling alerts generally require threshold values to be defined so that a resource's performance can be tracked in response to these parameters. For example, threshold values can include defining criteria such as a performance level that is lower or higher than a given number or identifying the age of a file being older than a time (i.e., minutes, hours, days, and so on). Threshold values give you the flexibility to refine rule conditions based on the performance values you choose for a resource.