Enterprise Manager Cloud Control 12c provides us with means to take total control of our Security, Monitoring and Incident Management models. Using Administration and Dynamic Groups, Roles and Administrator controlled ‘Solution Groups’ we are able to route Incidents based on our organization structure.
Therefor we are more and more relying on Target Properties like: Lifecycle Phase, Line Of Business, Department etc. When monitoring thousands of Targets, management of these Properties is a huge challenge.
Take the following example where we are using an Administration Group hierarchy based on Lifecycle phase and Line of Business:
When using an Administration Group you can fully automate the application of Monitoring Templates. This application is based on the association of Template Collections to Administration Group leafs.
A Template Collection includes all Monitoring Templates you want to be applied to all Targets that are in or underneath an Administration Group leaf. Allowing you to apply different monitoring settings to Targets in different Lifecycle Phases and/or different Lines of Businesses.
EM12c made great progress when it comes to the ability to get and stay in control of your monitoring settings. The whole concept of Administration Groups really proofs to work!
Apart from the usage of Target Properties to support your monitoring setup by means of Administration Groups, the same Properties can be included in overview pages as well will it support you in the creation of Dynamic Groups. Dynamic Groups are the way to go when setting up your Incident Management and Security model.
As you can see Target Properties are the main core of your Security, Monitoring and Incident Management setup.
Having said this, we are faced with a big challenge to manage these Target Properties. EM12c allows for setting the Target Properties by means of the Console (like during Target discovery, and as part of Deployment Procedures) and by using emcli.
As there is a risk of typos, incorrect values, and loosing of Target Properties (for instance if because of issues an Agent should get re-installed), there is a need for a “Single point of truth” to check our Target Property values.
Figure 1 OMS interfacing with TP CMDB
In this figure the OMS interfaces with the TP CMDB.
The TP CMDB would typically include a schema including tables as in next example:
Table ‘Targets’ would include a definition of each of your targets as table ‘Target Properties’ would include all properties like ‘Lifecycle phase’, ‘Line of Business’, ‘Department’, ‘Cost Center’ etc. and its values.
Interface functionality
We would like to interface to support the following features:
Check on proper values for Target Properties
Check if the Target Properties in the OMS (repository) are set to a proper value. The value for the property in the repository should be the same as the value in the CMDB.
Synchronize OMS Target Properties with CMDB
Refresh the Target Property contents in the repository with the Target Property contents from the CMDB. By this making sure all Target Properties have set proper values.
Implementation decisions to be made
- Is the CMDB going to reside in the OMR (repository database)?
If so, realize this will have licensing consequences - If the CMDB is going to reside in a different database we see two options:
- Usage of a Database Link (might have License consequences)
- Usage of emcli
- We could use a Metric Extension to implement the ‘Check on proper values for Target Properties’
- Are we going to use an ‘Automatic’ or ‘Manual’ synchronization from CMDB to Repository?
Some thoughts on an ‘ideal’ situation
- Shouldn’t the TP CMDB be the same as your corporate CMDB?
I think yes, but this might introduce several other dilemmas like; naming conventions (are target names in your repository the same as the Configuration Items in your CMDB?) etc. - If you decide to use your corporate CMDB as your TP CMDB, will you be able to make any adjustments when necessary (in time)?
- Wouldn’t it be great if Oracle would provide us with a solution?