[APM - Design] Individual JVM page drill down design

[nehaduggal]

The current metrics page provides a way to view aggregated JVM performance data for the service along with a Kuery bar to filter to individual instances. This new capability will provide a way to view all reporting JVMs for a particular service with the ability to easily click on any of the instances for metrics related to that instance.

[elasticmachine]

Pinging @elastic/kibana-design

[elasticmachine]

Pinging @elastic/apm-ui

[katrin-freihofner]

@nehaduggal thanks for the description. I'm wondering if you have heared about the local filters: #41588 and if we could use these for our needs to filter for instances. You can also find some visuals here: #34922
Please let me know what you think about this proposal.

[graphaelli]

This sounds reasonable with the caveat that local filters are optional (none selected) but for JVMs an aggregated view probably doesn't make sense, so one should always be selected, or at least selected by default.

[katrin-freihofner]

How would we pick what to filter for? I have another idea, what if we have a view that shows the metrics not aggregated but line charts with the individual instances like this:

As a user I could easily spot any spikes and I could filter the view than for this instance like this:

[nehaduggal]

We discussed using line charts within a single graph but having multiple instances show up on the same chart can get confusing esp when the number of reporting JVMs is a considerable number.

Using Local filters could work with an instance selected(instead of the default none). The only drawback of using the local filters is that it would not provide a quick easy to read overview of all JVMs. Also, we will have to figure out how these local filters would work with the time picker as the list of reporting JVMs could be dynamic. The tabular view of all JVMs would allow that one snapshot view of all reporting JVMs with the ones that are not active but were reporting during the time selected at the bottom of the table.

[katrin-freihofner]

@nehaduggal I agree with you, multiple lines can be confusing. As aggregation does not make any sense in our use case, we should enable our users to spot the spikes/outliers and filter down to these instances. This solution would also work for dynamic JVMs. How many instances do we expect?

[nehaduggal]

Hard to say how many JVMs. It entirely depends on the customer/service/load. Its not out of the norm to see additional JVMs being spun up when the expected number of requests hitting a service goes up to maintain throughput. This spinning up and down of JVMs is pretty common scenario and so its hard to put a number to the number of JVMs. Regardless of what experience we decide to go with, we should consider the experience when someone has 10/20/50 etc JVMs reporting for a service.

[katrin-freihofner]

I made a prototype so we can validate how this might look like

[nehaduggal]

I like the general layout as it is very consistent with the local filters on the other pages. Lets re-label the Host to 'JVM' as a host can potentially have multiple running JVMs. Also, how would the drop down appear if it has 20-25 instances reporting? Would it have a scroll bar? The containerID and pods as drop down local filters don't make sense. This metrics experience is relevant for a single selected JVM instance which is deployed on one single container in a pod. Container ID, Pods and environment information should appear on the page but as absolute selected values below/above the JVM drop down.

[katrin-freihofner]

@nehaduggal exactly, it scrolls. @dgiselaar already worked on the local filters and it turns out great: #41588. And yes, this was just a very quick mock and the filters/labels do not make any sense - I should have pointed that out. I just wanted to see how it behaves. Just let me know which filters we should add as soon as this is going to be implemented. Thank you!

[nehaduggal]

As per our discussion, lets find a placeholder for the container and host information for the JVMs. Other than that it looks good to me!

[katrin-freihofner]

I would propose to add a panel for all the meta data


@nehaduggal is there any useful meta data we should show for the service?