[Maps] Observability - Real User Monitoring layer template #64445
Description
As we explore new layer templates for solutions, we believe the Observability template will be a good place to start. Below are the requirements defined, as agreed upon by @drewpost, @cyrille-leclerc and the @elastic/kibana-gis team that we'll aim to deliver for the next release. We plan to iterate and this is expected to be the first phase with additional enhancements for polish in the future. This layer will be entirely focused on Real User Monitoring. We'll probably need input from our tech writing team for consistency on naming conventions across the app. This is just how I've visualized the configuration of these layers, please, feel free to adjust as needed for both technical or UX reasons.
Layer selection
As part of the current layer selection list, we'll want an option to choose Observability as group of layers the end user would like to visualize.
Input
In an effort to simplify the configuration experience for the end user, we'll want to provide a handful of dropdowns for an initial configuration. We'll need some input from @gchaps and others most likely for a lot of this.
Type
We'll want the user to select a type of layer / map for an Observability use case. To start, we'll only have one type. Uptime or Metrics are ones we could address in the future. This could be presented as a disabled combo box initially. We'll need @drewpost to provide some feedback on the naming conventions used here. We will be using apm-*-transaction* as an index pattern behind the scenes.
Type:
- APM - Real User Monitoring - Performance & Traffic
- APM - Real User Monitoring - Performance
- APM - Real User Monitoring - Traffic
Service
Optionally, we'll want to enable the user to select one, multiple or all services (default) that they'd like this map to be filtered to.
Service:
- One, multiple or all services
Metrics
To make configuration simple, we'll want to offer a few drop downs to depending on the layer type they've chosen. We'll need to triple check with @drewpost that these are the fields we should be using for traffic and performance.
APM - Real User Monitoring - Performance & Traffic
Choose performance metric:
- Transaction duration:
transaction.duration.us- SLA percentage:
duration_sla_pct
Choose traffic metric:
- Total count: Count of
transaction.id- Unique count: Unique count of
transaction.id
APM - Real User Monitoring - Performance
Choose performance metric:
- Transaction duration:
transaction.duration.us- SLA percentage:
duration_sla_pct
APM - Real User Monitoring - Traffic
Choose traffic metric:
- Total count: Count of
transaction.id- Unique count: Unique count of
transaction.id
Common configuration options
There will be a set of common configuration options that can be applied to each visualization type.
Filter Cohorts
To simply configuration, I feel like it'd be nice to offer quick and easy ways to customize a Cohort profile that essentially builds a query or filter. This could have a similar UI/UX experience for building a tooltip, adding each filter individually.
Add a filter to customize your view for specific cohorts
[Add filter]
[Browser | Operating System | Device] [Browser Name | OS Name | Device Name] [version | all versions]
Cohort fields:
- Browser:
user_agent.name - Operating System:
user_agent.os.name - Device:
user_agent.device.name - All users:
*
Style
Generally, we'll have two ways to visualize your data at a high level. Either a choropleth map with EMS boundaries or points. If traffic and performance are chosen, we'd simply combine the two configurations or select a smart default that can be tweaked later (heatmap for traffic, with choropleth map for performance for example).
Choose the type of map you'd like to see
- Choropleth
- Clusters
Choropleth
Choropleth maps are meant to be provide an aggregate view and we can provide a few options for styling here.
Boundaries
Users should have be able to select the administrative boundary they'd like and we should offer the World Countries and the upcoming World Country Subdivisions layer at the top as a choice.
Select an administrative boundary to view [performance | traffic] metrics
- Boundaries: [Long list of EMS boundaries]
Choose a predefined or custom color ramp for [performance | traffic] metrics
Clusters
Here we'll have a mix between cluster, grid, heatmap and blended layers.
Real time or aggregate
Choose real time to provide top entity by timestamp and offer the ability to customize how many entities. This should be a blended layer with predefined tooltips. Optionally, we should provide the ability to split by cohorts to show the top 10 names. Choose aggregate to select the aggregation you'd like to use for the metric chosen earlier and how it should be viewed.
Select real time to view the most recent points on a map. Choose aggregation to view the points clustered on your map.
- [Real-time] [1 - 100 slider]
Optionally, categorize by [Browser | Operating System | Device]
- [Aggregation] [available aggregations]
Choose a predefined or custom color ramp for [performance | traffic] metrics
Example Outputs
Below you'll find some example outputs that can be configured from this new layer template. There is a performance & traffic layer type missing, but just imagine having both layers represented :-)
Layer type: APM - Real User Monitoring - Performance
Custom name: Frontend mobile device performance by country
Service: frontend
Metric: transaction.duration.us
Cohort filter: Device - Chrome Mobile, Firefox Mobile, Mobile Safari
Style: Choropleth
Layer type: APM - Real User Monitoring - Traffic
Custom name: Chrome traffic by country
Service: frontend
Metric: Unique count of transaction.id
Cohort filter: Browser - Chrome
Style: Choropleth
Layer type: APM - Real User Monitoring - Performance
Custom name: Real time OS performance
Service: frontend
Metric: duration_sla_pct
Cohort categorization: Operating System
Real time: Last 10 points using @timestamp
Layer type: APM - Real User Monitoring - Traffic
Custom name: Front end total traffic
Service: frontend
Metric: duration_sla_pct
Cohort filter: All
Aggregate: Count
ignore the layer description in the screenshot