Kibana: Evolve the LogStream component to prepare for wider use

[jasonrhodes]

We recently developed a shareable LogStream react component to make displaying logs easier. This is a short list of questions and ideas we should consider before we begin heavily marketing it to other teams for much wider use.

Dependencies

Would it be possible to move this to the "observability" app somehow to avoid the potential for circular dependencies by asking other plugins to depend on the "infra" plugin? (e.g. if ML wanted to use this component we would immediately have some issues)

Composition

Do we need to think about how we break down the individual parts of the stream so that rather than turning things off, we are able to include only the parts we need?

For example, here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/infra/public/components/log_stream/index.tsx#L96-L121

We have a lot of flags with "false" passed in here, and we have a number of noop functions passed in as well. I think we might be able to compose things differently so that the base version is simpler by default, then wrap or add in features/components when we need them. That way, the version we use in the log stream is controlled and extended leaving the base version to be simpler. I think this may help us as we extend functionality in the future.

[elasticmachine]

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

[hbharding]

FYI Fleet may have a need for the LogStream component. We'd like to show Elastic Agent logs on the Agent Detail page in Fleet to helps users diagnose problems. https://github.com/elastic/kibana/issues/77189

[weltenwort]

@hbharding Thanks for the pointer! I suspect you intended to link something different than this issue itself?

[hbharding]

Whoops sorry about that. Just updated my comment above - https://github.com/elastic/kibana/issues/77189 is the correct issue I meant to link to