Operations Center – Static Match vs Dynamic (and more)

Tobin Isenberg

By: Tobin Isenberg

November 18, 2013 5:55 pm

Reads: 593

Comments:0

Rating:5.0

When setting up views in Operations Center (manually, viewbuilder, Service Configuration Manager, etc), you have several ways to relate elements from adapters (or other views) to your view. For instance, suppose you were setting up a view of the important Services within the Enterprise. The first level of the view might be things (elements) like:

  • EMail
  • Payroll
  • Accounting
  • Timesheets

The next level below the Services might be the technologies supporting the service such as:

  • Web Server
  • Database
  • SAN
  • Switch

Then under this level you have actual device/server names such as:

  • server1.netiq.com
  • router4.netiq.com
  • san27a.netiq.com

The next thing to do is to light up the view by correlating the actual real time health of those devices from your adapters. Regardless of where/how you are setting this up (Service Configuration Manager, Viewbuilder, manually), you have four basic options.   Specific matching from one element in the service model to one specific element under an adapter (or other location), ie: Static.   There are also options to leverage perl (reg ex) matching, LDAP like queries, class, etc, etc, etc.   From within the dialog (Element Properties), there are four main categories with multiple options.  Within Service Configuration Manager, they are a bit re-organized between the Join rule and Modeling Policies/Correlation.  Regardless, there are four core types of matches.

Scripting:

This option is pretty powerful, but it is also the least used option by customers.   The idea is that you have a very complex set of rules on how management data is related to the views.   You literally have to write a full fledge script and return a boolean value to determine if the specific data (element) from an adapter should or should not be related to the view.

Pro’s:

  • Full control over how matching is done.
  • Allows for complex compound matching.  Property = a, children of b, name of z, etc, etc, etc

Con’s:

  • Requires development experience to write script
  • If script is not optimal, Server may have serious performance problems.
  • Script does not fire (evaluate) under every single situation (ie: new element arrives on adapter, it is typically evaluated, new alarm… maybe)

There are some doc examples, but I believe that the other match options work more desirably.  If you must use this option and are unable to figure it out, send me a message and I’ll talk it through with you.  One last thought, a example I have heard from customers more often is based on relating an element from an adapter based on contents of an alarm.  While you can use the scripting option for this situation, you need to be extra careful.  The script accessing an alarm can be expensive (the server retrieves the alarms regularly).   If you *must* do this, make sure the view is buried down in a view and will only ever evaluate a small amount of alarms or you will see performance problems (server slow and/or view not up to date near realtime).  What works today may not work down the road very well.  BE CAREFUL!!!

Class:

Matching one element (IE: server1.netiq.com) based on class of elements under an adapter doesn’t make sense, you need to match on the name of the element, not the class.  If you have a technology type of view where you have Databases, Web Servers, Switches, etc makes more sense.  For instance, automatically relate any elements of class “webserver” to the view called Web Servers is a nice option.  As long as the class names are commonly known, this is a nicely automatically maintained list.

Pro’s:

  • Simple to set up, just need to know the class of the elements
  • Generic, but specific

Con’s:

  • You must know the class up front.
  • This is more of a one to one, ie: one view to one class
  • You don’t have control over the name of the class on all adapters, the underlying tool establishes that in some cases.

Static:

Static is achieved several ways.  Static meaning, a specific element, in a specific location is related to a specific view.   In many cases that is perfect to use, in some situations it might not be ideal.   Static is achieved multiple ways depending on where you are in the client.  For instance, a drag and drop sets up a static match.  Using the default settings in Service Configuration Manager sets up a static match.

This can be a pretty long topic itself, but really requires understanding the different scenarios (should I use static, or something else).   It’s hard to boil down to a single answer.

Pro’s:

  • Specific is specific  :)   This specific element is related to this specific view.
  • Forces some adapters to get current status (more on this later)

Con’s:

  • If the element doesn’t not exist, you cannot drag and drop (more on this later)

Match:

Matching is based on leveraging Regular Expression, (AKA: RegEx, Perl, etc).   The idea here is that you set up a rule for matching such as looks like, tastes like.   This is useful if you have several tools, the element is under an adapter but can move around, your naming conventions are not the same across adapters and several other reasons.   In the end you are saying things like server1.netiq.com in my view should be related to any element, under adapter A with any element that is named 192.168.0.45 or server1 or server1.netiq.com or, or, or.   To do this, you leverage the regular expression matching.  Something as simple as server1.* (conceptually)

Pro’s:

  • Endless matching options
  • RegEx evaluates quickly (versus scripting)
  • Lot’s of examples on the web

Con’s:

  • RegEx is a whole language (IE: C++, Java, assembly), you need to learn it to use it
  • Not all examples on the web are drop in and use (IE: requires thought translation)
  • Poorly written match rules will hurt performance of your server (IE:   .*server1.* )   Endlessly searches the entire NOC server due to prefixed .*

There are a few other match options such as LDAP, this is useful for matching on properties.  This is also a language in itself.  Unless you invest time to learn LDAP matching language, it can be tough to set up.   Since I rarely use it, I have to relearn it each time.

 

So let me roll this up and put a bow on it.  This section of the blog will be a collection of “my” opinions and hopefully organized random thoughts  :)

You can leverage the matching options in different places.   Create Element, Element Properties/Elements, Service Configuration Manager, Viewbuilder, drag and dropping elements, scripting, etc.   In the end, the match has to fall into one of the options under the menu/tab option of Element, Properties, Element.

 

ElementPropertiesDialog

Some of the options (IE: Match) have additional features (IE: regex match vs ldap match).   I can’t say that one specific option is the best, but I can tell you that static (specific matches) such as using the “Elements” tab in the view above vs “Match” tab is the best performing.  But due to the adapters you are using, the way the views are set up, your naming conventions, etc, other options (IE: Matching) might be the best choice.  So there is no single concrete answer.   The best I can do is provide you with some trade off’s.

First thing to determine is the adapter and how it does discovery.  Some adapters have a lazy discovery option, meaning, due to the potential size of an adapter (IE: Openview), it only discovers the fist layer or two of the adapter.   As users click on things more layers are discovered.  If you have views set up with RegEx matching, it may not automatically on start up relate elements multiple layers down the adapter to your view until someone clicks deep enough into that adapter.   Sorry, that is just the way it works.   We have had customers over the years that needed lazy discovery for other performance problems.  This is typically a setting on the adapter so you have to weigh the trade offs.

The good thing is, if an adapter has a static match, (from what I remember from many years ago), it doesn’t matter if the adapter is lazy or not, NOC will force discovery to that branch based on the static matches.   I would like to caveat this statement based on historical knowledge.  I do not think this has changed in the product, but it is possible.

As for RegEx, it acts more like a Dim Sum restaurant.  You are sitting at the table with an idea of what you are hungry for (RegEx match rule).  When a item is cooked (element discovered and shows up on an adapter), the waiter walks around to each table (internally NOC passes newly discovered elements to all views) and see’s if the customer (view) is interested in the item (evaluates the regex match).  Ok, either that analogy worked perfectly or it was a complete mess.  The gist of it is, as an element is discovered on an adapter, it is passed to the elements to run their regex to see if there is a match.  RegEx is fast, but if you have thousands of these firing, it can cause a performance strain on the system.

Another thing I run into is the customer is setting up multiple views (service based, technology based, customer based, etc).  They end up doing the match (static vs dynamic) over and over again of the same elements.   While this is easy to set up, again, it may not be ideal for all situations.   It might be a better idea to set up a list of all hosts/devices, correlate (match via regex, static, etc) in that one single view and then use that for all the other views.  This way you have one view (all hosts) with more complex match rules (short name, long name, IP address, properties, etc) run once and then the simpler matches server1 = server1 in the other views.

One last thought, specifically on Service Configuration Manager.  By default SCM does static matches (which is fine…sometimes).   If you have an event based adapter (IE: adapter has a hierarchyfile), typically if there are no alarm, there is no element, so in turn, SCM does not set up a match.  That means that either you need to run SCM often to make views light up, or you use a Match rule (regex) so when an element (alarm) finally shows up, it will automatically related the managed element to the view.  As I said before, this is fine, but if you have thousands and thousands of regex matches, it *might* turn into a startup performance problem (IE: after the server starts, elements are discovered, the server is spinning for an hour trying to finish up all the regex matches… server is up, to many things are green).  An option I like to use in SCM is the Dynamic Fixed.  The idea behind this is that you know that the element may or may not exist under the adapter right now.  Regardless of that, you know the place in the adapter it will show up, the class name and the name of the element… you can pre-register for the element.  Dynamic/Fixed builds a string of the dname to pre-set up a static match.   I can’t find the blog on that topic, so either I’m losing my mind or the blog disappeared. If I can’t find it, I will (re)blog it.  The value in Dynamic/fixed is, it reduces the need to regex matches (processor ticks) and sets up a static match (and in turn reduces the need to run SCM over and over again).

I hope I answered more questions than confusion.  If you find this blog useful, please comment, if you have additional questions or topics, please let me know via comments also.

- Tobin

VN:D [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
Operations Center - Static Match vs Dynamic (and more), 5.0 out of 5 based on 1 rating

Tags: , , , ,
Categories: Operations Center

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