IT Operations Management (ITOM)
cancel
Showing results for 
Search instead for 
Did you mean: 

HP Service Health Reporter 9.30 - Master the power of Remote Collector - Part 1

HP Service Health Reporter 9.30 - Master the power of Remote Collector - Part 1

HPE-SW-Guest

By Vageesh Hoskere

 

So what exactly is this all about?

SHR 9.30 is out in the market and one of the things that makes it more interesting and powerful is the introduction of remote collectors. So here is a blog series that delves into some of the more interesting aspects and topics associated to collectors including (but not limited to) some tips and tricks (or trick and treatJ) that would definitely make things a lot easier and also hopefully resolve some the queries and the how’s and why’s that you may be trying to find answers for..

 

Great!! What is in it for me?!!

The concept of a remote collector resonates to that of a light weight component that enables distributed collection and also provides enhanced scalability for data collection in SHR. This component includes the SHR collection framework in its entirety with support to various sources including Database, OM, OMi, Agents etc. The most important value proposition apart from scale is the flexibility it gives to report on nodes that are part of a DMZ environment without having to haggle about with the admins on opening up a bunch of ports and sockets or monitoring those same bunch of ports for security.

 

Sounds Good. So what’s first?

I have highlighted that collector is one for enabling distribution and scalability, so naturally the first question that would come to mind is “how do I actually achieve this?”, which, is a very valid ask and is what I want to try and explain with this article.

 

Let’s start!!

The first step towards harnessing the power of remote collectors is the distribution of agent nodes for collection onto various collectors configured in SHR based on the requirement (which can range from scalability to availability to accessibility to a multitude of other adjectives). SHR comes with an Administration Console that lets you perform this configuration with just a few clicks. In order to be able to configure sources for collection it is important to know what goes on behind the scene during the process of node distribution.

 

The HOW’s

Agent distribution for collection on various collectors can be done individually or as a combination of the following –

  • Rules/Pattern based ( ex - .*.IND.HP.COM)
  • RTSM View/HP OM Node group based
  • Manual configuration of an agent to a collector

Now that we know the different ways of configuration, let us dig deeper into them to understand what it means individually and collectively

 

First Option: Follow the rules -

 

What it means?

Agent instances can be associated to a collector based on regular expression patterns matching the hostname/IP address of the Agent sources discovered. Any number of patterns can be defined linked to a single collector and all sources that match the pattern will be marked to be collected from that collector. In case of a node matching more than one rule/pattern across multiple collectors, the association will be made to the collector that has the first match.

 

Wait!! That makes sense. But what happens if and when there is a clash of rules?

Also, one more point of interest here is that there is no guarantee that the node will always be associated to the same collector in case it contends to multiple patterns as the assignment is always “first match first win”. It is very much possible that the node be attached to a different collector when a reassignment is forced by the user or topology collection is complete. But there will never be a case where one node is simultaneously assigned to be collected from multiple collectors.

 

Right.. So how do I make sure that my rules are correct and valid?

There is an information button next to the pattern pick list which is helpful in validating the entered rules against the agent sources before they are saved and used by SHR in node distribution. This lists as output sources currently discovered by SHR that are potential candidates for association to the collector and I say potential because as mentioned previously, if there are overlapping rules, it is very much possible that the final list may not be the same as the one indicated in the output. So please note the disclaimer - “All sources listed are for indicative purposes only!!”

 

Now for some hands on!!

 As an example consider the use-case where we want to collect from all sources in the US via a collector in US and all the ones in India from a collector in India. Supposing the node names are indicative of their location i.e. “*.us.hp.com” and “*.ind.hp.com” from the US and India respectively, the same patterns of “.*.us.hp.com” and “.*.ind.hp.com” can be used for the collectors from US and India respectively. Please note that it is not just “*.” but “.*.” because SHR uses regular expression patterns to match hostname/IP addresses which in turn gives greater flexibility and power to users in terms of accuracy for matching nodes. So the patterns can range from as simple on option as “.*” which signifies all nodes to “16.15[0-9].[1-9]?[0-9].10” which matches IP address range ”16.15*.**.10”.

 

So the next option - Wait, a “Cliff hanger”?

Not at all!! This completes the first part on collector and is just the beginning. Stay tuned for more with the next part in the series.

  • operations bridge
0 Kudos
About the Author

HPE-SW-Guest

This account is for guest bloggers. The blog post will identify the blogger.

//Add this to "OnDomLoad" event