Setting Origins centrally verses at the profile

[Anon Anon]

One of the top requested IDEAS for UIM Server is the "Ability to set Origin at the Profile level".  Specifically the request is:

In environments with multiple customers, origin is the preferred way to tag robots belonging to to each customer.  However, some robots often perform remote monitoring for multiple customers with probes like *_response, net_connect, and more. Being able to configure different origin for each "profile" in these probes would be a very logical, intuitive and smart way to solve this. 

 

My question to you all is this.  If we provided a centralized ability to manage Origins, how far would that you get you?  Say we provided a 3 pronged approach to manage this meta-data centrally; An API to set, clear, override, the origin value for a device or component (ie: interface), the ability to import the origin for inventory items (devices and components), and the ability to edit via USM.  In essence this would enable the data in the DB to be modeled the way you want, but it would not be coming from the probes themselves.  This means if you have automation scripts picking the data off the bus, prior to getting into the DB, you would not have the profile specific Origin, only the controller Origin as you have today.  Let me know your bigger picture workflows and why it would or would not work for you.

[Anon Anon]

This is partially a philosophical question as to which approach one

prefers: Centralized vs decentralized. Historically, one of the

benefits of UIM has been it's decentralized nature.

 

What you are suggesting is pretty much just what the AE does? But with

possibly a different API against it? If people just wanted a new

version of that, I doubt "Ability to set Origin at the Profile level"

would have become one of the top votes ideas.

 

Personally, I strongly prefer doing the full configuration of the

profile in one location, and not intercepting messages to manipulate

them. Origin is a basic configuration setting in a multi-tenant

environment and having to configure all these profiles in two locations

adds additional complexity to the monitoring system.

 

Unnecessary complexity is not really the hallmark of a good monitoring

system. And adding components in the message flow that changes them is

just that. You have more components that can fail and/or malfunction in

your alarm flow. More ways the configuration can get wrong.

 

And as you mentioned, if you are picking data off the bus (as we are

doing in some cases), having this feature centralized does nothing for

you.

[Anon Anon]

Hi,

 

I'm working for an MSP so I also face this issue. I have some thoughts on it, not all pertaining to the environments that I run.

 

James Cooke wrote:

 

This means if you have automation scripts picking the data off the bus, prior to getting into the DB, you would not have the profile specific Origin, only the controller Origin as you have today.

I'm assuming this will mean alarm_enrichment like component, not fiddling with the data once it is in the database. This would mean intercepting at least qos messages in addition to alarms. Philosophically I'm not a big fan of intercepting anything, especially alarms, before they are ready to be published to any subscribers (email notifications, consoles, sms etc).

 

Also, what about multiple nas environments? There maybe nasses that do not have direct access to the DB and therefore these components would need to access database remotely, maybe through the bus. Depending on the size of your inventory and all the data that you need to get (does it only do origin override?) you might need to transfer significant amounts of data each time a probe restarts, or inventory get updated.

 

Overall, I'd prefer the "profile" level control over this. Additionally I think it would be better  if you could manage origins per device or metric id on the spooler level rather than doing it by intercepting everything by a central components. I think this would also be much easier than implementing it on profile level, even if not quite as user friendly.

 

-jon

[Garin Walsh]

Any time you introduce something that causes data to be interpreted differently depending on where you look at it (local to the originating hub, as an alert message, as a QOS message, before processing, after processing, etc.), you will create problems.

 

Keep in mind that Origin is also on the alerts that are generated. It would be meaningless to have data the belonged to Origin B in the database but corresponding alerts that belonged to the original origin A.

 

You need the data and the alerts to be consistent and you need the origin to be part of that consistency.

 

-Garin

[Anon Anon]

This has me thinking...  Say we add the ability in USM to edit inventory attributes like Alias Name, Location, Service Level, Timezone, Origin, and other user-define attributes.  These attributes would be available within USM, supplementing the other meta-data about devices and components typically discovered via discovery agent interrogating the devices with various protocols or from probes providing device meta-data.  While there would be Services and API's available to consume this inventory meta-data, generally speaking it would not be present at the NAS or other bus intercept points, which I gather from this thread is a significant use-case.

 

Additionally even today we have to deal with multiple sources publishing meta-data about devices and components, where each potentially has different value for the same attribute.  Because of this we have built-in correlation and reconciliation processes to figure out if the different data source are describing the same device or component and which attribute from which source is the one to utilize as the master.   If we had three different profiles from different probes each attempting to set the origin for the same interface on the same device, and the user manually setting origin via USM, it becomes very complicated.   Today origin is one of the keys that identifies a unique inventory item.  So in the case above, that one interface on the same device, defined by 3 different probe profiles, would end up being 3 inventory items in USM.  Maybe there are cases where this is what is desired outcome.  But if not we need to provide the means to override or influence the correlation and reconciliation rules to get what you want.

 

Thanks for the considerations.  Keep them coming.