EM12c Enterprise Monitoring, Part II
This is part II of the series on effective monitoring with EM12c.
You can read Part I of this series to ensure you have the complete setup for your Enterprise Manager 12c for effective monitoring and notifications.
Groups and Administration Groups
There are two different features that can be used to assign targets to groupings to ease management.
Groups were introduced early on and Administration Groups is new to EM12c. Although Administration Groups is the newer feature, it is limited to one escalation type, as a target can only belong to one administration group and notification type.
Administration Groups predecessor, “Groups” is able to accept a target being allocated to multiple groups, thus supporting a multiple escalation process for notifications and alerting. Due to this, we will be focusing on Groups and not Administration Groups, but I hope that the Administration Group feature will soon support multiple escalation paths.
Groups
To create a Group, click on Targets –> Groups
Click on Create and click on Group, (note for future reference that this is one location that Administration Groups are available for configuration.)
Choose from the list of targets what ones you want in each of your designated groups. For this client, we’re going to create a production and a non-production group.
Once the group is named, click on “Search” and choose all the targets that fit the criteria for your group.
Previously another production group was created for ASM with all the production ASM targets assigned and so we will also add this to the new production group, designating it as it’s parent. Keep in mind, once you add the ASM-Production group, there is no reason to also add the targets from that group. Once added to the “Parent Group” you will see it assigned when accessing the ASM-Production group.
Breaking large environments down into “sub-groups” with parenting groups can ease management but also adds complexity when targets are automatically discovered. If a sub-group design is chosen, it’s best to break these down by target type and target use, (development, test, staging, production or non-critical/critical, etc.)
Once completed, you can now assign your groups to Incident rule sets as you would individual targets to create more complex notification and alerting scenarios and not have to select individual targets or types.
Pingback: EM12c Enterprise Monitoring, Part II - Oracle - Oracle - Toad World
Pingback: EM12c Enterprise Monitoring, Part II - Oracle - Oracle - Toad World
Pingback: EM12c Enterprise Monitoring, Part II - Oracle - Oracle - Toad World
Pingback: EM12c Enterprise Monitoring, Part III | DBA Kevlar
Pingback: EM12c Enterprise Monitoring, Part I | DBA Kevlar
Pingback: EM12c Enterprise Monitoring, Part III - Oracle - Oracle - Toad World
Pingback: EM12c Enterprise Monitoring, Part IV | DBA Kevlar
Hi Kevlar,
Is the EM12c is solely for the 12c or it can be integrated with earlier Oracle DB versions too like 11gr2/1 etc.
Is the maximum benefits of em12c can be reaped if its been with 12c DB.
Also kindly do provide me with the links to integrate em12c with 11.2.0.1, platform WIN_64BIT, if at all is it plausible to do so.
Thanks
Bharath
Hi,
great blog. I hope to get to OpenWorld next year.
I’m trying to filter out some generic alert log errors – the expression filter string works when using the alerttest.pl script in DOC ID 1567605.1, but when placed in OEM I still get emails.
The strings I’m trying to filter:
“RM cpu_count*” and “Detected change in CPU count to*”
Any help appreciated. I have an SR with Oracle but no solution for a couple of weeks. I’ve also looked at editing the emd.properties file as per 1290548.1, but the emails still come.
Pingback: EM12c Enterprise Monitoring, Part V “Warning Management” | DBA Kevlar
Kellyn, Hi. Do you advocate defining the Hierarchy in OEM 13c?
With the advancement of dynamic groups, I think it’s a management choice. If it makes sense, then use the admin groups with hierarchy, otherwise, simplify and use dynamic groups.