[Logs UI] Show log analysis ML jobs in a list#71132
[Logs UI] Show log analysis ML jobs in a list#71132weltenwort merged 17 commits intoelastic:masterfrom
Conversation
bbabb39 to
e5a5dbd
Compare
8c92106 to
e4d4394
Compare
564acf7 to
0a55573
Compare
Kerry350
left a comment
There was a problem hiding this comment.
Awesome work 🎉
I've left a few comments, but nothing that should block approval. I also didn't want to comment on anything that was already covered under "Future work".
All the states worked well for me (including outdated configurations / definitions):
Only thing to mention out of these screenshots is the "success" callout rendered for me with the log entry job, should it do the same for just the categories job?
.../infra/public/components/logging/log_analysis_job_status/job_definition_outdated_callout.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/infra/public/components/logging/log_analysis_setup/manage_jobs_button.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Is it a problem that some user facing text uses "ML" and some uses "Machine Learning"?
There was a problem hiding this comment.
Good question, I'm trying to find that out...
There was a problem hiding this comment.
Sorry that it took a while to find an answer. The preferred variant is to spell out "Machine Learning" (capitalized if it refers to the app) and only use the abbreviation if there's too little room.
x-pack/plugins/infra/public/pages/logs/log_entry_rate/page_content.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/infra/public/pages/logs/log_entry_rate/page_content.tsx
Outdated
Show resolved
Hide resolved
|
Thank you for the timely review. I mostly addressed your comments, but I'm still looking for writer input regarding the ML vs Machine Learning question.
That condition could indeed be better. I just changed it to "when any of the jobs have just been created and no log rate or anomalies are found". I imagine that would be the situation in which the user would be most unsure. Does that make sense? |
The `required` module setup state doesn't have to encode the update and reconfiguration cases anymore, because the flyout visibility is decoupled from that.
3bbf3e2 to
e412dec
Compare
|
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
|
ℹ️ I rebased this on |
💚 Build SucceededBuild metrics@kbn/optimizer bundle module count
History
To update your PR or re-run it, just comment with: |
Kerry350
left a comment
There was a problem hiding this comment.
That condition could indeed be better. I just changed it to "when any of the jobs have just been created and no log rate or anomalies are found". I imagine that would be the situation in which the user would be most unsure. Does that make sense?
Makes sense, thanks for the explanation 👍
Reapproving now it's moved out of draft. Thanks for checking up on the "ML" vs "Machine Learning" copy (can always come in a followup if needed).
|
I'm still waiting for new insights on the copy, but I'll merge while the Jenkins and GitHub stars are aligned. |





Summary
This modifies the ML job setup flyout of the anomalies tab to offer a list of the two available modules. Via the list each of the modules' jobs can be created or re-created.
closes #64757
Previews
Review and test notes
The implementation can be seen as rather simplistic because it hard-codes the two available modules in the results page and flyout. The advantage is that the changeset is significantly smaller than of a fully generic implementation.
The possible setup state were reduced because the visibility state of the flyout and its pages is tracked in a separate flyout state (shared via the context).
The category page flyout only contains the category setup form and should function the same as before.
Warnings for outdated configurations or definitions can be triggered by modifying the jobs with queries like the following:
Future work