Arkime Tab v2

Overview

The current Arkime Dashboard tab provides a fixed set of visualizations. To increase utility and flexibility, this proposal shifts toward a modular, widget-based dashboard. Users should be able to build a customized workspace by adding, configuring, and arranging various visualization elements (graphs, maps, SPI data) that persist across sessions.

Core Objectives

• Flexibility: Move from a "one-size-fits-all" view to a customizable layout.
• Granularity: Shift configurations (limits, fields, types) from the global header to individual widgets.
• Efficiency: Allow saved expressions per widget to enable multi-layered analysis in a single view and only ask for the fields selected to improve aggregation time

---

Functional Requirements

1. Modular Widget System

Users should be able to add multiple types of elements to their dashboard. Each element is an independent "Widget."

• Widget Types: Support for all existing Arkime visualizations:
  • Timeline/Current Graphs
  • SPI Graphs (Tree, Matrix, Donut, ...)
  • Map Views
• Per-Widget Configuration: Each widget should feature an Edit Button to configure:
  • Field Selection: (e.g., srcIp, host.name, protocols).
  • Metric Basis: (e.g., Sessions, Packets, Bytes, or Lookups).
  • Data Limit: Number of items to display (e.g., Top/Bottom 10, 20, 50).
  • Local Filtering: Ability to save a specific Search Expression or View per widget. This filter is applied on top of the global session search.

2. Layout and Grid UI

To keep the dashboard organized, the UI should follow a structured grid system:

• Column Control: Toggle between a 2-column or 3-column layout.
• Sizing: Widgets should have a fixed width based on the column count. Height should be configurable (e.g., Standard or Double Height). Maybe support double width?
• Internal Scrolling: To prevent the page from becoming excessively long, widgets should have internal scroll bars for high-density data (e.g., showing 50 bar chart items).

3. Persistence and Management

• Saved Dashboards: Users can save the entire configuration (layout + widget settings) as a "Saved Summary."
• Default Dashboard: Option to set a specific saved dashboard as the default landing page for the tab.
• Searchable Selector: The dashboard selector should include a search bar and the top X number of used dashboards.

---

Example Scenario

A user creates a "Security Operations" dashboard with the following widgets:

1. Widget 1 (Bar Chart): Field: srcIp | Top 50 | Metric: Sessions.
2. Widget 2 (Matrix Graph): Field: host.name | Top 20 | Metric: Packets.
3. Widget 3 (Map): Focused on destination countries with a local expression protocols == "tls".

---

Technical Considerations

• Global vs. Local: The global search bar still drives the primary data set, but widget-level expressions act as sub-filters.
• Portability: Dashboard configurations should be exportable/importable via JSON to facilitate sharing across clusters.