Dashboards & reports

Yagra’s WebUI turns what the pollers collect — liveness, performance, alerts, passive events, and traffic flow — into boards you compose yourself and reports you can hand to someone else. This page covers the dashboard system, the widget catalog behind it, the topology map, the report builder, and the opt-in public dashboard mode.

Dashboards

There are two kinds of dashboard, side by side in the navigation:

• Dashboard ▸ Shared dashboard — one board for the whole team, curated by an administrator. Everyone sees the same layout, so it works as the wall view and the common starting point for a shift: what is down, what is alerting, where the traffic is going.
• Dashboard ▸ My dashboard — personal boards, per user. Each user can keep multiple boards and switch between them, so a network-edge board, a server board, and an events board can coexist without fighting over one layout. Changes here affect nobody else.

A user who has never saved a personal board starts from a representative cross-section of the catalog rather than an empty page, so “My dashboard” is useful before it is customized. From there it diverges however you like.

Both kinds are edited the same way, in Customize mode:

• Add widgets from the catalog (grouped by section, described below) and remove the ones you don’t need.
• Drag and drop to reorder tiles on a snap-aligned, gap-free grid.
• Resize a widget by dragging its corner, and pick a stepped per-widget height for taller content — a long event feed and a compact status ring can share a board without wasted space.
• Cancel discards — edits are not applied until you save, so an experiment can’t wreck the board you present from.

Dashboards work on phones. The board collapses to a single full-width column, tiles reorder by press-and-hold on the move handle (a normal swipe still scrolls), and the edit controls grow to touch-friendly targets. Desktop editing is unchanged.

Widgets update live: current node status arrives incrementally over a stream, and the boards are built to stay responsive at tens of thousands of nodes — rollups are computed server-side rather than by loading the fleet into the browser.

Widgets

The catalog currently holds 46 widgets across eight sections. The exact lineup grows with most releases, so the sections are the stable way to think about it:

Section	What it covers
Fleet health	Fleet-wide status — state summaries, nodes currently down, a fleet health timeline, and the like
Alerting	The alert stream — active alerts, volume and severity mix over time, a flapping watchlist
Performance	Top-N views over live metrics — RTT, CPU, busiest interfaces, and similar
Capacity	Utilization and trend — an interface-utilization heatmap, aggregate throughput, traffic spikes and drops
Passive events	The syslog / SNMP-trap stream — a live event feed, volume and kind mix, noisy sources, rule coverage
Traffic flow	Flow telemetry — top talkers, protocol mix, a conversation Sankey, and more
Sites	Location-oriented rollups — a site matrix, a geo map, a dependency view
Monitoring	Yagra watching itself — poller health, the discovery queue, data coverage

To make that concrete, a few representative widgets:

• Fleet health timeline — the fleet’s state mix over time, so “when did tonight actually start going wrong” has a visual answer.
• Interface heatmap — the busiest links across the fleet at a glance, the capacity view to check before anyone books an upgrade.
• Event feed — the live syslog / trap stream, right on the board.
• Conversation Sankey — who talks to whom, drawn from flow telemetry as a flow diagram.
• Poller health — Yagra watching its own collectors, so a silent monitoring gap shows up on the same board as the outages it would otherwise hide.
• Metric chart and Top nodes by metric — the two escape hatches from the catalog. Every other card answers a question decided in advance; these two take a metric your devices report and ours do not. The first charts any metric of any node, the second ranks the whole fleet by any metric name, by current value or trailing-hour peak.

A few things worth knowing about the catalog:

• The traffic-flow widgets read fleet-wide — every exporter, not one node at a time — so a single board can answer “who is talking, across the whole network” without picking a device first.
• The two any-metric widgets refuse rather than mislead. Metric chart does not offer per-interface metrics (the node’s Interfaces tab charts those per port, and collapsing eight ports to one line answers a different question), and both chart a counter as a per-second rate rather than its stored value — Top nodes by metric refuses to rank a counter at all, since ranking a counter’s stored value ranks how long each node has been up. Top nodes by metric also takes the metric typed, not picked from a list: enumerating every series across every node is the one query that does not survive a large fleet, so the field suggests what this browser has already seen and accepts anything else.
• The passive-event widgets are triage-oriented: the noisy-sources and rule-coverage widgets exist to show you where event volume is coming from and which of it your rules aren’t matching yet.
• Widgets that reference nodes show human names, with the underlying id available on hover — the same convention as everywhere else in the WebUI.
• Charts draw their series colors from the theme’s shared palette, so every widget is legible in both light and dark mode, and a node’s status color is the same in a widget, the node tree, and the topology map.

Topology & dependency map

Topology ▸ Network map draws the fleet as a graph, colored by live status — the same canonical status colors as everywhere else — with drag-pan and wheel zoom on desktop and a two-finger pinch on phones. At fleet scale the map is paged from the server rather than rendered from a full download, so it stays usable when the inventory reaches tens of thousands of nodes.

Topology ▸ Dependencies is the editable half: the parent–child dependency graph that records which devices sit behind which. It is worth maintaining, because it is not just a picture — the dependency graph drives alert suppression. When a parent goes down, alerts from the children behind it are attributed to the parent as the root cause and their own notifications are suppressed, so an access-switch failure pages you once instead of forty times. The map shows suppressed nodes distinctly, so you can see the blast radius of an outage at a glance.

Topology ▸ Geo map answers the other question — where. It draws one pin per node group that has coordinates, on a world outline, coloured by that group’s worst member state, so a multi-site estate reads as a map rather than a list. Set a group’s latitude and longitude in Nodes ▸ the group’s Edit dialog; groups without coordinates simply do not appear. Clicking a pin opens that group in the inventory.

How suppression, root-cause roll-up, and the rest of the alert pipeline behave is covered in Alerting.

Reports

Dashboard ▸ Reports generates documents from the same data the dashboards read — for the people who want a weekly summary rather than a live board.

• A report builder with saved definitions. A report is assembled from sections you pick and order — availability, alert summaries, capacity views, and so on — and saved as a named definition, so the monthly report is defined once and re-run, not rebuilt. Sections carry their own settings (which nodes, which window), and the builder reorders them by drag.
• Three output formats: HTML, CSV, and PDF. HTML for reading in the browser, CSV for feeding a spreadsheet, PDF for attaching to a ticket or mailing to management.
• Schedules. A saved definition can run on a recurring schedule, so recurring reports generate themselves. Finished runs are kept and listed with their state (queued, running, succeeded, failed), and can be re-opened or exported later — a run that finished overnight is waiting in the list, not gone.

One deployment note: PDF rendering shells out to wkhtmltopdf. The container images ship with it, but in a native (from-source) install it must be present on the host — without it, PDF export returns HTTP 503 with the error code pdf_unavailable, while HTML and CSV export keep working.

The report builder works on phones too — tabs scroll sideways and the section settings stack full-width.

Public dashboard mode

Sometimes the right audience for a dashboard is a hallway screen or a team that shouldn’t have accounts — a NOC wall display, a status monitor in the office, a neighboring team that only needs to see. Setting YAGRA_PUBLIC_DASHBOARD=true opens the WebUI’s read views without login: dashboards, node status, alerts, and the other monitoring reads work for anonymous visitors.

The mode is deliberately narrow:

• Reads only. Every write — acknowledging an alert, editing a node, changing any configuration — still requires an authenticated session with the right role.
• The MCP surface stays authenticated. AI clients talking to /mcp always need a token, even with the public dashboard on.
• Alerting configuration stays closed. Reading the threshold rules — a description of when and whom Yagra will page — requires a configuration-level role and is not exposed to anonymous visitors.

The flag defaults to false; see Configuration for where to set it.