[Logs UI] Simple Logs component POC

[jasonrhodes]

Drawing from designs mentioned in this ticket and clarified in this comment: #67611 (comment), we will put together a plan for how we would implement this component.

Related: #70513

Requirements so far:

• A list of logs filtered by some time range and some KQL-style filter, e.g. "trace.id:1531151359144"
• Timestamp and message should be present, at a minimum (better: use the user's configured columns from their source configuration)
• Ignore service colored dots from mockup
• No logs streaming required
• No action menu per log line at this time (eventually would add same action menu from logs UI, with view in context, etc)
• Optional button to "View in Logs App" to go to the logs app with the same filters applied
• Reload link for manual refresh of this view (?)

Acceptance Criteria for this ticket:

• A drafted plan that answers these questions:
  • How will this component fetch data? (Data plugin? HTTP? One time or with scrolling/pagination?)
  • How will this component behave if no data is available vs Logs UI is disabled vs user doesn't have permissions on the logs indices?
  • Which parts of the existing Logs UI can be re-used?
  • What work will need to be done to make those existing parts of the Logs UI re-usable?
  • Where will this component live and how will it be accessed by others?
  • What other questions or concerns do we have about this component?

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[afgomez]

Optional button to "View in Logs App" to go to the logs app with the same filters applied

I think the <LogStream /> component should only be the table itself.

For the button I would either export a different component, or a hook/helper function that generates the link and can be used by consumers.

[afgomez]

Timestamp and message should be present, at a minimum (better: use the user's configured columns from their source configuration)

I think the component should allow consumers to specify what columns makes sense for them. Take the APM example: It's important to separate logs from different services (I'm going to assume this lives in event.dataset for the sake of simplicity).

If the kibana user leaves only @timestamp and message as columns, the APM component will have all logs intermixed, confusing the user. I think it's useful to allow APM to force certain columns that they know will be useful in their context.

<LogStream
  ...
  columns={['@timestamp', 'event.dataset', 'message']}
/>

[afgomez]

How will this component fetch data? (Data plugin? HTTP? One time or with scrolling/pagination?)

Data fetching will be done using the existing /entries API. I think pagination is not required for the first iteration.

We will wrap this in a new useLogEntries hook. This hook will live in parallel to the existing one and will serve as a playground to determine how a fresh implementation of the existing hook will look like.

How will this component behave if no data is available?

It will show an EuiEmptyPrompt or similar, saying there are no logs.

...vs Logs UI is disabled

It will render null.

I also think consumers should be responsible of checking if the logs UI is enabled or not (we can provide a helper, or even better, see if Kibana offers a solution already).

In the APM example, they can check if logs is enabled before showing the "Logs" tab in their UI.

...vs user doesn't have permissions on the logs indices?

Same as above.

Which parts of the existing Logs UI can be re-used?

• The /entries API
• The <ScrollableLogTextStreamView /> component, which contains most of the rendering logic. This is the same component used in "View logs in context".

What work will need to be done to make those existing parts of the Logs UI re-usable?

The /entries API needs a new parameter for the columns, if we decide we want to allow consumers or the component to specify what columns they want.

Where will this component live and how will it be accessed by others?

./infra/public

What other questions or concerns do we have about this component?

How should it handle date ranges? Should it only take timestamps or datemath expressions? If that's the case, how should it handle now?

Proposed component API

interface LogStreamProps {
  startTimestamp: number; // Required
  endTimestamp: number; // Required
  center?: TimeKey; // What log entry is centered?
  filter?: string; // KQL expression
  source?: string; // defaults to "default"
  size?: number; // how many log lines. Default delegates to API.
  columns?: string[]; // what fields to show. Default delegates to API.
  paginable?: boolean; // defaults to `false`
}

export const LogStream: React.FC<LogStreamProps> = (props) => {...};

[weltenwort]

@afgomez the discussion in #67611 explicitly mentions using the source configuration as defined in the Logs UI. A deviation for the columns could mean significant changes to the APIs and would make the link back to the Logs UI very difficult (because that uses columns from the source configuration).

The column definitions themselves are also more complex than just the field name.

[afgomez]

A deviation for the columns could mean significant changes to the APIs and would make the link back to the Logs UI very difficult

We can skip it for the first version. I still think there's some value in allowing consumers to specify what columns they want though, so I would like to revisit it in the future.

[afgomez]

I've outlined the possible API and some implementation details in #75650

[jasonrhodes]

Adding some thoughts here as we continue this work:

• I don't think the column configuration that users set up for their Logs UI makes sense to use in other places in the app, so I think/agree that we need to de-couple this shared component from that.
• I think we should always be driving people back to the logs UI when this component is used, so I think default actions of "view in logs UI" and "view in context" would be appropriate to add to each line. Curious why we'd want to let users not do that, since we want to drive new users into the Logs UI as much as possible.