VCF Operations ships with many predefined dashboards and almost nobody uses most of them twice. A dashboard earns its keep when it answers one question for one audience fast. Build a few of those, scope them to groups and applications rather than all objects, and use widget interactions so picking one object updates the rest. Clone a predefined dashboard to start, then cut. The wall of default panels is not a monitoring strategy.
Count how many of the predefined dashboards your team opened in the last month. For most shops the honest answer is two or three, and the rest are scenery. That is not a knock on the product. A general tool ships broad defaults so it can be useful to everyone, which means it is perfectly tuned for no one. The dashboards that get used are the ones somebody built to answer a real question.
So this part is less a tour of panels and more a way of thinking. What makes a dashboard worth keeping open, why scope and interaction matter more than widget count, and which handful you should actually build.
What a dashboard is made of
A dashboard presents a visual overview of the performance and state of objects, and you use it to judge the nature and timeframe of an issue. You build one by adding widgets to a canvas and configuring them, working under Infrastructure Operations then Dashboards and Reports. When you edit, a widget list panel shows the predefined widgets you drag onto the workspace. The widgets do the work: a Metric Chart widget plots the workload of your objects over time, an Object List widget gives you a selectable list, a View widget surfaces a saved view of data that matters to that dashboard audience, and there are many more for alerts, heatmaps, topology and text.
You have three honest starting points: use a predefined dashboard as-is, clone and edit one, or build from scratch. Most good custom dashboards begin as a clone, because the predefined ones already wired widgets together in ways worth learning from.
Why most dashboards go unused
Two mistakes turn a promising dashboard into wallpaper. The first is scope. A dashboard pointed at all objects is slow to load and impossible to read, because it shows you the whole fleet when you almost always care about one cluster, one service or one environment. Scope every dashboard to a custom group or an application object, the constructs from Part 2, and it becomes both faster and legible. The second is interaction. A pile of widgets that do not talk to each other is a static poster. The value comes when selecting an object in one widget drives the others, so you click a host in the Object List and the Metric Chart, alerts and view all refocus on it. That selection-driven behavior is the difference between a dashboard you read and a dashboard you investigate with.
Build for an audience, not for completeness
Here is where I take a side. The instinct is to cram every interesting metric onto one mega-dashboard so nothing is missed. Resist it. A dashboard should answer one question for one audience: is anything wrong right now for the NOC, where is capacity tightening for the capacity owner, is this one service healthy for its app team. Five focused dashboards beat one that tries to be everything, because focus is what makes a glance enough. Completeness is the enemy of a five-second read.
There is a performance argument too, not just a readability one. Every widget on a dashboard runs queries when the page loads, so a sprawling dashboard scoped to the whole fleet is doing real work on your single VCF Operations instance every time anyone opens it. Multiply that by a team that leaves three heavy dashboards open on wall monitors all day and you have turned the monitoring tool into its own load. Tight scope and a short widget list are not only kinder to the reader, they are kinder to the platform. When a dashboard feels sluggish, the fix is almost never a bigger appliance; it is fewer widgets and a narrower scope.
Views and reports
Dashboards are for looking at a screen. Views and reports are for everything else, and they are the part teams underuse most. A view is a saved, reusable presentation of data, a list, a distribution, a trend, a summary, that you define once and then drop into a dashboard through the View widget or schedule inside a report. The advantage is reuse: the same well-built capacity view can appear on the capacity dashboard, feed a monthly PDF to management, and answer an ad hoc question, all without rebuilding it three times.
This matters because the audience for operations data is not only the operator staring at a console. Someone wants a monthly capacity summary in their inbox. An auditor wants a compliance report on a schedule. A manager wants a trend they will never log in to see. Reports exist precisely for the people who will not open VCF Operations, and they are built from the same views you already made for your dashboards. Build the view once, then point both a dashboard widget and a scheduled report at it.
Build the view once, reuse it
The clean mental model is one source feeding two outlets. The view holds the definition of what data and how it is shaped. The dashboard is the live, interactive outlet for people who investigate. The report is the scheduled, pushed outlet for people who just need the answer delivered. When you find yourself building the same table twice, once for a dashboard and once for a report, stop and make it a view. That single habit cuts your maintenance in half and keeps the live screen and the emailed PDF telling the same story, which matters more than it sounds the first time a manager quotes a number that does not match your dashboard.
One caution that follows the scope rule above: a report built on an all-objects view is as unwieldy as a dashboard built the same way. Scope the underlying view to the group or application that the report is about, so the recipient gets a page about their environment rather than a phone book of the entire fleet.
The handful worth building
Rather than browse the catalog, decide by audience. These four cover most real needs, and each maps to a question someone asks under pressure.
| Dashboard | Audience | The question it answers |
|---|---|---|
| At-a-glance health | NOC, on-call | Is anything wrong right now? |
| Capacity and headroom | Capacity owner | Where am I running out, and when? |
| Service health | App team | Is my service healthy end to end? |
| Troubleshooting | Admin in an incident | What changed and where is the cause? |
The at-a-glance one is the dashboard your NOC keeps on the wall, so it should be ruthlessly simple: overall health, active critical alerts, nothing that needs a second look to interpret. The service health dashboard is where application objects pay off, because the health of 40 VMs rolls up into one badge per service. Build these four well before you build a fifth.
Build an at-a-glance health dashboard for one production cluster. Start by cloning a predefined health dashboard so the widget wiring is already sane. Scope it to a custom group that contains only that cluster and its children, not all objects, so it loads fast and reads clean. Keep four widgets: overall health, active critical alerts, an Object List of the hosts, and one Metric Chart. Set the Object List as the driver so selecting a host refocuses the chart and alerts. Then delete everything else the clone brought along. The test is simple: a tired on-call engineer should answer is anything wrong here in five seconds without scrolling. If they cannot, you still have too much on the canvas. Share it to the on-call group and have someone else confirm they can open it.
Common questions
Should I build dashboards from scratch or clone the predefined ones?
Clone, in most cases. The predefined dashboards already wire widgets and interactions together in sensible ways, so cloning gives you a working base to trim. Build from scratch only when nothing close exists.
Why is my dashboard slow or cluttered?
Almost always scope. A dashboard pointed at all objects loads slowly and buries the signal. Scope it to a custom group or application object so it shows only what that audience cares about.
What makes a dashboard interactive instead of static?
Widget interactions. When you configure one widget to drive others, selecting an object updates the whole dashboard. Without that, you have a static display rather than an investigation tool.
Why can my colleague not see the dashboard I built?
It probably has not been shared. New dashboards are private to the creator until shared with a group, so share it and confirm someone else can open it.
What is the difference between a view and a dashboard?
A view is a saved, reusable presentation of data that you can drop into a dashboard through the View widget or use in reports. A dashboard is the canvas that assembles widgets, including view widgets, into one screen.
A habit that keeps a dashboard set healthy over time: put an owner and a purpose in the dashboard name itself, something like Prod Cluster Health (NOC). A nameless dashboard with no owner is the first one to rot, because nobody feels responsible for fixing it when a widget breaks or a scope drifts. Naming the audience also stops the slow creep where one person keeps adding their pet metric until the NOC view is unreadable again. If a request does not fit the named audience, it is a sign you need a new focused dashboard, not another panel bolted onto this one. Reviewing the list once a quarter and deleting the orphans takes ten minutes and is the single cheapest thing you can do to keep people trusting the screens.
Where this leads
A dashboard is worth keeping only if it answers a question fast for a specific audience. My verdict: build four good ones, scope them tight, wire the interactions, share them, and prune the rest. Dashboards tell you something is off, but a dashboard cannot wake you up. The next part is about what pages you when something breaks, alerts, symptoms and definitions, and how to run them without drowning in noise. The two are partners: a good dashboard is where you go after an alert fires, and a tight alert is what sends you to the dashboard in the first place. Build both with the same discipline, name the audience and answer one question, and the platform starts working for you instead of at you.
By the numbers: scope decides load
The same dashboard, pointed at three different scopes.
| Dashboard scope | Objects in view (example) | Load and clarity |
|---|---|---|
| Whole fleet | Thousands of objects | Slow to load, hard to read |
| One cluster | About 8 hosts plus their VMs | Fast and focused |
| Application group | About 40 VMs roll up to 1 health badge | Fast, service-level |
« Previous: Part 3 | VCF 9 Operations Complete Guide | Next: Part 5 »
References
- Dashboards in VCF Operations, VCF 9.0 (Broadcom TechDocs)
- Types of Dashboards, VCF 9.0 (Broadcom TechDocs)
- Using Predefined Dashboards for Quick Insights, VCF 9.0 (Broadcom TechDocs)
About The Author
DrJha