NetIQ Operations Center – SCM – Dynamic/Fixed feature (pre-subscribe to future elements)

Tobin Isenberg

By: Tobin Isenberg

November 26, 2013 4:35 pm

Reads: 259

Comments:0

Rating:0

Most customers leverage the Service Configuration Manager to automatically build and maintain views.  The basic concept is that Service Configuration Manager uses one or more trees in an adapter to build the skeleton of a view such as Services, Customers, Technologies.   The adapters typically connect to a Management Tool, Asset database, CMDB or some other home grow database that has a list of items and how they relate to each other.   Service Configuration Manager (SCM) then correlates current health and availability metrics from other adapters.   By default, SCM does a static (hard coded, specific) link between the element in the view and the element under the adapter.   While this is quick and useful, there are times that the element does not currently exist on the adapter.   If you continue to use SCM with the defaults, you must run SCM over and over again on a routine basis in order to relate a future element on an adapter to the view.   Let me expand on this further.

There are some management tools that I typically describe as “no news is good news”.   What I mean by that is, if there is no violation (alarm) on the underlying device, there is no alarm in the management tool.   Since there is no alarm, there will be no element representing the device.   This is very common for event management tools such as Netcool and Tivolie T/EC.  Typically adapters that have a HierarchyFile adapter property work in this manner.  It is not a limitation of the adapter, it is how the underlying tool works.  Some adapters allow you to create a “seedfile” which pre-creates elements, but at times this may not be an option for you.

While running SCM on a routine basis is fine, if at some point there is a CPU violation, disk space, etc, then in turn an alarm shows up in the management tool and then in turn the alarm shows up in the adapter and creates an element… unless SCM runs seconds after that happens, your view(s) will not be up to date.

One option to alleviate the lag between an element just showing up on an adapter and updating the SCM generated view is to set up expression based matching in the view, for instance, look for a server the is named the same (or close to) the name of the element in the view under a specific branch of the adapter.   As I have said in other blogs, expression based matches are fine, but having thousands of matches can cause longer start up times as well as strain on the processor on the NOC server in general.   Remember, I am talking about thousands and thousands or regex type matches, so this may be fine on your system.

The other option is to leverage the Dynamic/Fixed option which allows you to stamp the elements in the view with a specific dname regardless if the element exists on the adapter at that moment in time or not.

Things to consider:

  • Since you are building a static dname on the fly, the element name in the view SCM created and the adapter must match (IE: case sensitivity).
  • The SCM job requires multiple definitions contained within it in order to leverage Dynamic/Fixed for multiple adapters (IE: pre setup static matches between an element and Netcool, Event Manager and a Help desk system.
  • if you do not use the “match” rule for the structure, you will accidentally do static matches for every element in the view
  • One element can have a dynamic/fixed static relationship to multiple sources (IE:Netcool and Remedy or even multiple branches in the same adapter).
  • You must know the exact name and location that the element will eventually be created.
  • For each adapter and match location, you will need to set up an additional definition in the SCM job.

Here is an overview on how to setup Service Configuration Manager to leverage the presubscribed static match option.  Let’s assume you have one adapter that is the basis (skeleton) of the main view and you have two or more adapters (IE: Netcool, Remedy) that do not always show elements unless there is a corresponding alarm/ticket.

Leveraging the feature:

The first part (definition) of the SCM job has the structure pointing at the adapter that contains the skeleton of the view.   We will assume that you have other adapters that are pre-built out with all of the underlying devices (IE: AppManager, Openview, Spectrum, etc).   Add all of these adapters like you normally would as sources for the first definition.

Now for each other adapter (typically event based adapter… they have a hierarchy file adapter setting), you must add one additional definition.   The structure points at the existing view that SCM just created.   Set up a match rule on the structure so it only retrieves elements that require the static match presetup such as “servers”, “switches”, etc.

For the source, point it at one adapter.    You will point at a view where the element may eventually show up.  For instance, on Netcool, there is a “Nodes” folder.  When an alarm is received on the adapter, it will create one element based on the name of the Node.   The interesting part is that the “join” rule for the source is completely ignored when you set up the next setting.

Under Matching Policies, Correlation there are two setting options, for the first one select Dynamic, for the second one, choose Fixed.   The last thing to do is to type in the details to do the final mapping.   Remember in a previous step you pointed the source (ie: netcool) to a location on the adapter where the element will eventually show up (IE: Nodes folder), consider this the last part of the dname.   In the box below the Dynamic/Fixed settings, you need to build out the rest of the dname (the first part of the dname).   SCM will take what ever you type in and combine it with where the adapter is pointing.  So in this example, you would type in….

Nodes=${name}

When a new element shows up under the Nodes folder on the netcool adapter, it is assigned a class name “Nodes” (first part of text above).   The name of the element is the same as the name of the element under the structure ( ${name} ).   When you combine the two parts of the dname of where the source is pointing along with the Dynamic/Fixed setting (IE Node=server1/Nodes=Nodes/adapter=Netcool/root=Elements), you have the full dname.  This dname is what gets stamped on the element in the SCM generated view.  It basically points at an existing element or it is pointing at an element that may show up in the future.

SCM spins through all of the elements on the structure that qualify for the structures Match rule.   It then stamps every element with a hard coded dname dynamically built on the fly. When you look at the properties of the elements after running SCM, you will see one of two things.  Either an element in the properties tab with a condition color such as green, red, orange or an element with a white condition (diamond).  The ones that are showing a white condition may or may not be a problem.  Essentially the element is related to another element and the white indicator means that the element does not exist (right now).  Mouse over the element and double check that the dname name shown in the tool tip is correct.  If it is, you should be done.  Force an alarm to come in and test it out.   The view should light up WITHOUT having to run SCM again.

If you have other adapters, add additional Definitions in the SCM job and repeat the sequence.   Point the structure at the existing SCM generated view, narow down the structure match rule in order to not stamp every element.  Point the source to a location where the elements will eventually show up and then fill in the Dynamic/Fixed settings with the final part of the dname.

The Dynamic/Fixed option is a nice feature.  By using this, you may only need to run your SCM jobs every once in awhile, basically, you will only need to run it to do updates (adds or deletes) of devices or services.

Tips

  • I have seen many implementations where adapters have a mix of short device name and full qualified (IE: server1 vs server1.netiq.com).   There are a few ways you can “clean” up these names.  Typically Data Integrator (AKA: BDI) and Event based adapters (IE: any that have a hierarchyfile) can be set up to adjust the name.  For Data Integrator, add in sql functions to trip full qualified names to short names.  For Hierarchy File based adapters, place a java script in the hierarchy file to trim the names.   Sometimes you may have the short name as another property (IE: use ${shortName} instead of ${name} or whatever the property is.
  • Double check that you didn’t accidently forget the Match on the structure by look at other elements in the view and see if they have the static dname set up on them.
  • Dynamix/Fixed rquires a one to one, for each source location, you need a corresponding definition pointing at it.
  • One element can be stamped with multiple dnames such as the event manager, help desk tickets, etc, etc, etc.

As always, test this out on a development system and not in production.

- Tobin

 

 

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , , , , ,
Categories: Operations Center, Technical Solutions

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment