You've deployed VMware Aria Operations (formerly vRealize Operations or vROps), configured your vCenter Adapters, and are now seeing data! In fact, you're seeing too much data, in this case Alerts on your non-production VMs you're just not interested in. How do we turn these off? Policies!
Aria Operations installs with a default Policy called vSphere Solution's Default Policy.
You will want to keep this in place and build new ones based on it, as the vSphere Solution's Default Policy gets overwritten at upgrade time.
So, what is a Policy? Basically a set of Metrics and Properties, Alerts and Symptoms, Capacity Policies, Compliance Scores, Automation Rules, and the Groups and Objects to which they apply.
Let's explore Metrics and Properties first by selecting the tile.
There are a total of 169,962 Attributes (Metrics and Properties) for 1747 Object Types (VMs, Datastores, etc) defined here. This is where you turn on/off Metric/Property collection. Select the Object Type from the drop down.
I've chosen Virtual Machine and am exploring the CPU metrics being collected. Each metric has a State and an Instanced State. There are four different States:
Activated - indicates that a metric/property will be collected.
Activated (Inherited) - indicates that the state of this metric/property is inherited from the base policy and will be collected.
Deactivated - indicates a metric/property won't be collected.
Deactivated (Inherited) - indicates that the state of this metric/property is inherited from the base policy and will not be calculated.
As an aside, you will also notice the Instanced State field. This allows you to enable the metric/property on instances of objects, say for example CPU Usage on vCPU1, vCPU2, etc.
Next up Alerts and Symptoms! Click the Alerts and Symptoms tile to go into the details.
There are 7119 Alert Definitions against 498 Object Types here. Let's look at the Alert Definition against VMs.
The State here indicates if the Alert Definition is Active, Deactivated, and/or Inherited from the Base Policy. This is where you will turn on/off Alert Definitions. You can do the same thing for Symptom Definitions via that tab.
Next up, Capacity! This is where you configure Time Remaining Calculations and use Business Hours.
There are three options for Time Remaining Calculations:
Conservative - this is the default setting and generally used for production environments. It provides for the most generous projections available. For details on the algorithm see VMware Staff Technical Marketing Manager Brandon Gordons blog here. As of Aria Operations 8.10, there are five levels of this, level 3 being the default. Turn the dial to 1 for the most Conservative settings and to 5 for the least Conservative projections.
Aggressive - often selected for most non-production environments. Uses the mean of the upper and lower projections described above.
Peak Focused - will make projections based on the upper range of data described in the algorithm above, giving more weight to the historic peaks.
Beyond that, as of Aria Operations 8.10, we can also define Business Hours, such that capacity projections can be made just within Business Hours, as you define them.
The next tile in a Policy is Compliance! This is where you can adjust the Compliance score based on the number of violations against Compliance Policies.
Workload Automation is the fifth tile in a Policy and were you can adjust how Workload Automation is performed across your environment.
The default is Moderate which will minimize workload contention, but not move workloads to achieve balance or consolidation. It will avoid performance issues with as few moves as possible. You can also define Cluster Headroom and turn off/on Storage vMotion capabilities.
Finally, Groups and Objects, is where you assign Policies to Groups.
For example, and the very first Policy use case for almost every customer, will be to turn off certain Alerts against a group of VMs. How do we do this?
First, create our Custom Group of VMs by going to Environment - Custom Groups - ADD.
This Custom Group contains all VMs with the string "bpeterson" in their name, these are all my VMs. Next let's create a Policy with the Alerts we want turned off. Go to Configure - Policies - ADD.
When creating a new Policy you base it on a previous one, we call this inheritance. In my case, I'd like to base this new Policy on the Default Policy, which is called vSphere Solution's Default Policy.
We now have our new Policy, so let's disable the Alerts we don't want. Click on Alerts and Symptoms.
This tells us that we have 7119 Alerts Definitions against 498 different Object Types in this Policy, but nothing defined locally, we're going to change that. From the Select Object Type dropdown choose Virtual Machine.
Here you can see the Alert Definitions that are Activated and those that aren't. I'd like to Deactivated all CPU related Alert Definitions for my VMs, I just don't want to be bothered by them.
Adjust the State to Deactivated for the ones that were Activated, I left the Deactivated/Inherited ones alone as they were already Deactivated as part of the vSphere Solutions Default Policy, the one we inherited from. Click SAVE.
You can now see that we have 15 locally defined Alerts Definitions in this Policy. Next we assign the Custom Group by selecting the Groups and Objects tile.
Find your Custom Group, select it, then click SAVE.
You can now see that your new Policy has 15 locally defined Alert Definitions and one Custom Group. Back at your Policy listing, you can now see your new Policy.
It's within the vSphere Solution's Default Policy stanza because it's inherited from that Policy, along with the others that you see. You'll notice it has Priority 3, which means Policies with Priority 1 and 2 will be run before this one. Let's move it to Priority 1 to make it the first Policy run. Go to the three dots at the top, select Reorder Policies and move our new Policy to the top.
You will now see our Test Policy for Blog is Priority 1, while the others have been moved down, and our vSphere Solution's Default Policy is D, for Default. The Default Policy is the last Policy in our list, best practices would keep this as your vSphere Solution's Default Policy and act as a catch-all for anything making it through the previous Policies.
Now, to confirm the VMs in your Custom Group are in the proper Policy, let's go find one.
Top right, you can see the Active Policy for the VM, which is the Policy we just configured. Policies are super powerful and can be used for everything from Alert Definitions to Capacity Projects. For more information on VMware Aria Operations please visit the VMware Apps and Cloud Management Tech Zone site!
Comments