Often we hear from customers that they get so many alarms they don't have time to sort through them. The monitoring system they use fires too many alerts, and they just end up ‘white noise’ instead of actionable items. Are you getting too many alerts? Often times too many alerts is worse than too few.
As administrators, we need to find a way of getting alerts from systems that are important and weed out the ones that we do not care about. Most performance monitoring alerts in Foglight have an all or nothing problem. They are either turned off or apply to every object in your environment. I have a solution to this problem. How would you like to scope your rules to only the objects you want to hear from?
This is part one in a three-part series of how to configure your alarms to do exactly what you want them to do. Today, we will go over how to scope your rules to the objects you want them to monitor, or scope out objects you don’t want.
Here's an example. I run a virtual center with 15 ESX hosts. Only three of the hosts are used for production, and the remaining hosts are used for development. I need to monitor the ESX Hosts' CPU utilization for only the three production ESX hosts, and not the others.
1) Here is the rule I want to modify. Go into the Rules dashboard and edit the rule. Drill all the way down to the screenshot shown below. We will be playing with the Rule Scope at the bottom.
2) If you click on the green check, all the objects the rule is scoped to will be displayed in green.
3) Click on the wrench, and we can begin scoping out this rule. In the instances tab, select the objects you want to include and insert them in your scope.
NOTE: the object is defined by the uniqueId in this situation.
4) Join them together with the word ‘where’ and click on the green check to verify the scope is correct.
Congratulations, you have just scoped this rule to only these three objects!
Taking the next step.
You can explore other syntax for this by clicking on the wrench and going to the filter tab to insert several commands together, or negate servers instead of only including them. In this example, I used the UniqueId to define the object, because it was already enumerated in the scope. But, you could use any identifier.
Stay tuned for part two in this series, using a group to filter out servers instead of one server at a time.