Database Reference
In-Depth Information
•
Set the number of occurrences appropriately. If some events occur only once or twice, for
example, you might not need to be notified of them. You can set the number of occurrences of
a metric that must be reached before you are notified.
•
Use corrective actions to autoclear metric alerts. Depending on the metric itself, you may
be able to define a corrective action that will take place automatically to resolve the issue.
This will autoclear the metric alert so you do not need to take action. You might also want to
consider creating a rule that clears events for all metric alerts if the event has been open for a
certain number of days.
•
Disable metric collection for those metrics that you might not care about. Once you have
the history information discussed in the second bullet, you can use that to not only set
metric thresholds but to disable those metrics that may not be important in your particular
environment.
•
Define metric settings in monitoring templates, and use those templates in monitoring
collections. This will allow you to take full advantage of administration groups, lessening the
amount of work involved for you when new targets are added to your environment or when
threshold values need to be adjusted.
Rule Set Recommendations
In terms of recommendations for rule sets, let's start off with some general recommendations. First, as just discussed,
it is strongly recommended to use a group as the target for a rule set. You want to put together all the rules that pertain
to members of that group in the same rule set. Then as much as possible, take advantage of the fact that you can
control the execution order of the rules within the rule set.
When you create a rule in a rule set within EM12c, you'll notice three types of rules. Let's look at specific
recommendations on how you would use these types. For rules that operate on events, the use case is to create
incidents for the alerts or events that are managed in Enterprise Manager. If you want to use a ticketing connector in
Enterprise Manager to create tickets for these incidents, use rules on events to do so, by using the rule actions to first
create an incident on the event and then create a ticket for the incident. Another use case for rules on events would be
to simply send events to third-party management systems using event connectors. The final scenario would be to only
send notifications on events rather than creating incidents, as you could in earlier releases.
For rules that operate on incidents, one of the primary use cases is to automate operations that pertain to
incident workflow (such as automatically assigning owners to incidents), to set priority for an incident or set its
escalation level, or to send notifications for incidents. You can also as another use case create tickets based on
incident conditions, such as creating a ticket when an incident is escalated to level 2.
Rules are used on problems to automate the management of problem workflows in much the same way as for
incidents. For example, you can automatically assign owners to problems, set the priority or escalation level for a
problem, or send notifications for problems.
Incident rule sets can be easily used for automation and workflow management. For example, you might do
the following:
•
Auto-assign incidents for faster resolution. When incidents are created, assign an incident
owner automatically. Alternatively, create a separate rule to assign ownership based on
specific criteria. In either case, this saves having to manually assign the incident to a specific
owner.
•
Automate your escalation processes. You may want to set the escalation level for an incident
based on the length of time the incident has been open and unresolved. If you do not
auto-assign incidents as discussed in the first bullet, you may want to escalate unassigned
important incidents.
