In part 1 of this new series on building great dashboards with vRealize Operations I explained the difference between vRealize Operations and vRealize Operations Cloud. I also provided an overview of the dashboarding capability in vRealize Operations Cloud and I discussed some important questions you should ask yourself before you start building a vRops dashboard.

In this article, part 2 of this series, we will have a first look at the dashboard canvas, the available widgets and views, and we will get some basic understanding on how to configure a widget.

The dashboard creation canvas allows you to:

• Set a name for your dashboard;
• Cancel and/or save your dashboard;
• Copy/paste a widget;
• Configure interactions between widgets and/or views within the same dashboard, or configure interactions between widgets and/or views on other dashboards;
• Drag and drop widget and views on the dashboard and configure them.

Widgets, views, objects, metrics, properties and alerts

A vRealize Operations Cloud dashboard is actually a collection of widgets and/or views with optional interactions to display the information you need:

• A widget is a pane on your dashboard and displays information about objects, metrics, attributes and processes in your environment. Currently there are 44 different widgets available. Widgets can interact with each other through the interaction option, and can send or receive data.
• A view is also a pane on our dashboard and helps you to interpret the metrics, properties and/or policies. There are very powerful views available that help you to list and summarize information. You can also use views to do trend calculations and show how objects and/or properties are distributed across the environment. You can also use views to display plain text or add an image to your dashboard.

About objects, metrics, properties and alerts

Widgets and views are built around the available objects in vRealize Operations and their related metrics, properties and alert. An object in vRealize Operations is (for example) a Datacenter, Cluster, ESXi hosts or virtual machine. A metric is an operational performance value that vRealize Operations collects (normally every 5 minutes), a property is a static value that describe a specific property of an object. An alert is a state that is triggered based on the alert definition. To get on an overview of the available metrics and properties including corresponding values for a specific object you can navigate to the metrics tab of a specific object:

Maybe you’ve also heard about super metrics, this is special type of metric that will be discussed in a future article.

With the available widgets you can cover a lot of different use-cases, some examples are:

• Use an object list, metric picker and metric chart widget to display detailed information on how a specific object (datacenter, cluster, ESXi host, virtual machine, datastore etc.) is performing;
• Use the scoreboard, scoreboard health, heatmap or health chart widget to get overview information on how objects are doing in terms of performance, capacity or health;
• Object relationship widgets help you to show the relationship between objects;
• There are also widget around specific vRealize Operations metrics with the Health, Workload, Anomalies, Faults, Risk, Time Remaining, Capacity Remaining and Efficiency widget.

Of course you can combine available widgets and views in one dashboard at your own discretion.

Basic widget configuration

After dragging a widget on the canvas, you have to do some basic configuration available via the pencil icon available on each widget. Of course things depend on the selected widget, but you will (almost) always see something like this to start with:

The first two options determine if the content of the widget should be automatically refreshed and how often this should happen. By default the refresh interval is 300 seconds (=5 minutes), usually it makes no sense to change this value because vRealize Operations and vRealize Operations Cloud collect new data every 5 minutes.

Depending on what you want you can set a widget as a “Self Provider” or not. If a widget is a Self Provider, the widget is showing information itself and not the target of any interaction. If the widget is used as a target in an interaction, self provider should be turned off.

Some of the widget show the following additional configuration categories:

• Input Data – The input data option is only available if the widget is a self-provider and allows you to add specific objects to the widget. The objects you add here are the only objects that are available in the widget. By default “all” is selected here, which will select all objects (duh). It’s always possible to filter the list of objects using the Output Filter option.
• Input Transformation – Input transformation determines if you want to show the objects themselves (Self), the parent or child objects. You can also select the Depth if you want to show parent or child objects.
• Output Filter – Output filter is used to make a subselection of the available objects based on a broad range of available filters. Filter types are for example object type, a specific (custom) datacenter, based on a location, collection state or recently added objects. You can create basic and advanced filters, advanced filters allows you to combine different filter options (read on to learn how this exactly works).

Object list widget – an example configuration

To make things a bit more concrete let’s configure an object list widget and see what happens.

Drag an object list widget to the canvas and open the “edit widget” option. Configure a name, enable refresh content and keep the default value of 300 seconds. We will make this a self provider widget and we will also auto select the first row.

We will NOT select a list of object but instead show all available objects. However, we will make a selection of objects using a Output Filter in het next step. The Input Data option will look like this:

The Output Filter offers basic filtering and advanced filtering. With a basic filter note that if you select more than one filter tags, the widget includes objects that have any of the tags applied. You can use the advanced filter to do additional filtering on the objects selected by the basic filter. Please note the following important statement (coming from the manual):

If the objects have a tag filter applied in the Basic subsection, you define filter criteria for the object types of the objects with tag filter applied. If the objects with tag filter applied do not belong to any of the object types in this filter criteria, the widget skips this filter and includes all the objects with tag filter applied.

This means if you haven’t select a specific object type in the basic filter, all objects type will be included in your advanced filter.

So, select (for example) virtual machine as an object type in the basic filter:

And now create an advanced filter to create an additional selection:

In this example I’m selecting all the virtual machines that are descendant of a specific vCenter Server.

Note the difference between Child of or Descendant of. A child object has a direct relationship with its parent object, while a descendant doesn’t need this direct relationship. In this example is a virtual machine not a child of a vCenter Server, but it’s a descendant. A typical child (and also descendant) of a vCenter Server is a Datacenter object because is directly under the vCenter Server in the navigation tree.

The last option to configure in this widget is Additional Columns, which allows you to add extra columns to the default columns that are available in the widget. In this example I want to show the vCenter Server in the that is managing a virtual machine. This can be achieved through adding the Parent vCenter property of a virtual machine.

No it’s time to save our widget that will show all the virtual machines that are descendant of a specific vCenter Server, and will also show this vCenter Server name in the list:

Unfortunately I had to blur some of the information that is displayed in the widget, but you will get the point.

That’s it for now, in part 3 of this series we will further expand our dashboard, add additional widgets and define some interactions. Stay tuned if you want to learn more!