This is Part IV in a multi-part series, demonstrating how to take EM12c from out of the box to enterprise level.  

You can read Part I, Part II and Part III to complete the first phases of this setup and look for future posts in this series to ensure your EM12c is set up to support your database world.

Incident Rule Sets

There was a slight mis-communication between development groups when the Incident rules and the metric value settings were configured for the EM12c “out of the box”.  Currently, 90% of metrics are only set with warning thresholds.  The Incident rule sets that are created by default and locked, (non-editable) are set only to notify on “Critical” incidents.  Realize that this is a formula for disaster for most if they rely on the defaults.

We will then first, correct the Incident rules and assign our notification choices, then go onto database templates/metric settings.

To enter the EM12c Incident Rule Sets Interface, click on Setup –> Incident –> Incident Rules.

You will view two system-generated rules sets by default.  They will be locked, (note the padlock icons next to the Rule set name) and although enabled and in use by default, we are going to create copies of these rules and then disable the originals, (retaining as templates for future if ever needed.) and edit our new “Copies”.

To create a copy, first click on the first rule set in the list, “Incident Management Rule set for all targets” and then click on the “Action” drop down menu.

Choose “Create like Rule set” from the list and click on it.

You will then need to name the new Rule Set, (I commonly name the Rule set “<client acronym> Incident Management Rule set” for easy reference.)

Don’t make any other changes and click through to completion and save.

Once you’ve created your copy, you must disable the original or you will have two sets of rules notifying you when issues arise.  To do this, click on the original, system-generated rule set, then click on Actions–> Disable.

The Rule set is now disabled and your new Rule set you created is the new production one  Note that your new rule set no longer has the “padlock” icon next to the nthat is active and notifying.  No changes have been made to it yet, so it notifies for the same and in the same way as the original.ame.  This means that you are able to edit this rule set.  Also note that the original system-generated one is set to “No” in the Enabled column.  Only enabled Rule sets are active.

Create a copy of the Event Management Rule set for Self Update, but you will also edit the notification on the updates.  This is an update that we would like to see the information about available updates published to the OMS, but not alert, as it can be very disruptive to after-hours support and is non-critical.

Once you have removed all user names form the Action Summary for Email and only left the $SOURCE_OBJ_OWNER$ entry, click on Next –>OK and then Save.

Now, we must disable the system generated original rule.  Click on the Original, click on Action–> Disable and then click OK.

Not that the rule now is marked “No” under the enabled column and contains a yellow warning icon beside it to notify you that it is no longer enabled and active.

 

Editing Rule Sets to Achieve Optimal Alerting

Below is a list of the rules in our copy of the main Enterprise Rules.  I have demonstrated the changes in the Action Summary, mostly involving email notifications.  You will note as the default shows emails being sent for most of these, I have removed them by clicking on the individual rule and then clicking on Actions à Edit.  I then remove the names of the notifications for the rules showing below without email notifications.  You should be able to simply compare your list with the one below to decide how much “white noise” you wish to remove from your environment.

 

 

The rule edits above are simply a guideline, but the one I recommend to create the most effective, critical alerts.  You may have to tweak these to receive the alerting and notifications that are important to the business you support.

Next Part V, Managing Warnings through the Incident Manager