Unsolved
This post is more than 5 years old
71 Posts
0
148725
Multiple Clients, Different Rules
Hello Community
Is there any easy way in vFoglight 6.7 that different rule parameters can be used for different customers? Let me explain by way of an example.
We have copied the default CPU Utilization rule to "Cust_A CPU Utilization" with a Warning level of 75% (this customer is overly cautious). We also copied CPU Utilization to "Cust_B CPU Utilization" with a Warning level of 95% (this customer is laid back). Is there any easy way to get vFoglight to say that Client_1, Client_2 and Client_3 should be evaluated by the Cust_A CPU Utilization rule and that Client_6, Client_7 and Client_8 should be evaluated by the Cust_B CPU Utilization rule?
I want this to be as easy to administer as possible, so if I have to group the clients for each customer together, I only want to update one area and this one list should be queried to ascertain whether or not the client should be evaluated against the "Cust_A " or the "Cust_B " list of rules.
Similarly, when viewing Dashboard data, will Cust_A be able to see all the clients and data for Cust_B and vice versa? Can the two customers be isolated from each other?
Thanks
Brian
john_s_main
132 Posts
1
November 21st, 2012 12:00
You have a couple of things to do:
The first part is pretty easy.
Grouping the customer devices via Service Builder would be the best way to do this. You can group customer devices easily within hierarchical FSMservices, and get some real benefits through things like the Service Operations Console.
The second part is less simple, since there is currently no "template" way to apply a set of thresholds to metrics by FSMservice. A really important thing to be able to do, so a very good question.
I'll have to think about that, and see if those more knowledgable can contribute to the second part.
Brian91_4544b4
71 Posts
0
November 21st, 2012 14:00
Hi John
Thanks for the reply. I figured that Service Builder would be involved, but I was rather hoping that NetMonitor could be used instead - a query run against the Server Group field perhaps (or even a new field called "Customer" or something similar) to pick up all the devices for Cust_A.
As for using the Service Builder groups against particular rules, it'll be interesting what the Community come up with!
Brian
john_s_main
132 Posts
0
November 21st, 2012 21:00
I guess the question is whether you are using Service Builder to build the relationship between the customer/application and the device, or somehow tagging the VM with the customer and application and application stack layer, and then building the service configuration from that.
I have both cases to deal with in our environment. For the second, resulting primarily from our upcoming auto-provisioning process for VMs, I'm currently going down the road of the Knowledge Item as a way to tag VMs with additional information which might be applicable to multiple VMs, such as Customer, Application or Application Stack layer. This particular KI would be tied to the FSM service, with a list of references to the related VMs as a property.
However, once they fix the relationship system in Foglight, hopefully soon, we should be able to use that to relate the VMs to the FSMservices.
DELL-Thomas B
171 Posts
0
November 22nd, 2012 03:00
I'd probably start by creating services for each of the customers with their VMs and then in the rule I would scope the rule to all VMs CPUs or whatever object type you like. Then, part of the rule would look at the service ownership and based on that use some logic to pull the metric value to evaluate against. I would probably use a registry variable value and then edit that based on each of the services with their own value. There might be a simpler way...
Brian91_4544b4
71 Posts
0
November 22nd, 2012 07:00
This isn't just for VMs though, it's for the whole of the customer's estate - switches, physical servers, devices, VM hardware, VMs, services, etc. In other words, we want to monitor all devices for both customers but from within the same vFoglight environment, keeping the two customers separate (both from a rule perspective and from a 'we don't want Cust A to be able to see Cust B's alarms, devices' perspective) if at all possible.
I've got a feeling from reading elsewhere that this will not be possible, or at least, not without a great deal of effort which is what we're hoping to avoid...
Brian
DELL-Thomas B
171 Posts
0
November 22nd, 2012 10:00
You could just take a single rule then and modify it slightly for each customer if need be. There are two main schools of thought for this in my mind. One set of rules that evaluate all VMs (regardless of customer) and then fire based on registry variables that ARE tied to the 'customer' (aka. service) or one set or rules for each customer that are pre-tweaked with their settings. More work up front on the first or more on the later long term with upkeep and each customer addition will be 5 - 10+ new rules.
It's a bit to setup, but very doable in a day or two depending on how many rules. A basic poc of the rule should only take a few hours and then copying/pasting that rule and changing it slightly to fit each requirement, cpu vs. memory vs. disk for example...
The users, if locked to a view, will only see alarms for their objects and nothing else. I've got several large customers that do this and share out their environment in a hosted fashion like you are trying to do.