[R&D] Logs embeddables: what are your use cases?

[jasonrhodes]

I've heard rumblings of people wanting various logs-related embeddable UI components to drop into other parts of Kibana. What are the use cases for this kind of embeddable? If you have one, please describe it in a comment on this issue so we can collect the various use case requirements and draft a plan for creating the ones that have the best simple to useful ratios.

Please use the following format:

Component Name
Filtered Logs List

Inputs
Date range, field-based filters, results per page (optional)

Output description
List of logs matching the description. Should be paginated if results exceed the optional "results per page" value. Each result should have its own action menu with "view in context" option, and should link back to the logs stream with these filters applied.

Proposed placement?
Metrics UI, on a host view, filtered by host, etc, etc

Thanks!

[elasticmachine]

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

[jasonrhodes]

Here's one case: #67611

[cyrille-leclerc]

Thanks, I'll work with @alex-fedotyev to capture the integrations between APM and logs Alex is looking at for the "APM Service Landing Page".
For the integration between APM Distributed Traces and Logs, I'll iterate with @formgeist .

[sorenlouv]

APM would like to display related log lines for a particular trace (see details here). Log lines will be read from the index already specified in the Log ui settings.

This is our suggested interface for a react component:

<LogStream  
 timestamp="1590690626648" 
 filter={'trace.id:"0570667f4e27e2cac0d6c5b311c65918"'} 
/>

It could also take startTime and endTime instead:

<LogStream  
 startTime="1590690626648" 
 endTime="1590690636648" 
 filter={'trace.id:"0570667f4e27e2cac0d6c5b311c65918"'} 
/>

[drewpost]

Synthetics would like to have

• Logs that contain a specific unique test-run identifier that's passed through for each synthetic run so we can then display them in the "test results" details page in Client Side monitoring and also in the errors details page
• Time filtered view of all logs +/- a configurable window of time
• Log anomalies detected by ML filtered by time and matched in the Client Side monitoring UI to relevant error details pages and test results

Considerations:
Ideally these are stateful - I'm not sure we want them changing out underneath a user.
We also need to figure out how to preserve relevant anomalies and logs to match a "full fidelity" window of data retention in client side monitoring

[weltenwort]

Ideally these are stateful - I'm not sure we want them changing out underneath a user.

@drewpost could you elaborate on that? Which state are you referring to?

[drewpost]

@weltenwort - sorry for the delay, tweaking my mail filters.

What I mean by that is that the logs shown in the error details page in synthetics don't change out underneath the user. Perhaps we take a copy of the relevant log entries? I don't want to get into implementation but from a requirement perspective, I'd like to avoid logs disappearing from the details page if they've been shown there.

I'm happy to tie this to a time window though and we can handle errors outside of this period of retention in the UI.

[weltenwort]

That makes sense, thanks for explaining. I see three options right now to achieve that, most of which you already alluded to:

• Rely on the time filter and ensure the retention of the original log entries is sufficient.
• Copy the relevant log entries to a different index with longer retention and get the logs view to read the entries from there.
• Store the log entries somewhere else and directly pass them to the embeddable as data.

They all have various tradeoffs which we'd have to discuss in detail.

[jasonrhodes]

@drewpost it sounds like this would be good enough for your use case?

Rely on the time filter and ensure the retention of the original log entries is sufficient.

[jasonrhodes]

Synthetics would like to have

Let me see if I understand these correctly by restating them, @drewpost -- correct me where I'm wrong!

• Logs that contain a specific unique test-run identifier that's passed through for each synthetic run so we can then display them in the "test results" details page in Client Side monitoring and also in the errors details page

Logs that match a search string? Would the specified string be its own structured field or is it just embedded in the "message" field somewhere?

• Time filtered view of all logs +/- a configurable window of time

Got it 👍 (I think we'd always need a window of time for this to work)

• Log anomalies detected by ML filtered by time and matched in the Client Side monitoring UI to relevant error details pages and test results

So this is log anomalies that match a certain search criteria? Our log anomalies right now are one of two types: a) log rate, or b) log category ... I think we might be able to search the category types but the rate one won't really make sense, curious to hear more about what type of anomaly you'd like to search and find in a scenario like this.

Thanks!!!

[jasonrhodes]

APM would like to display related log lines for a particular trace

@sqren this looks like a pretty simple case to start out with. Do you think this component should make the API call to the logs API assuming it's there, and then just handle the resulting error accordingly, or would you expect it to know about Logs-related authorization before it even makes the request?

I also just need to think through the best way for this component to get access to the data access API it needs (whether that's core.http, plugins.data, or something else) ... but other than that I think this would be relatively easy.

[sorenlouv]

Do you think this component should make the API call to the logs API assuming it's there, and then just handle the resulting error accordingly,

Yes, I'd expect the component to handle the data fetching

the best way for this component to get access to the data access API

Good point. It might be able to access it from the Kibana React context. I'm also fine with explicitly passing core.http or similar as a prop.

[tbragin]

@nehaduggal FYI

[alexfrancoeur]

Heya, I wanted to share a thought I had when I heard that the logs viewer may be being built to be embeddable in APM. I wonder what the additional work effort could be put in to introducing it as a dashboard embeddable. I'm sure it's non-trivial, but it might be worth exploring a bit further. I can see a ton of value in providing a similar experience that the ML team did with swimlanes. There are a lot of different components I can see being leveraged as embeddable panel to a dashboard, but logs seems like the most universal. We know we have a lot of users who live in their custom dashboards. Adding a logs view next to the metrics and KPI's they are already tracking not only provides additional value to their observability use case, but also a quick path to the logs solution UI to dig in further.

Outside of this, I also see an embedded logs view being helpful in a variety of places. Onboarding / getting data in to preview the data that's streaming in from agent, upgrading processes, something like a security control center - far off future, but Kibana audit logs will be available with support ECS in the next release.

cc: @tbragin

[tbragin]

+1 on understanding whether a Logs viewer should eventually be exposed natively on a Kibana Dashboard. Today, to my knowledge, a user has to "add a saved search" to a Dashboard to display logs in a table format. I'd be curious if we have requests from users to expose logs in a more compact and custom format for logs. cc @AlonaNadler may have some thoughts here in terms of Dashboard priorities.

[AlonaNadler]

In general we do want to allow users a path to create single pane of glass combining their solutions widgets next to their custom charts in a dashboard. We already started that by working with the different teams and adding Maps and ML anomalies into a dashboard which acts like a regular panel.

We are hoping to enhance it in the future and have a toolbar within the dashboard that makes adding solutions even more discoverable

I had several conversations about it with @nehaduggal on adding APM widgets into the dashboard and we have multiple ERs requesting it. At this point from the Kibana app side, the infrastructure is ready. We will be happy to help guide the teams and based on ML it doesn't look like a large task. The first path forward is to put it on your roadmap and start a discussion with @timductive @clintandrewhall and @ThomThomson

[tbragin]

@mukeshelastic @sgrodzicki @weltenwort I'd love your thoughts on the use case around exposing a native action in Kibana Dashboards to add a Logs panel.

[sorenlouv]

Fyi: Created an issue to track and discuss which APM components would be useful as embeddables: #82388

[weltenwort]

With the <LogStream /> component that @afgomez created we're closer than ever to providing something that can be added to a dashboard. I'm not totally certain we already fulfill every requirement needed to implement the Embeddable interface, but a bit of investigation could clarify that.

[jasonrhodes]

I've been thinking about embeddables and drilldowns for a while, logged the following tickets:
#84549
#84550
#84552