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.
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!
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.
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...
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...
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.
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.