[APM] Service overview [META]

[formgeist]

Summary

Related design issue elastic/apm#300

The service overview introduces a new view for the selected service that encompasses a lot of the service data from existing views like metrics, transactions, and errors. The primary goal of the view is to aid in troubleshooting a given service from a birds-eye view rather than immediately diving into the Transactions, as that's the current landing page for a selected service. There's more information about the user stories and goals of the view in the design issue linked above.

Implementation tasks

Outside the layout implementation, we have open issues for the dependencies table and the time range comparison.

---

Updated header

The main header will be updated to make it consistent with the other Observability apps.

Apart from the re-arrangements, we'll be adding new icons at the top to indicate the service agent, container, and cloud metadata.

🖼 View screens

Service

• Service version
• Runtime name & version
• Framework name
• Agent name & version

Container

• OS
• Containerized
• Average number of instances
• Orchestration

Cloud

• Cloud provider
• Availability zone(s)
• Machine type(s)
• Project ID

---

Latency visualizations and events timeline

The time range comparison will be handled in another issue, but the general idea behind the Latency (previously Transaction duration) chart is to contain the event annotations such as deployments, alerts, and anomalies. These events will not be duplicated in any of the other charts, which is why this is designed to be 100% width of the view at the top of the page as well.

Additionally, there's an option to change the primary time-series to another percentile. It will default to average, but will also have options for 95th and 99th percentiles. This will change the related latency metrics on the rest of the page as well to keep it consistent with the main latency chart.

🖼 View screens

---

Traffic & transactions table

The traffic chart consists of the average transaction per minute without grouping by status code as it's done in the Transactions view.

The transactions table will add sparklines per metric and have room for comparison data as well.

🖼 View screens

---

Errors

The error rate chart and errors table will be close to what we know today from the Errors view aside from the comparisons and sparklines. Additionally the first and last seen relative timestamps were already presented as part of an Errors table redesign, but we'd like to implement this as part of the overview experience first.

🖼 View screens

---

Span type breakdown & dependencies table

The span type breakdown chart will be updated to no longer be percentage but take duration as the y-axis and allow for each span type to show its average duration in a stacked area chart.

The dependencies table is already documented separately in this open issue

🖼 View screens

---

Instances

The instances scatterplot visualization is considered a stretch goal seeing as the Elastic Charts feature is yet to be implemented (elastic/elastic-charts#502).

The list of instances should be feasible and lists the service instances available within the selected time range along with some key metrics;

• latency
• traffic (default sort option)
• errors
• CPU
• memory

🖼 View screens

---

Responsive layout guidelines

The immediately clear solution is to simply move to 100% widths for each panel when the viewport reaches a specific breakpoint. We can certainly play around with some more flex group magic to make e.g. the panels increase/decrease in size per breakpoint, but I think for now the easiest would be just simply put everything into single column rows.

Here's an example of the full-width panel layout;

🖼 View screens

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[smith]

This will change the related latency metrics on the rest of the page as well to keep it consistent with the main latency chart.

If changing that control changes the metric on all the charts on the page does it make sense to put it there? After I read this sentence I looked back at the mockups and was expecting the control to be outside of that specific chart.

[smith]

This comment mentions using the TopNavMenu component from the navigation plugin. If we're thinking about moving to that perhaps we can add it here, since we're moving the search bar and date picker around anyway.

[formgeist]

This will change the related latency metrics on the rest of the page as well to keep it consistent with the main latency chart.

If changing that control changes the metric on all the charts on the page does it make sense to put it there? After I read this sentence I looked back at the mockups and was expecting the control to be outside of that specific chart.

The metric selector will only change the Latency metrics for the main chart and the metrics in the Transactions, Errors, and Dependencies tables.

[smith]

Renamed to just "Service Overview." It's a meta issue for the whole feature.