Context
PR #2826 adds RED metrics (Throughput, Errors, Duration) to the trace search results view. Each tile is a chart card built from the same base config the search histogram uses, so the aggregations already honor the active WHERE filter and the selected time range.
Dashboard tiles elsewhere in the app offer an action to save a chart to a dashboard. The trace search RED tiles do not, so a user who spots something in one of these charts has to rebuild the same aggregation by hand in a dashboard or in the chart explorer.
Proposal
Offer an "add to dashboard" action on each RED tile that carries the tile's config (select, display type, number format, granularity) plus the active search filter, so the saved tile matches what the user was looking at.
The configs are already pure builders in packages/app/src/components/Search/traceRedMetrics.ts, which is what a save action would serialize.
Notes
Worth checking what the heatmap view should do here as well, since it is the same switch on the same area.
Context
PR #2826 adds RED metrics (Throughput, Errors, Duration) to the trace search results view. Each tile is a chart card built from the same base config the search histogram uses, so the aggregations already honor the active WHERE filter and the selected time range.
Dashboard tiles elsewhere in the app offer an action to save a chart to a dashboard. The trace search RED tiles do not, so a user who spots something in one of these charts has to rebuild the same aggregation by hand in a dashboard or in the chart explorer.
Proposal
Offer an "add to dashboard" action on each RED tile that carries the tile's config (select, display type, number format, granularity) plus the active search filter, so the saved tile matches what the user was looking at.
The configs are already pure builders in
packages/app/src/components/Search/traceRedMetrics.ts, which is what a save action would serialize.Notes
Worth checking what the heatmap view should do here as well, since it is the same switch on the same area.