Key Concepts

• Log analysis is performed not only through queries but also through visual inspection of the results.
• The UI should allocate screen real estate in proportion to data importance — for instance, log messages deserve as much horizontal space in the table as possible.
• Several users may inspect the same query result at different moments as part of a shared workflow.
• There are two principal ways to read logs: (1) retrieving information about a known event and (2) locating an event by investigating its effects. The first method often needs no tooling at all.

---

High‑Level Features

Aliasing

When a single frontend services multiple tenants or data sources, differences in field names make a universal table layout impossible. Very long field names (e.g. from Kubernetes) also bloat the UI and waste space.

Introducing aliases of the form field[] → (alias, description) would shorten headers to human‑friendly labels while keeping the full description for tooltips or help dialogs.

Note

The idea is sound, but it partially duplicates the behaviour of the | rename pipe.

Streams

The storage layer already exposes a technical _stream label that contains all labels, but users need a higher‑level abstraction:

A stream (as a label tree) is a semantic unit that defines the context in which events happen. It sets logical boundaries for grouping logs by module, user, session, and so on. A label set therefore becomes a contextual key rather than a raw filter.

Note

Sounds good — could be implemented as a separate tab.

---

Components Review

Time Controls

• Extra controls such as <<, >>, or a dedicated zoom‑out (−) button were proposed.

Note

Zooming already works via the mouse wheel and + / − keys, so extra buttons feel redundant.

---

Query Editor

• Navigation state is not fully synchronised — a query sometimes has to be resent to get a shareable URL. A link shortener would also help.

Note

Agreed — the state really is out of sync.

• On‑boarding for beginners. For users unfamiliar with the query language it would help to:

  • show operator hints,

  • offer key‑name or token suggestions before typing, and

  • provide templates for common tasks.

Note

All useful, but a large effort. We could reuse the query builder from the VictoriaLogs datasource plugin.

• Result limits clash with three other places:

  1. the dashboard time picker,
  2. an explicit limit inside the query, and
  3. internal service limits.

  This makes it unclear which component actually caps the results. Suggested mitigations:

  • On timeout/termination (e.g. at ingress), fall back to a lower limit and show hints on using limit correctly.

  • If the query’s time range differs from the dashboard range, automatically synchronise them based on the last change.

  • When the number of returned rows equals the limit (i.e. the cap is active), lazily load more rows or estimate pagination via a stats query.

Note

• Dashboard vs. limits — the dashboard itself never sets limits, so the first conflict is unclear.
• limit in query vs. internal limits — all limits are already enforced by victorialogs. Better show a tooltip explaining how limit is interpreted when present both in a pipe and in query params.
• Timeout ≠ limit — a timeout may have nothing to do with limits; that distinction should come from the error returned by victorialogs.
• Time‑range sync would complicate the code and may confuse users. A common pattern is to refine the UI range with _time: in the query (e.g. UI = 01–02 May 2025, query has _time:13h → logs from 02 May 2025 minus 13 hours). Instead of auto‑changing either value, show a hint that the ranges differ.
• Pagination when the limit fires is a good idea, but only feasible after introducing sorting with | sort, which slows queries.

• Better error messages with links to docs and suggested fixes.

Note

Fully agree.

• Query history should store timestamps, result counts and allow re‑running the same query for the same period.

Note

Possible, though it is unclear how many users rely on history.

• Favourites should allow optional descriptions.

Note

Reasonable addition.

• tail‑f support — very useful in dev and near‑real‑time dashboards.

Note

Already implemented — see VictoriaMetrics #7046.

---

Timeline

• Missing zoom‑out and horizontal panning (mirrors time controls on dashboards).

Note

Already implemented. Just needs a usage hint, which can be taken from vmui.

• Grouping should be configurable — by default all streams are combined, but users might prefer grouping by log.level, service, etc.

Note

Tracked in issue #7365.

• Legend templating should be customisable; otherwise it is unreadable with too many unique labels.

Note

Agreed.

• Need a colour‑palette picker.

Note

Not sure about real‑world use cases — what problem does it solve?

• Show events/annotations coming from separate queries.

Note

Would require an extra backend and duplicates Grafana functionality.

• Next to the result stats, offer Load All to fetch beyond the current limit.

Note

• For hits the stats already ignore limits; only the top 5 values are capped (rest collapses into other).
• For records the user can simply raise limit; same mechanism.

• Visually indicate and allow adjusting the window of logs that are currently rendered in the table.

Note

Not entirely clear what “window” is meant here.

---

Table

• In grouped view, use horizontal tabs for groups. Groups should be defined by an editable set of fields, not just one. Flat and grouped views could be merged by adding a group toggle with an All option.

Note

Considered tabs, but long group names (several concatenated fields) may not fit. Grouping by multiple fields is certainly desirable.

• Provide column sorting and resizing via the table header.

Note

Sorting exists; column resizing makes sense.

• Add inline actions like Filter by this value or Filter by selected text.

Note

Thought about it, but the same can be achieved by editing the query; unsure how often it is needed.

• Visually separate logs by group and severity.

Note

Implemented in the datasource plugin; propose bringing the same visuals into the UI — see datasource #294.

• Time is the only consistently useful sort. Besides ingestion time, allow sorting by an explicit event‑time field to handle log races. Other sorts might order groups, but concrete use cases are vague.

Note

1. You can already sort in a query via | sort.
2. The table header supports sorting by any column.
3. There is a PR that adds nested JSON sorting: #8745.

• Compact view should collapse columns with a single repeated value and free horizontal space for the message text.

Note

The compact view was removed (inherited from vmui but not useful for logs) — see #7047.

• Context feature — when filters are active, allow showing neighbouring log lines by temporarily relaxing some filters, either inline or in a modal.

Note

Tracked in issue #7063.

• JSON tree view for structured logs: display the message field and render the remaining fields as a collapsible tree. Very handy for large payloads such as config dumps or decoded service messages.

Note

Being discussed in #9011 and #7047.