This post is a semi-detailed tutorial on building your own dashboard using out-of-the-box widgets in VMware vCenter Operations Enterprise. The information presented is based on how I’ve been using vCOps over the past year which should be a good starting point for anyone that is looking to go beyond the standard dashboards, dashboard templates, or analysis views. I explain some of the basics and also some of the gotchas that you can run into when building these dashboards. Some of the views presented are specific to storage, but overall it should be useful for any metrics and resources available within vCOps.
It is very important to mention that this configuration is done using the custom portal and NOT the vSphere portal in vCOps. The vSphere portal is statically configured in a way that allows you to get very useful data and switch contexts for that data in an out-of-the-box way. The custom portal is where you can go (Enterprise/+ only in v1+v5) and create your own complete dashboards. The custom portal is also the location where you access the 3rd party metrics that may have been brought in through 3rd party adapters (Java RMI) or the vCOps open adapter (HTTP Post).
The first thing that I want to do is walk through how to create a new dashboard. There are default templates that come with vCOps which are those that include a set of configured/unconfigured widgets. We could leverage these templates since they contain widgets and dimensional styles that may be desired, or we could use the template and remove the widgets once they get added. Instead of either of these approaches, I will demonstrate how to create a dashboard from individual widgets without a template.
Login to vCOps through the custom URL as listed above and press the “+” button on the dashboard row.
You will see the template screen load, go ahead and press the icon in the top left corner as shown below. This will bring up the screen that allows us to simply choose widgets.
Now we get to choose the style and name of the widget that we are creating. On the left side you can see the drop down where we decide how many columns that will be presented in this vCOps dashboard.
We have selected three columns and you can see on the right side that our page setup has changed to three vertical columns. Our next option is to actually slide the two columns in the middle left and right which creates custom dimensions for the width of my widgets.
In the following screenshot we are now showing the list of available widgets on the left and the subscribed widgets for this dashboard on the right. I can simply drag and drop any widget from the left to the right. The order does not matter on the right side and has no permanent effect of how widgets will be displayed on the dashboard, so simply drag and drop any widget that you would like.
I have dragged over a handful of widgets that I will now demonstrate how to configure. You can see the health-workload widget, generic scoreboard, heat maps, and a metric graph. This by no means indicates the usefulness of any of the widgets, they all have value and I encourage you to play and test them out!
Gadgets with VNX Data – Performance Metrics
This section will demonstrate some of the common ways that you can visualize important VNX storage array information with the scoreboard, heatmap, metric graph widget. We showed you how to create a dashboard above, go ahead and drag the widgets listed to a new dashboard. Once you have done this click the configuration button from the Generic Scoreboard.
You will notice that the following widget configuration window arises. The information here should be pretty self explanatory. However, I wanted to take a quick second to describe some of the buttons on the interface that are common to vCOps.
The following shows up under the configuration of the widget. On the bottom left of the red box it has an icon marked with an “x”. This icon refers to “clear selections” and removes any rows that you may have selected in the list. This is important to remember as vCOps is filled with selectable boxes and filters. It can be very easy to not get the results that you were expecting because you have an existing selection that may be hidden from you. The button to the right with the green arrow has to do with multiple selects. In this case we are selecting a resource and on the right side vCOps, it is populating metrics for this object. What if we had a case where we had multiple objects (SPA & SP B) which are the same Resource Kind with the same metrics. Wouldn’t it be easier just to select both SP’s and then have the common metrics be displayed on the right? And then when I select a metric and hit the multi-select above those metrics that both SP’s metrics populate in the list at the bottom? This is exactly how it works.
Ok, time to move on. The following window shows the configuration of the Scoreboard widget. We have populated metrics into the selected metrics box as described. We have also assigned “Box Labels” and “Measurement Units”. You can see from the screenshot below the widget configuration where we display the widget itself that those items show up above the metric and to the right of the metric. The other important thing has to do with the range.
Note: See the User’s Guide (v1.0.2) for more examples and detailed information here.
The range is a tough one to get correct without an example. The “green range” refers to anything up to the green maximum, so in our case we enter “40” for SP utilization. The “yellow range” refers to an amount between the minimum and maximum of that range, so for this we enter “40-60”. We repeat the same in orange as a range of “60-80”. The “red range” is then configured with the minimum of that range, in this case “80” which covers anything between 80 and up. We also configure throughput as IO/s in the scoreboard, but feel free to choose any metric.
The next examples will be leveraging the “Heat Maps” widget. We will be repeating the usage of this widget across many different types of objects, so the explanation of how to configure it in general will only be done once.
The heatmap is an awesome way to visualize data. When looking at the widget generated, there are two main options for displaying metrics. The first is the “Size By” and the second is “Color By”. This allows us to specify two separate metrics for a single resource. The heatmap is used in the Analysis -> VC Analysis tab where VMware has packed in some great generic views. You can refer there for other examples of how you might format information. In terms of storage I would point you to the heatmaps that refer to Datastore, there are some really good ones there.
Getting back to visualizing the data. The heatmap allows us size the boxes displayed by a quantity and color them possibly by a health indicator. For example, if I want to see the hot datastores then I can create a heatmap that looks at the IOs as the size of the box and the response time for that datastore as the color. This is a very powerful view of exactly how my storage is performing out of the box for vCOps. You can even take this to a more VM specific heatmap where you see virtual disk IO and response times. The other bonus for heatmaps has to do with how we group the information being presented. It would be one thing just to show say VMs on a heatmap and size as discussed. It is another thing to actually group those VMs into possibly the ESX host first, and then display the VMs after that. This way we would have another metric displayed which would be the ESX host’s aggregate IO being generated for those VMs along with the previous view of simply VMs.
We leverage this grouping in many different cases. For the examples below we are actually pulling data from 5 different VNX’s. In order to properly segregate out the resources we needed to create a “tier” ahead of time where we could properly define what those resources were. Unfortunately, identifiers (uniqueness of resources) aren’t possible to group by. So we use tiers instead and this generates what you see in the widget screenshot below the configuration where you see the array name itself, and the objects inside of the major group box pertaining to that tier or array. Don’t worry about tiers if you’re just starting out!
The next thing to point out is the “Resource Kinds” drop down. This drop down is where we specify which resource we want to pull metrics for. By populating this drop down with a resource kind, the lists below it for size and color are populated. The section below the “Size By” and “Color By” lists refers to how we filter the data being returned. This would be a case where we wanted to possibly display the resource kind of Virutal Machine, but there were specific VMs we wanted filtered or not filtered. We could create custom tiers, applications, or any of the listed tags to filter appropriately. The combinations in this area are essentially limitless.
The next section to highlight is in the top right on the color spectrum. You can see that there are two squares which allow us to customize the colors that show up during a range of values that are returned from the “Color by” metric selection. If these are left blank then the widget will take the maximum and populate the color manually. For percentages that are predictable for their health (utilization is a good candidate), it is always a good idea to fill in 0 and 70 for the range of green to red. However, keep in mind that some metrics may be reversed where being higher might not represent being worse and could be the opposite. In these cases you can press the box below the color spectrum to reverse the colors. You can even use a small trick to choose black for one of the left or right color boxes which (if you have dark set for user preferences) will make the box empty until you hit a certain point in the range. The black would reference no activity value instead of a good or bad value.
One last important thing to mention for heatmaps is around saving your configuration. Use the green plus button at the top right to create a new profile for each heatmap widget and configuration. When you have changed anything for this widget, either press the save button (disk below green plus icon) or press the green plus icon (for a new config).
The next widget that we will run through configuring is the metric graph widget. You can see here that there isn’t much to this one. You simply select a single or many resources from the list in the middle and then using the drag and drop method or the multi-select icon to bring the resource metrics up on the right. This is then followed by the same action, or the multi-select again to get the resources to the bottom list. You can then drag and drop those resources in the “Selected Metrics” window in the desired order.
You can see in the following screenshot that the legend at the bottom lists the values that we selected in the configuration. Defaulty, this widget may display the graphs individually in a list. However, we wanted to see everything overlayed together so we hit the button on the top left with the green and red lines which toggles between many and single metrics per graph.
An important thing to note with the graphing is the calendar portion of configuring the widget. There is a line and an arrow in the middle of the line above the graph. You can press this which will reveal the calendar portion to properly set the desired timeframe. We selected last hour in this example, but this can be whatever you want. Simply press the line with the arrow (divider) to hide the date selection.
Health is an very important and useful feature within vCOps. Health relies on a lot of different metrics, their anomalies, and ties this together with context sensitive information about how relevant those metrics are to the overall health of the resource and its dependencies. The longer you analyze the metrics the better that vCOps can make good decisions about proper dynamic thresholds (DT) for that metric. All of the EMC metrics can contribute to the health of that resource over time. Let’s take a look at some different views that might help us dig through the health of resources.
For the following examples we will be leveraging the Health Status and Resources widget. These two widgets actually interact together so that we can at any time change the context of what we are viewing by clicking on the Resource List widget and have that change the view in the Health Tree.
We start by simply dragging the widgets over into the dashboard as described previously and configuring the health status widget. The only selection that we changed has to do with the Mode, where we set “parent”. This simply means that when this widget receives a request to change views that it looks at what was selected and then displayed the parents of that resource. It is important to make sure that “Self Provider” is not enabled here.
The next thing is to click the “interactions” button on the top right of the dashboard view.
This is where we can setup the relationship that determines where the actionable selection as mentioned previously gets displayed. In this case we are selecting the “resources” widget as the provider which means the health status widget will change context whenever we click a new resource in the list of the resource widget.
Go ahead and test this out once you save the configuration. You should be able to click through the resource list and have the information populated to the health tree widget.
Now the resource list that we are viewing may not need to be for all resources that vCOps has access to. If we want to limit the list this is a perfect situation to leverage a filter. The following is a list of proper filters for this example “Datastore,DISK,LUN_*,RAIDGROUP,SP,VIRTUAL MACHINE”. Remember the selection and de-selection process above the tag list. It never hurts to just use the de-select button (not red slash, that is reverse). We have also leveraged the order capabilities below the filter to make the list a bit neater for viewing.
With that complete you can now see the more friendly listing of resources and their health.
Now let’s take this to the next level. There are plenty of other widgets that can be added to this dashboard and viewed at the same time that might be useful. I added the Metric Selector widget which you can now see listed under the Interactions section of the dashboard. I am going to populate the metric selector with the resources as a provider. This will allow us to select a specific metric for a resource once it is selected.
You’ll also notice that we added a Metric Graph widget. We can select the resources provider in the top drop down, followed by the metric provider in the bottom drop down. This will give the metric graph everything that it needs to generate graphs on the fly as we click through our resources and metrics.
There you go, you can now see this dashboard coming to shape all properly related and interacting. Here we have chosen a resource. This resource has populated the parents above it. We then can choose a metric for the resource (double click) which then displays the graph below it.
Another very cool thing that was slightly highlighted in the previous examples is around relationships. We demonstrated this capability by setting a “parent” for the health status widget. Let’s add a couple of more useful widgets to the dashboard that should better demonstrate what the relationships. We have added another Health Tree and a Root Cause Ranking widget. The interactions have then been set to be populated by the resources widget.
Here are the new widgets stacked on top of each other. We have selected the management datastore which would show us the immediate parents and children. If you have the EMC relationships or relationships with the resource you are viewing properly configured here (as I don’t) you would see the EMC LUN or NFS export listed below the VMware datastore (management). Below this health tree widget you can see that we are calling out the root causes for any health deterioration of the resource in question.
We are going to add one more health tree widget that allows us to take some pretty interesting views of the relationships. Where we previously were showing relationships based on the resources widget, we now can show relationships based on the actual health tree itself. This allows us to simple click a resource in the health tree which then populates the parent/child relationships in the new health tree.
Here is a view of that if it didn’t make sense when I described it. Here we are looking at the templates resource on the top. We then selected the “win7-basevm” resource which populated its direct parents and children. This would be a view that we would typically get if we double clicked the resource since the health tree itself will drill into whichever object we specify. By adding another health tree we can keep the top view stationary and explore relationships of any resource.
Here is a complete picture of the dashboard that we have created. You can see all of the widgets listed that we configured along with their dimension that was defined vertically per widget and horizontally per dashboard.
Hopefully this information is useful. I wouldn’t expect anyone to specifically use these examples exactly as is. The information presented is more for educational purposes so that you can go off and create your own dashboards!