11.2 Dashboards, Custom Views, Metrics & Reports
Key Takeaways
Dashboards combine visualizations and provider/receiver interactions for an operational question.
A receiver needs the correct object input and supported metric type.
Dashboard sharing and underlying inventory permissions are separate.
Verify units, timestamps, selection changes and dependent Views with the intended viewer role.
11.2 Dashboards, Custom Views, Metrics & Reports
Visual analytics in VCF Operations transforms raw metric streams into actionable administrative workflows. By organizing infrastructure data into structured Dashboards, Views, and Reports, administrators can triage performance anomalies, evaluate environmental health, and present capacity forecasts to executive stakeholders through a centralized web console.
Out-of-the-Box (OOTB) Dashboards & Tactical Troubleshooting
VCF Operations includes dozens of pre-configured, curated dashboards for common Day 2 administrative workflows. The examples of operational dashboard use cases include:
-
Troubleshoot a Cluster: Provides holistic visibility into compute cluster health. Displays real-time CPU and memory contention, ESXi host workload balance, DRS migration activity, hardware alerts, and localized network drop rates across all hosts within a selected vSphere cluster.
-
Troubleshoot a VM: An end-to-end diagnostic workbench for individual virtual machines. Visualizes guest OS workload pressure alongside underlying infrastructure dependencies. Correlates guest CPU ready time (
%RDY) and memory ballooning with physical ESXi host contention, storage datastore read/write latency, and virtual switch packet discards. -
Heavy Hitters: Identifies the top resource-consuming entities across the entire inventory. Ranks objects across multiple dimensions: top 10 virtual machines by CPU consumption, highest memory demanders, virtual disks generating the greatest storage IOPS, and interfaces with the highest network throughput.
-
Capacity Overview: Delivers high-level operational intelligence regarding resource runway. Summarizes total compute, memory, and storage capacity across datacenters, highlighting clusters nearing resource exhaustion and quantifying reclamation savings from idle or powered-off workloads.
Custom Dashboard Construction & Widget-to-Widget Interactions
While OOTB dashboards satisfy broad administrative requirements, custom dashboards allow organizations to tailor visual analytics to specific application tiers, operational teams, or tenant groups.
The Widget Palette
Dashboards are constructed on a flexible grid canvas using modular visual components called Widgets:
- Object List: Displays inventory entities (clusters, hosts, VMs) in a searchable tabular grid.
- Metric Chart: Renders historical time-series graphs for selected metrics over custom time ranges.
- Health Chart & Scoreboard: Displays aggregated health scores and numeric key performance indicators (KPIs) with colored thresholds.
- Heat Map: Visualizes large object populations across two concurrent metric dimensions.
- Top-N Graph: Dynamically lists the top or bottom performers for a given metric.
- Alert List: Filters active operational alerts affecting specific object groups.
Widget Interaction Mechanics: Self-Provider vs. Input Listening
A common exam objective evaluates how widgets communicate within a dashboard. Widgets operate under two primary data provision modes:
- Self-Provider (Enabled): The widget independently selects and queries its own objects. For example, a Top-N widget configured as a Self-Provider independently queries the entire vCenter inventory to list the top 10 VMs by CPU usage without external interaction.
- Input Listening / Driven (Self-Provider Disabled): When Self-Provider is set to No, the widget requires an upstream object provider. Administrators configure Widget Interactions by drawing a relationship from a source widget (e.g., an Object List) to a destination widget (e.g., a Metric Chart).
In this master-detail workflow, selecting esxi-prod-01.corp in the Object List automatically drives both the Metric Chart (displaying host contention) and the Heat Map (displaying all child VMs on that specific host).
Designing a Dashboard for Its Audience
Start from an operational question, such as "which production VMs on the selected host are contending for CPU?" An inventory selector supplies the host, a related-object widget supplies its VMs and metric charts show demand and contention over the same window. Configure the object relationships and input/output interactions; merely placing widgets side by side does not connect them.
Test with at least two hosts and an empty selection. If every selection shows the same VM list, inspect the receiver's input and self-provider setting. If a widget has no data, check that the selected object type actually exposes the requested metric and that the collection time window has data. A missing metric is not the numerical value zero.
Share and Verify Access
Save the dashboard, then configure sharing for the intended users/groups under the installed release's dashboard-management controls. Dashboard sharing and access to underlying inventory are separate. A viewer must have the required role and object scope; making a dashboard visible does not authorize an otherwise restricted tenant to see every object in the provider's account.
Review embedded object selections, custom groups, metric configuration and any dependent Views before export/import or sharing. Test with the intended viewer role, not only the creator's Administrator session. Verify that provider/listener behavior and time ranges remain useful and that sensitive object names or properties are not exposed to an unintended audience.
Use a small set of widgets answering related questions. A heat map's area and color can encode different measures, but label both units. A large red tile is an invitation to inspect data, not proof of an application's root cause. Include a metric chart and alert context so the viewer can distinguish a persistent fault from a brief expected batch peak.
Reusable Views and Metrics
A View defines reusable presentation/query choices; a dashboard is an interactive workspace, and a report is a generated deliverable. The dedicated views/reports section teaches their creation and scheduling. Likewise, the telemetry section distinguishes metrics, properties and logs without tying each category to an invented internal database.
For a final dashboard test, select a known object, verify the unit and freshness of its metrics against that object's detail page, change the selection, and confirm receiver updates. Save the intended default time range and document the purpose of each widget. This makes the dashboard repeatable for the next operator instead of a one-off arrangement tied to the author's browser state.
Official Reading
Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.
Review Takeaways
- Dashboards combine visualizations and provider/receiver interactions for an operational question.
- A receiver needs the correct object input and supported metric type.
- Dashboard sharing and underlying inventory permissions are separate.
- Verify units, timestamps, selection changes and dependent Views with the intended viewer role.
An administrator is configuring a custom alert policy and needs to distinguish between object telemetry types in VCF Operations. Which of the following is classified as a Property rather than a Metric?
Virtual machine hardware version and guest operating system name
Virtual machine CPU ready percentage (%RDY)
Datastore write latency in milliseconds
Virtual machine guest memory demand in megabytes
In a VCF Operations Heat Map widget configured to visualize virtual machine health across an ESXi cluster, how are the two primary metric dimensions visually represented?
Box position on the X/Y Cartesian grid represents IOPS, while the border thickness indicates CPU utilization.
Box shape (circle vs square) represents operating system type, while animated blinking indicates alert severity.
Tile height represents memory demand, while tile width represents storage capacity.
Tile size represents one metric (such as memory provisioned), while tile color represents another metric (such as CPU contention percentage).
An administrator wants to build an interactive custom dashboard where selecting an ESXi host from an inventory grid automatically updates an adjacent chart displaying that host's CPU and memory contention over the past 24 hours. How must the widgets be configured to achieve this behavior?
Both widgets must have Self-Provider enabled and be bound to the same Cassandra metric rollup schedule.
The inventory grid widget must act as the provider while the chart widget is configured to accept input from the grid as its driven listener.
A dedicated Cloud Proxy must be configured to mirror telemetry streams simultaneously to both independent widgets.
The chart widget must be configured with an automated JavaScript callback that polls the REST API for inventory selection changes.
Sections you finish are checked off in the contents.