Owner: @AndresTK89
One groundwork task plus one task per integration in the v12 catalog, all listed below as sub-issues and all assigned to Andres.
What we want
Every integration gets a simple built-in dashboard that answers four questions at a glance: how much is this technology sending, is it still sending, what kinds of events are they, and which ones deserve a look. The core of each dashboard is the technology's logs grouped by event type (the log's title or subject). Click one and the Log Explorer opens on exactly those logs.
How v12 dashboards work, in short
- Built-in dashboards are YAML files in
definitions/dashboards/. The backend loads them at every start (backend/modules/dashboards/repository/dashboard_bootstrap.go) and the image copies the folder to /utmstack/dashboards. Built-in widgets are replaced on each start; a built-in dashboard a user removed stays removed.
- Only one ships today,
definitions/dashboards/agents-overview.yaml. Copy its style.
- A widget is a query (
spec), a chart type (config.__builder.chartType) and a position (layout). A query is one of four shapes (backend/modules/dashboards/domain/spec.go): metric (one count), category (top values of a field), time (count over time, optionally one line per value of a field) and table (latest records).
- Logs are stored in ClickHouse (
installer/docker/clickhouse-schema.sql). Fixed columns include dataType, dataSource, action, actionResult, severity and protocol. Everything else is a nested path under log, origin or target (for example log.eventCode, origin.ip), and any path a parser writes can be grouped or filtered.
- Count is the only measure. There are no sums (so no byte totals), averages or unique counts.
Standard layout for every dashboard (12-column grid)
| # |
Position (x, y, w, h) |
Widget |
| W1 |
0, 0, 3, 2 |
Total logs (number) |
| W2 |
3, 0, 3, 2 |
Integration-specific number, for example failed logons or denied connections |
| W3 |
6, 0, 3, 2 |
Second integration-specific number |
| W4 |
9, 0, 3, 2 |
Alerts from this integration (number) |
| W5 |
0, 2, 8, 4 |
Log volume over time (area) |
| W6 |
8, 2, 4, 4 |
Logs by device, host or account (dataSource, bar) |
| W7 |
0, 6, 6, 6 |
Top event types: logs grouped by title or subject (value and count table, the main way into the logs) |
| W8 |
6, 6, 6, 6 |
Top 5 event types over time (line) |
| W9 onward |
from y = 12 |
Two to five breakdowns that matter for this technology (users, addresses, ports, countries, rules, threats, applications) |
| near last |
|
Alerts by rule, and alerts by severity (bars) |
| last |
full width |
Latest logs (table) |
Each sub-issue fills in the integration-specific slots with fields taken from that integration's parser, says where each field comes from, lists what to watch out for, and includes a starting YAML file that already passes the backend's own checks.
Order
#2697 first, since it adds the click-through that every dashboard needs. Then the dashboards, in the order listed below (most widely used integrations first).
Field names are about to move
Since 24 Sep 2026 the event engine keeps underscores in field names (go-sdk v1.1.35, threatwinds/EventProcessor commit e6d9bd307e). Before, it removed them, so a vendor key like fw_action was stored as log.fwaction, and the parsers were written around that. The v11 parsers were updated for the change the same day (commit 06e2746 on v11); the v12 parsers in definitions/filters/ have not been yet. Several more parser fixes are open against v11 right now and will likely be carried over to v12.
What that means here:
- Fields the parser names itself (the target of a
rename, an add key, a grok field name) keep their names, as long as the parser's rename still finds its source.
- Raw vendor keys that contain an underscore will change name, and renames written for the old names will stop finding them until that parser is updated.
- Each sub-issue says which of its fields are affected when we know. In every case: when you start a dashboard, check its fields against the v12 parser at that moment and against real logs, and build against what you find. The field lists in the sub-issues are the intent, not a contract.
Rules for every dashboard
Owner: @AndresTK89
One groundwork task plus one task per integration in the v12 catalog, all listed below as sub-issues and all assigned to Andres.
What we want
Every integration gets a simple built-in dashboard that answers four questions at a glance: how much is this technology sending, is it still sending, what kinds of events are they, and which ones deserve a look. The core of each dashboard is the technology's logs grouped by event type (the log's title or subject). Click one and the Log Explorer opens on exactly those logs.
How v12 dashboards work, in short
definitions/dashboards/. The backend loads them at every start (backend/modules/dashboards/repository/dashboard_bootstrap.go) and the image copies the folder to/utmstack/dashboards. Built-in widgets are replaced on each start; a built-in dashboard a user removed stays removed.definitions/dashboards/agents-overview.yaml. Copy its style.spec), a chart type (config.__builder.chartType) and a position (layout). A query is one of four shapes (backend/modules/dashboards/domain/spec.go):metric(one count),category(top values of a field),time(count over time, optionally one line per value of a field) andtable(latest records).installer/docker/clickhouse-schema.sql). Fixed columns includedataType,dataSource,action,actionResult,severityandprotocol. Everything else is a nested path underlog,originortarget(for examplelog.eventCode,origin.ip), and any path a parser writes can be grouped or filtered.Standard layout for every dashboard (12-column grid)
dataSource, bar)Each sub-issue fills in the integration-specific slots with fields taken from that integration's parser, says where each field comes from, lists what to watch out for, and includes a starting YAML file that already passes the backend's own checks.
Order
#2697 first, since it adds the click-through that every dashboard needs. Then the dashboards, in the order listed below (most widely used integrations first).
Field names are about to move
Since 24 Sep 2026 the event engine keeps underscores in field names (go-sdk v1.1.35,
threatwinds/EventProcessorcommit e6d9bd307e). Before, it removed them, so a vendor key likefw_actionwas stored aslog.fwaction, and the parsers were written around that. The v11 parsers were updated for the change the same day (commit 06e2746 onv11); the v12 parsers indefinitions/filters/have not been yet. Several more parser fixes are open againstv11right now and will likely be carried over to v12.What that means here:
rename, anaddkey, agrokfield name) keep their names, as long as the parser's rename still finds its source.Rules for every dashboard
definitions/filters/. Check each widget against real logs before shipping; a widget that stays empty while logs arrive means the field is wrong.log.*,origin.*,target.*) within, even for one value. See v12 dashboards: groundwork for integration dashboards (click-through to the Log Explorer, value/count table, Agents dashboard fix) #2697.