vcops

If you have been looking into vCenter Operations Manager you have probably heard about Super Metrics, Dashboards and the Custom UI. In this article I will help you build your own dashboard that uses a super metric. The high level approach to this:

1. Create super metric packages and add the metric packages to your inventory
2. Build a super metric and add the super metric to a super metric package
3. Build a dashboard that uses the super metric

1. Create super metric packages and add the metric packages to your inventory

A lot of different guides I have seen starts by building the super metrics. I think it makes more sense to start by building empty super metrics packages and apply them to your inventory. My suggestion is the following approach. Build super metric packages based on different levels.

• Host Super Metric Package
• Cluster Super Metric Package
• Virtual Machine Super Metric Package
• Datastore Super Metric Package
• etc.

Then when you build your super metrics you add them to the group they belong, and after a few minutes data should be available in the inventory.  To build your package groups start by logging in to the vC Ops custom ui. In my environment the URL is: https://vcopsuivm.vclass.local/vcops-custom

Then go to Environment – Super Metrics – Package editor 

After creating your package groups you should see a screen similiar to this

 

Now we need to add the packages to our inventory. We need to do two steps for this. One is to add it to existing objects and another is to add it to future objects. For instance when you add a new host to cluster you want the super metric package to be applied to that host automatically.

To add the host super metric package go to Environment – Environment Overview – Resource Kinds – Host Systems 

The select all hosts (if you want the super metric on all hosts and click “edit” and add the Host Super Metric Package to the objects. This means that whenever you create a new super metric for a host just add it to the correct super metric package and it will start to work right away!

Do the same for you Cluster, Datastore and Virtual Machine super metric packages.

The second step we can add is to make sure the super metric packages will also work on new objects, for instance new hosts og newly created virtual machines.

Go to Environment – Configuration – Resource Kinds Defaults and configure it like the screenshot

Now we are ready to start building our Super Metrics

 

2. Build a super metric and add the super metric to a super metric package

I have borrowed an example of a Super Metric from the following pdf the super metric we want to build is to find the virtual machine with the highest amount of Memory Ballooning in KB. To do this we need to use the metric “Memory Balloon (KB)” and the function maxN in vC Ops. 

Go to Environment – Super Metrics – and create a new Super Metric. Look at the screenshot

 

After creating the super metric then go to the super metric packages and add it to the “Cluster Super Metric Package”

Now you just need to wait at least 5 minutes for the metric to start appearing. The easiest way to verify it is working is to to the normal vC Ops user interface, select your cluster, operations, all metric and look under the super metric category

 

When you see data in the Metric Chart you are ready to go to the next step which is to add it to a dashboard.

3. Build a dashboard that uses the super metric

There are many guides out there showing how to build your own dashboards. In this configuration I build a dashboard with two “Generic Scoreboard Widgets” and two “Metric Sparklines”

 

And the END result

After teaching vCenter Operations Analyze & Predict and facilitating private workshops with customers I have had this one question that always pops up. What is the criteria for vC Ops to say a VM is oversized or undersized. 

To understand how it is calculated is just one thing. What is more important is what you do with the sizing recommendation. Even though Operations may find a machine to be oversized it does not necessarily make it true. 

First thing you will need to do is go into “configuration” from the vC Ops website. Here you can configure the thresholds for oversized and undersized VM’s. The settings in the screenshot is right now at default. I have made some marks in the screenshot. “1. Oversized threshold: 1%“, “2 CPU deman less than: 30%“, “3 Memory deman less than: 30%“

What this means is that if a virtual machines is using less than 30%CPU or 30%Memory for 1% of its running time it is considered oversized. Actually it is not based on time. But it is based on “Area” Look at the next screenshot. The threshold of 30% is the “U” and the threshold of 1% is the blue area. So if the area of the blue is more than 1% of the graph it will be considered oversized.

With the default settings of 30% CPU/Memory and oversized threshold of 1% I bet you are going to have A LOT of virtual machines that are considered oversized. For instance if you have some machines who are idling most of the time but in peaks need LOTS of CPU they will definitely be considered oversized even though from the administrator perspective it is not.

I would change the settings for the threshold. Per default you get way too many oversized virtual machines. I recommend the following:

• Oversized Threshold: 10%
• CPU Demand less than: 15%
• Memory Demand less than: 15%

 With these settings a virtual machine is oversized if the area on the graph below the threshold “U” (15% CPU/MEM) is 10% or higher. This is just one recommendation, you can tweak the setting to your own liking.

 

 

I have been playing around with vCenter Operations Manager a lot lately. The more I use the product the more I find it useful. At first glance Operations Manager you just see a 3 major badges and 8 minor with some colors that tell you whether an object is performing like it should or not. When you go deeper into the product you find a very useful feature called Heat Maps. You find the Heat Maps under the “Analysis” tab. Here is an example

This is a custom created Heat Map that shows us every VM grouped by ESXi host and colored by the CPU Ready time in ms. This is the configuration for the heat map

What you should notice in the configuration is that the VM’s are colored by “cpu usage” but the size is fixed. This means that every VM will be the same size. If we wanted to we could add another the cpu usage | ready (ms) to the size. This would mean that that heat map would change to the following

And the config looks like this now

In this case we used the same counter for both color and size. To make it more interesting we could create a heat map with two counters. Lets say we wanted to figure out what machines in our environment used the most IOPS and had the highest latency then we could create a config like this

And the result would be the following heat where the biggest box is the “commands per second” (IOPS) and the color is based on the read latency (you could change to write or use overall latency)

 

The custom heat maps are a great feature to use the data your vCenter Operations have collected. I would suggest you to look into this feature if you are so lucky to have the product installed.