By: Alain Geenrits, Blue Medora
In the previous post (vRealize Operations Policies Demystified: Definitions) we looked at what policies are and looked a bit around in the policy library. In this post I want to show you how to actually create and edit policies and some use cases on policies with Blue Medora Management Packs.
Creating a New Policy
Policies are crucial to a good functioning vRealize Operations environment. Let’s look at the policy creation pane and the steps involved. Start a new policy by clicking the green ‘+’ sign in Administration > Policies > Policy Library. You will be presented with the familiar vROps panel-for-creating-things (Figure 1):
Figure 1: Creating a new policy.
On the left side you see the eight steps to creating a policy, you can always go back to a previous step if necessary. The first thing you notice after giving your policy a name and description is the ‘start with:’ dropdown (Figure 1). This allows you to populate your new policy with the settings from an existing one. This is very useful since you do not want to build everything from scratch and it allows you to build on previous settings. Go ahead and try it!
Figure 2: Show override settings and changes.
In step 2 (Figure 2) you can specify what objects you want to see the changes for in the right pane. Note that you can click the blue ‘all objects’ or ‘all objects with override’ or you can specify objects. Even the ones from Blue Medora management packs are here, like the Dell Blade Server for example! Don’t forget to click the green filter button to the right to add it to the list.
You can further change settings by choosing any number of override settings policies here. This means you can really construct a policy out of a number of other ones without touching one setting yourself. If you lose oversight you can check the right pane to see what settings are affected on a per-object basis by your choices.
Management Pack Policies
Before we jump in it is important to note how we handle policies at Blue Medora. You will notice when you install a management pack that a template is added in the Policy Library under Base Settings ( Figure 3.) These templates are empty so that you can change the settings in your own policy to meet your needs. You do not need to add the polices or use them as overrides. The objects will be available.
Figure 3: Blue Medora base policies.
So where do we put the default settings for our management packs? For every solution installed in vROps (including the base vSphere adapter!) a describe.xml file is installed. The describe.xml file is in the conf subfolder of the adapter, for example:
/usr/lib/vmware-vcops/user/plugins/inbound/dell_power_edge_adapter/conf. Note that /usr/lib/vmware-vcops is the vROps base directory on your node. The describe file contains all objects, metrics, analysis and discovery settings for an adapter and their defaults. It also contains the credential definitions. Figure 4 shows you the start of the Dell describe.xml.
Figure 4: Dell management pack describe.xml file.
You do not touch this file directly! The one time you use it is in case of issues, where you launch a ‘Redescribe’ action in Administration> Support. This effectively reloads a management pack with defaults. To change the defaults you need to create new policy settings. This brings us back to the Analysis Settings, Metrics and Properties and Alerts/Symptoms settings in the policy editor.
For the remainder of our policy creation, let’s look at the 3 most important use cases in conjunction with Blue Medora management packs, namely: Analysis Settings, Metrics and Properties and Alerts/Symptoms.
Analysis settings
In Figure 5 you see the next tab in the policy creation pane: Analysis Settings. If you want to change the settings for an object defined in a management pack, you need to click the green plus sign next to ‘Add settings for new set of objects’ and chose it from the dropdown list. In this case I added a NetApp Volume to the list.
Figure 5: Analysis Settings.
To override the settings (remember where these defaults come from?) you need to click the padlock icon to the right and then edit. Here (Figure 5) I am editing the Capacity Remaining and Time Remaining sessions.
Metrics and Properties
Under tab 5 of the policy creation pane you find ‘Collect Metrics and Properties’. These are the settings you are least likely to touch.
Figure 6: Metrics and Properties.
You see in Figure 6 that for a NetApp volume alone there are 16 pages of metrics and properties! For every metric there is a State, KPI and DT column. The drop down menus are similar. ‘Inherited’ is the default setting all around, meaning that the setting is inherited from the base policy and overrides defined before, or the describe.xml of the adapter! In ‘State’ you can explicitly stop the local instance of the metric. This can be useful if there is a metric you really don’t need and you have a very big deployment. You could create a policy to stop it from collecting.
If you define a metric as KPI it is not immediately clear what happens, unless you start digging in the documentation. The ‘vRealize Operations 6.3 Information Center’ states:
When a KPI violates a threshold, vRealize Operations Manager examines the events that preceded the violation. If it finds enough related information, vRealize Operations Manager captures the set of events that preceded the violation as a fingerprint. If it finds a similar series of events in the future, it can issue a predictive alert warning that the KPI violation is likely to occur.
In other words, this influences the dynamic behavior of vROps, trying to predict when KPI violations occur.
The DT column handles Dynamic Thresholds. I recommend you don’t touch it.
Alerts/Symptoms
The last step in the policy creation pane is the Alerts and Symptoms definitions. It is very useful to be able to suppress a Smart Alert from an adapter that is not useful to you. How to do it has been described in a blog post by Greg Hohertz: Using vRealize Operations Policies to Disable Alerts on Certain Objects – VMware Cloud Management.
Figure 7: Symptom Definitions.
Note that you can also change the Symptom Definitions here. If a threshold is defined in the last column – and it is not a dynamic one – you can click override and edit it!
That’s it! If you save your policy and connect it to some custom groups you made, you can influence the analysis settings, metrics gathering and alerts for all your adapters. So go try this out and as always let us know your findings!
