Automatically assigning monitoring templates to databases in cloud control

This sounds like a very 'dry' topic for a blog post but bear with it as this is actually very useful and it's the kind of thing you only discover in cloud control when you've gone about doing this a totally different (and very manual) way.

In older versions of OEM every time a new target was added, to get it to be monitored in the way you wanted using monitoring templates always required a manual step of pushing the templates out which had to be remembered each time (unless you had some clever self built automation to handle that). (and possibly earlier versions though i can't check this now) has an almost 'hidden' feature called administration groups - i say 'hidden' as i didn't notice it for over a year and the (oracle press) book i have on cloud control only hints that this feature will exist and was written long before the feature was really 'in the wild' i think.

Anyway here is a short overview of what they are and how they can be used (well at least what i used them for)

Administration groups are conceptually very similar to dynamic groups, essentially you define some property of the target that then includes it in the group. Here are a quick couple of screen to illustrate that:

Clicking on the targets-> groups link gives the following page - with the not immediately obvious button circled below:

Clicking on this opens a nice screen where it gives an overview of what this functionality is all about

The first stage is the hierarchy definition where you define the logical groups and what criteria makes you a member of that group. I've made use of the line of business property here which is something i populated using emcli (i did an earlier post covering this -

However in the earlier post i was only labelling the host level and not the database level - which for the purposes of what i wanted to do is not enough. To do this easily i wrote a small shell script to identify all the database running on a host and give them the same label that the host itself has

Hopefully I've managed to upload this here so you can easily grab it - it's written for Linux - but it's fairly basic and should be easily portable to other platforms

All the script does is run some sql to generate an input file to emcli, which updates the database 'line of business' property to be the same as the host.

Right - after that slight sidetrack lets get back to the main topic - i now have all of my databases labelled with a line of business of either dev/int/uat or live.

I can use this property to allocate those hosts to different administration groups

see screenshot here from the hierarchy page

You then click calculate members before moving on to the next tab.

Now at this point you have nice groupings defined (and a nice picture) but it's not really anything more than dynamic groups gives you - so whats the point?

Well here is where it gets really useful...

Well before we jump into that the useful bit relies on you having already created a monitoring template - this is purely a defined list of the things you want to check.

This post will get too long if i start talking about creating these just suffice to say i created one with just one check in it - a metric extension checking if there has been a full backup in the last week

something i explained how to do here: and then helpfully exported it and uploaded it for you to use in your system (should you wish)

Anyway i drift off the point yet again.

I have a monitoring template now with just this additional check in and now i want to link this to the administration groups i just created.

This is where it gets useful......

This monitoring template can be combined with other templates (should you so wish) - or it can be used on its own when we create a 'template collection' on the next tab of this screen. Here you can see i created one called 'EGC additional checks' - in this simple case all it contains is the simple 7 day backup check metric template.

OK lets recap. I now have a top level admin group called ADMGRP0 and 4 subgroups - each one relating to one of the different environments in the database/application lifecycle. Along with that i know have a template collection containing an additional check i want applied to all environments..

All i need to do now is associate the template collection with the administration sub group - we do this on the final tab

Now the association is there - anything that is in that group gets that template.

However at this point the template is not pushed out to the servers, this seems to automatically trigger when a new member is added to the group but not on initial creation. There seems to be a scheduled auto push job that should run every 24 hours - but at least in my case that didn't seem to be running correctly.

It can be manually forced though (again this is not obvious). If you navigate to the group home page of each sub group - highlight it in the picture and then click 'go to group homepage' (or find it using the search option). On here there is a sync section - clicking start sync forces the initial push out

So now we have an automatic template pushing system in place, every time a member is added to a group it automatically gets the monitoring we want it to have. If we want to globally change the template we can do it once and push it out again to everything easily. If we want different automatic templates for different groups we've got that too.

One thing that initially worried me is that i thought assigning a template with just this single metric in might remove all the other metrics associated to that object - that's not the case. The new metric is added and nothing is removed (well the information is collected but alerting thresholds are removed as i found out recently - there is a later post on this topic) . You can apply a template with a disabled collection for one of the metrics and this will remove it from all those targets but this is the only way metrics get removed.

So there we go - a simple way to control all of your monitoring using this new feature. Hopefully you read this article before you head too far down a more manual path......


Post a Comment