Goal

The goal of this spike is to establish the set of features we want in the logging view, and plan the order of implementation. We should aim for a simple view quickly and then iterate to add features.

Ideas

The following are initial ideas for features in the logging view, all open to discussion as part of this spike.

Definitions

Log record: a JSON log record including the original log text a "message" field, or the original log JSON object in the "structured" field if the logs were parsed as JSON.

Log query: Need to define exactly but it will to identify at least:

• a set of containers to retrieve logs from
• a time range of interest.
• (optional) filters to reduce the logs - these could be part of a query, or applied within the UI.

View elements:

Columns: sort by, select visible.

• Default columns such as: time, severity,message
• Column set could be static (logging data model) or dynamic (inferred from log records)

Header/footer: display information that is common to all log records once, not as a column in every record. E.g.

• Logs from single container: headers [namespace, pod, container], columns [timestamp, message]
• Logs from single pod: headers [namespace, pod], columns [timestamp, message, container]
• Logs from many sources: columns [timestamp, message, namespace, pod container]

Filter by columns:

• substring/regexp match on message and other string fields?
• time: time range match
• drop down menu for enumerated fields? (e.g. severity)
• labels: match label expressions? what do we do elsewhere?
• completion for fields with set values - namespace, pod etc. (what do we do elsewhere)

Logs from multiple containers in single view:

• interleaved by time.
• reduce column clutter by color coding logs from distinct containers? (see metric views)

Side-by-side time-correlated view

• Logs with same timestamp from multiple log sets.

Links to related console pages

• namespace/pod/container labels
• others…

Future flexibility.

This spike is to establish initial capabilities for the logging view.

More elaborate correlations with other signal types will be the subject of future work. The logging view should be flexible, in future it may incorporating new links, be embedded in views with other console components etc.