[APM] Offer users upgrade to metrics-based ML job

[dgieselaar]

Summary

In #101734, we will start supporting (transaction) metrics based ML jobs (v3). Users that have an existing ML job based on transaction events (v2), should be offered an upgrade, and be nudged towards doing so.

The current proposal is:

• Display a warning/callout in the APM ML header if v2 ML jobs are running. We already have something similar for v1 ML jobs.
• On the APM ML settings page, allow users a (one-click) upgrade from v2 to v3 ML jobs.

The upgrade process is as follows:

• Stop/close running v2 jobs, but don't delete them, to preserve results.
• For every running v2 job, create a v3 job for the same environment.

Open questions

• How to handle existing alerts based on ML data

Design solution

Please refer to https://github.com/elastic/observability-design/issues/106 for the design solution description.

[elasticmachine]

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

[formgeist]

@dgieselaar Just need some quick clarificiations;

Display a warning/callout in the APM ML header if v2 ML jobs are running. We already have something similar for v1 ML jobs.

Is that warning/callout the Kibana menu header (similar to when there are no jobs created)? I can't remember nor figure out how to invoke that warning.

For every running v2 job, create a v3 job for the same environment.

Just so I'm clear we will upgrade all of their existing v2 jobs to v3 without the option to select individual environments to be included in the upgrade? I like that because we don't have to build out any selection UX of existing jobs and I don't see why it'd be necessary for the user to change the jobs at this time.

In that case, it can be as simple as you describe it - we just show a callout to inform the user to upgrade their jobs and the implications.

Not sure if it's necessary, but I can put together some quick mocks for the callout and UX.

[dgieselaar]

Is that warning/callout the Kibana menu header (similar to when there are no jobs created)? I can't remember nor figure out how to invoke that warning.

I think it's supposed to show if you don't have any ML jobs but you can create them (for the current environment).

Just so I'm clear we will upgrade all of their existing v2 jobs to v3 without the option to select individual environments to be included in the upgrade?

yeah, I think so. with one caveat, that we'll be replacing their jobs, and closing the old ones. so we'd have to filter the list of ML jobs and hide stopped v2 jobs, if that does not happen automatically already. do you think we should also display a status/version in the table?

Not sure if it's necessary, but I can put together some quick mocks for the callout and UX.

always helpful!

[dgieselaar]

Blocked by elastic/elasticsearch#77734.

[formgeist]

@dgieselaar @sqren I've updated the description with a link to the design issue which contains the full description of the main UX solution for migrating to the new ML jobs and other related solutions that will preferably be included in this iteration. Let me know if you have any questions or concerns 👍

[dgieselaar]

@formgeist do you mind clarifying what the buttons on the right of a job row are supposed to do? I remember we briefly discussed having links to both the anomaly explorer and the job management page for that specific job but I can't quite tell from the screenshot what the inspect icon should do and whether the settings thing is a dropdown or a link to the job management page (i'm assuming it's the latter and the inspect icon should link to the anomaly explorer but want to verify).

[formgeist]

@dgieselaar Apologies, I've just realized how inconsistent those actions are across the provided design screens. Also, I double-checked the ML icon usage and found they use a different icon for the anomaly explorer link in their jobs management table.

• The visTable icon will take the user to explore the job results in the ML Anomaly Explorer
• The gear icon will take the user to the jobs management page filtered by the apm group and with the job ID in the query. Here's an example;
• We'll need to add tooltips for those actions to be clearly stated

View screens

Does that make sense?

[dgieselaar]

@formgeist sure, that makes sense. I've replaced "stopped" with "warning", fwiw, as there are other states (e.g. failed) that might be better captured as "warning". WDYT?

[formgeist]

@dgieselaar In that case, should we think about providing a job state message in a tooltip upon hovering the badge? Otherwise the user is left to go to the Jobs mgmt page to find out what's wrong? I know we're in a grey area on what should be supported inside APM and what should be directed to ML here...

[dgieselaar]

@formgeist there are six states each for job and datafeed 😬 the job can be opened, but the datafeed can be stopped, or stopping, or failed, etc. I think displaying a warning if both job and datafeed are not running & the job is not closed, and then redirecting to the ML Job Management UI is our best bet here.

[formgeist]

@dgieselaar Ok I can agree with that 👍