Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Maps] Observability - Real User Monitoring layer template #64445

Closed
alexfrancoeur opened this issue Apr 24, 2020 · 4 comments
Closed

[Maps] Observability - Real User Monitoring layer template #64445

alexfrancoeur opened this issue Apr 24, 2020 · 4 comments
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation Team:Observability Team label for Observability Team (for things that are handled across all of observability)

Comments

@alexfrancoeur
Copy link

alexfrancoeur commented Apr 24, 2020

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

image9

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

image5

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

image6

Layer type: APM - Real User Monitoring - Traffic
Custom name: Front end total traffic
Service: frontend
Metric: duration_sla_pct
Cohort filter: All
Aggregate: Count

image8
ignore the layer description in the screenshot

cc: @cyrille-leclerc @tbragin @VijayDoshi

@alexfrancoeur alexfrancoeur added [Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation Team:Observability Team label for Observability Team (for things that are handled across all of observability) labels Apr 24, 2020
@nreese nreese added the blocked label Apr 27, 2020
@nreese
Copy link
Contributor

nreese commented Apr 27, 2020

blocked by #64461

@nreese nreese removed the blocked label Apr 28, 2020
@nreese
Copy link
Contributor

nreese commented Apr 29, 2020

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.

I am not sure we can allow users to choose administrative boundaries. Where in the ECS does ids for EMS administrative boundaries live? Does ECS provide keys for all EMS administrative boundaries?

@thomasneirynck
Copy link
Contributor

thomasneirynck commented Apr 29, 2020

for confirmation: the field is geo.region_iso_code https://www.elastic.co/guide/en/ecs/current/ecs-geo.html. But since that one is still in flight on the EMS-side (elastic/ems-file-service#171), imho OK to leave out sub-regions at initial pass at this

@thomasneirynck
Copy link
Contributor

Closing. RUM layers were added in 7.8 #64949

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation Team:Observability Team label for Observability Team (for things that are handled across all of observability)
Projects
None yet
Development

No branches or pull requests

3 participants