Skip to content

Instantly share code, notes, and snippets.

@alexgavrushenko

alexgavrushenko/log-ui-improvements.md Secret

Created May 7, 2025 15:02
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save alexgavrushenko/9b3c66d3d19229922b7ff23647cdbc02 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save alexgavrushenko/9b3c66d3d19229922b7ff23647cdbc02 to your computer and use it in GitHub Desktop.
Download ZIP
Logs UI improvements
Raw
log-ui-improvements.md

Key Concepts

  • Log analysis is done not only through queries, but also via visual inspection of results.
  • The interface should allocate screen space in proportion to data importance — for instance, log messages should occupy as much horizontal space in the table as possible.
  • Multiple users may work on the same query result at different time, as a part of a shared process.
  • There are two primary ways to read logs: retrieving information about a known event, and locating an event based on its effects. First method often requires no tools at all.

High-Level Features

Aliasing

When working with multiple tenants or data sources from a single frontend, we encounter problems that degrade experience. For multi-tenant and datasources, it’s often impossible to configure a single universal table view due to field names differences. Additionally, long field names (e.g., from Kubernetes) tend to clutter the UI, causing certain components to waste space without adding value.

Introducing aliases of the form field[] → (alias, description) can significantly improve usability by shortening field names to human-friendly labels while still retaining descriptions for tooltips or help dialogs.

Streams

The _stream includes the full set of labels and is defined at the storage level, but from the user’s perspective a more meaningful abstraction is needed:

A stream (as a label tree) is a semantic unit that defines the context in which events occur. It sets the boundaries of logical relatedness between logs, allowing grouping by module, user, session, etc. In this way, a set of labels acts as a contextual key rather than a purely mechanical filter.

This concept would help with many issues described below.

Components Review

Time Controls

  • Some more controls may be useful — buttons like <<, >>, and zoom out (-).

Query Editor

  • Navigation state is not fully synchronized — the query may need to be resent to avoid misleading shareable links. (It also be nice to have a link sharing and shortener).

  • The current editor is effective for users familiar with the query language. For beginners, it would help to:

    • Add operator hints.
    • Show key names or token suggestions before typing.
    • Provide templates for common use cases.

  • Result limit is a minor control but conflicts with:

    • Dashboard time picker.
    • limit field inside the query.
    • Potential internal service limits.

    This leads to confusion due to unclear source of truth (for results borders). Suggestions:

    • On timeouts or termination (e.g. at the ingress), implement limit backoff and show hints on how to use the limit keyword.
    • If the query time differs from the dashboard time, sync them based on the most recent change.
    • If the result count equals the limit (i.e., the limit is effective), lazily load more data or estimate pagination via a stats query.

  • Improve query error messages with links to documentation or suggested fixes.

  • Query history should include:

    • Timestamps
    • Result counts
    • Ability to rerun queries for the same time range (i.e. history of results)

  • Favorited queries should support optional descriptions.

  • Add support for tail -f — this depends on backend capabilities but can be partially implemented in frontend. It is especially useful in dev environments and some real-time dashboards.

Timeline

  • Zoom-out and horizontal panning are missing (same as in dashboard time controls).
  • Grouping should be configurable — by default, all streams are selected. Users may want to group by log.level, service, etc.
  • Legend templating should be customizable — otherwise it's unreadable with many unique labels.
  • Color palette customization is needed.
  • Add support for displaying events/annotations fetched via separate queries.
  • Near the result stats, add an option to load all results beyond the current limit.
  • Visually indicate and allow adjusting the window of logs that are currently rendered in the table.

Table

  • In grouped mode, use horizontal tabs for groups. Groups should be defined via an editable set of fields not only one particular field, Grouped and flat table views can be merged by using group toggles with "All" option.
  • Add standard for table views column sorting and column resizing. All operations should be available through table header.
  • Add Inline actions such as filtering by column value and selected text.
  • Visually separate logs by group and severity.
  • Sorting by time is the only consistently useful sort. Besides ingest time, support an explicit event time field — especially needed for log line races. Other sorts may apply to group order but use cases are unclear.]
  • Compact view should also compact some fields in table or even columns with one common value to give more space to message text.
  • Feature: Context:
    • When filters are active, allow viewing surrounding log lines by temporarily relaxing some filters — shown either inline or in a modal.
  • Feature: JSON tree view:
    • For structured logs, show the message and render other fields as a collapsible JSON tree.
    • Useful for inspecting large serialized payloads like config dumps or parsed service messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment