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

[Monitoring] Optimizing alerting code #83681

Merged
merged 17 commits into from
Dec 8, 2020

Conversation

igoristic
Copy link
Contributor

@igoristic igoristic commented Nov 18, 2020

Resolves #80065

  • Shared threshold/legacy alert functionality is moved into base alert/watches

  • processData method is now shared across all none legacy alerts

  • All "legacy" watches type alerts now share processData and fetchData methods

  • Some helper methods were also unified

  • Removed dead code

  • Mostly code that wasn't used any more due to removal of some features, mainly stack products and resolved functionality

  • Server/UI shared elements moved into common folder (mostly done in [Monitoring] Thread pool rejections alert #79433)

  • In some cases we were importing a lot of alerts related code into our frontend app which pretty much imported the whole server app due to other required imports/dependancies

  • Also moved all the types/helpers shared between server and public folder into common folder

  • Test alert triggers with multiple environments primarily CCR/remote features, and with/without security

  • Fix unit/functional tests

@igoristic igoristic added enhancement New value added to drive a business result Team:Monitoring Stack Monitoring team v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.11.0 labels Nov 18, 2020
@igoristic igoristic added this to the Stack Monitoring UI 7.11 milestone Nov 18, 2020
@igoristic igoristic marked this pull request as ready for review November 30, 2020 10:48
@igoristic igoristic requested a review from a team November 30, 2020 10:48
@elasticmachine
Copy link
Contributor

Pinging @elastic/stack-monitoring (Team:Monitoring)

@chrisronline
Copy link
Contributor

@igoristic

Thanks for putting this up!

I'm having a hard time reviewing this, as I'm not really sure what problems we're solving.

I see a few changes that maybe make the code easier to read, but it would help me greatly if you could list out what you changed and why, which will help give me context into the review.

For example, in the description:

Shared threshold alert functionality is moved into base alert

What does this mean exactly? What functionality was moved to the base?

@igoristic
Copy link
Contributor Author

@chrisronline I added more details to the body, but I'm happy to do a walk-through/zoom if it helps

Copy link
Contributor

@chrisronline chrisronline left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link back from the internalFullMessage is broken - it just renders like: http://elasticsearch/nodes? Is that a regression in this PR?

@chrisronline
Copy link
Contributor

Also, can we separate this into three separate PRs?

  1. Shared threshold/legacy alert functionality is moved into base alert/watches
  2. Removed dead code
  3. Server/UI shared elements moved into common folder

I'm finding it hard to understand what code changes contribute to which.

@igoristic
Copy link
Contributor Author

@chrisronline

The link back from the internalFullMessage is broken...

I think we should keep track of everything we find and compare 'em with master. If it's indeed a regression I'll address it in this branch, otherwise it should go into a separate issue

Also, can we separate this into three separate PRs...

I agree this should have been broken down into couple of PRs (from the beginning), but at this state it might be too late since all the changes are coupled together. It would take a lot of work decoupling everything, and might require some extra (throw away) work just so they could function independently. I will keep this in mind when doing future PRs similar in nature

@igoristic
Copy link
Contributor Author

If you want I can go through it all via zoom, would be more than happy to

@chrisronline
Copy link
Contributor

@jasonrhodes Curious to your thoughts here. Should we get on a zoom on discuss it more? Or do you think we can discuss everything here?

@jasonrhodes
Copy link
Member

@jasonrhodes Curious to your thoughts here. Should we get on a zoom on discuss it more? Or do you think we can discuss everything here?

My advice is to do the zoom call, and if after that call, it still feels difficult to review, we should split into 2-3 PRs even if it takes some work. That is probably the safest thing to do. If the zoom call can help illuminate the changes sufficiently, we can keep it, but I'd leave that up to Chris as the reviewer.

@jasonrhodes
Copy link
Member

I think we should keep track of everything we find and compare 'em with master. If it's indeed a regression I'll address it in this branch, otherwise it should go into a separate issue

This makes sense and sounds like how we should try to treat most code reviews.

Copy link
Contributor

@chrisronline chrisronline left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. Thanks for hoping on a zoom to help talk it through. I only had one small comment for now

Copy link
Contributor

@chrisronline chrisronline left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seem to be at least one test removed that should be put back, but once that's done, this LGTM! Great work!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
monitoring 612 611 -1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
monitoring 951.7KB 944.7KB -7.0KB

Distributable file count

id before after diff
default 47694 47692 -2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@igoristic igoristic merged commit a41881d into elastic:master Dec 8, 2020
@igoristic igoristic deleted the optimizing_alerts branch December 8, 2020 15:16
igoristic added a commit that referenced this pull request Dec 8, 2020
* [Monitoring] Optimizing alerting code (#83681)

* Optimize alerting code

* Merged all the branches

* resolved conflict

* optimizing all branches merged

* Fixed tests and resolved conflicts

* Fixed jest tests

* Resolved merge conflicts with the alerting team's PR
# Conflicts:
#	x-pack/plugins/monitoring/public/components/apm/instance/instance.js
#	x-pack/plugins/monitoring/public/components/beats/beat/beat.js

* Update instance.js
@igoristic
Copy link
Contributor Author

Backport:
7.x: c60bd21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result release_note:skip Skip the PR/issue when compiling release notes Team:Monitoring Stack Monitoring team v7.11.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Monitoring] Share alerting code better
5 participants