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

fix alert normalization #50

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

atammy-narmi
Copy link

Description

Fix normalization of alerts and triggers. The new API for opensearch rearranged the JSON so we need to update the normalization code.

I took the trigger_types from https://github.com/opensearch-project/alerting-dashboards-plugin/blob/353aa258fb9a2f031964427a45da765092c7cf6d/public/pages/CreateTrigger/containers/CreateTrigger/utils/constants.js#L6

Issues Resolved

N/A

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

for _, t := range triggers {
if trigger, ok := t.(map[string]interface{}); ok {
delete(trigger, "id")

if actions, ok := trigger["actions"].([]interface{}); ok {
normalizeMonitorTriggerActions(actions)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why are you removing this part of the normalization?

Copy link
Author

Choose a reason for hiding this comment

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

I didn't see it present in any of the alerts that we had in our system, so it seemed spurious to keep it there. Do you want me to add it back?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It was introduced here: phillbaker/terraform-provider-elasticsearch#164 can you see if that's still an issue?

Copy link
Author

Choose a reason for hiding this comment

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

Checked it out and it's not an issue with the newer opensearch monitors.

The opensearch alerting plugin changes aren't using the same syntax/representation as the elasticsearch, so we can delete this without worries.

@prudhvigodithi
Copy link
Member

Hey @atammy-narmi we just merged the PR for provider OpenSearch 2.x support, can you please fetch upstream and modify the changes accordingly.
Thank you
@bbarani @peterzhuamazon

@atammy-narmi
Copy link
Author

OK, I've rebased the PR.

@prudhvigodithi
Copy link
Member

Hey @phillbaker can we move forward with this PR?
Thanks

@prudhvigodithi
Copy link
Member

Hey @phillbaker just checking back, are we good to move forward with this PR?
Thank you

@atammy-narmi
Copy link
Author

is there anything that's blocking this PR from being merged?

@prudhvigodithi
Copy link
Member

Hey @atammy-narmi thanks for holding on this, does this change require for 2.x version of OpenSearch ? If need only for 1.x, please raise a PR to 1.x branch. Thank you
@peterzhuamazon @bbarani

@atammy-narmi
Copy link
Author

Hey @atammy-narmi thanks for holding on this, does this change require for 2.x version of OpenSearch ? If need only for 1.x, please raise a PR to 1.x branch. Thank you @peterzhuamazon @bbarani

This works with the 2.x version of opensearch 😸

@prudhvigodithi
Copy link
Member

This works with the 2.x version of opensearch 😸

Got it, then please change the base branch to 1.x as this an issue for only OpenSearch 1.x series. Thanks

@atammy-narmi
Copy link
Author

This works with the 2.x version of opensearch 😸

Got it, then please change the base branch to 1.x as this an issue for only OpenSearch 1.x series. Thanks

No, I said it's for the the 2.x branch.

@prudhvigodithi
Copy link
Member

No, I said it's for the the 2.x branch.

Do we need to backport this to 1.x?

@atammy-narmi
Copy link
Author

No, I said it's for the the 2.x branch.

Do we need to backport this to 1.x?

I don't think so.

@prudhvigodithi
Copy link
Member

prudhvigodithi commented Oct 5, 2023

Cool, thanks LGTM.
@atammy-narmi Can you please add some unit tests, we can ship this in next release.

@atammy-narmi
Copy link
Author

I don't see any tests defined for other functions in the provider_test.go, could you point to where I should add the tests?

@prudhvigodithi
Copy link
Member

I don't see any tests defined for other functions in the provider_test.go, could you point to where I should add the tests?

Hey @atammy-narmi may be it was started that way, would it be better to add in provider_test.go or create a file util_test.go, WDYT? Just want to ensure your change is tested before we the provider is shipped :)
Thank you

@prudhvigodithi
Copy link
Member

Hey @atammy-narmi just following back on this PR? can you please add some unit tests so that we merge this PR.
Thanks

@prudhvigodithi
Copy link
Member

Hey @atammy-narmi just following back again on this PR? can you please add some unit tests so that we merge this PR.
Thanks

@atammy-narmi
Copy link
Author

Sorry, it will take me a couple more days, will try to get it done by next week 😄

@rblcoder
Copy link
Collaborator

@atammy-narmi Could you please create an issue and specify examples so that I can test and review the PR?

@prudhvigodithi
Copy link
Member

Hey @atammy-narmi just following back on this PR? can you please add some unit tests so that we merge this PR.
Thanks

@atammy-narmi
Copy link
Author

I've added something which looks like it should test this out.
I don't have a development environment setup for a local opensearch cluster, so I haven't managed to test this fully, can you approve the workflow so I can try testing this out?

@atammy-narmi
Copy link
Author

Should be working now.

@@ -71,52 +94,99 @@ func testCheckOpensearchMonitorDestroy(s *terraform.State) error {
return nil
}

var testAccOpensearchOpenDistroMonitorJSON = `
Copy link
Author

Choose a reason for hiding this comment

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

had to duplicate this cuz the linting was complaining if I did it the smart way by embedding the variable.

@bbarani
Copy link
Member

bbarani commented Jan 22, 2024

@prudhvigodithi @phillbaker @rblcoder can we move forward on this PR?

@@ -55,17 +56,26 @@ func normalizeMonitor(tpl map[string]interface{}) {
}

func normalizeMonitorTriggers(triggers []interface{}) {
trigger_types := []string{"alerting_trigger", "anomaly_detector_trigger", "bucket_level_trigger", "document_level_trigger", "query_level_trigger"}
for _, t := range triggers {
Copy link
Member

Choose a reason for hiding this comment

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

Just checking is there a way identify all these actions using client actions rather than hardcoding ?

Copy link
Member

Choose a reason for hiding this comment

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

I see a new one chained_alert_trigger.

Copy link
Author

Choose a reason for hiding this comment

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

Sadly I don't know of any :(

@prudhvigodithi
Copy link
Member

Thanks @atammy-narmi other than my above two comments the change LGTM.

@rblcoder
Copy link
Collaborator

@atammy-narmi @prudhvigodithi Can the code for normalizeMonitorTriggers be as follows? I checked, the tests are also passing.

func normalizeMonitorTriggers(triggers []interface{}) {
	// trigger_types := []string{"alerting_trigger", "anomaly_detector_trigger", "bucket_level_trigger", "chained_alert_trigger", "document_level_trigger", "query_level_trigger"}
	for _, t := range triggers {
		if trigger, ok := t.(map[string]interface{}); ok {
			delete(trigger, "id")
			var trigger_type_key string
			for key := range trigger {
				if strings.HasSuffix(key, "_trigger") {
					trigger_type_key = key
					break
				}
			}

			if qlt, ok := trigger[trigger_type_key].(map[string]interface{}); ok {
				normalizeMonitorLevelTriggers(qlt)
			}

		}
	}
}

@atammy-narmi
Copy link
Author

atammy-narmi commented Jan 26, 2024

While that seems OK with me, it seems to be relying implicitly on all triggers being named *_trigger. I don't have a problem with that, but might be worth checking if you want to introduce that kind of pattern.

Another is that this implementation assumes only one trigger, you could potentially have multiple triggers. Removing the break and moving the normalize to inside the block should work for that scenario.

@rblcoder
Copy link
Collaborator

rblcoder commented Jan 27, 2024

@atammy-narmi I agree that the code above is not robust.
Adding links for sample json documents if anyone going through this issue later would like to refer -
https://opensearch.org/docs/latest/observing-your-data/alerting/per-cluster-metrics-monitors/#painless-triggers
https://opensearch.org/docs/latest/observing-your-data/alerting/composite-monitors/#example-request

@atammy-narmi
Copy link
Author

Bump, can I ask whats the holdup now?

Signed-off-by: Abhinav Tamaskar <[email protected]>
Signed-off-by: Abhinav Tamaskar <[email protected]>
Signed-off-by: Abhinav Tamaskar <[email protected]>
Signed-off-by: Abhinav Tamaskar <[email protected]>
Signed-off-by: Abhinav Tamaskar <[email protected]>
@prudhvigodithi
Copy link
Member

Thanks @atammy-narmi, @rblcoder since you are reviewing, can you please check and see if we are good to move forward.
Thanks

@rblcoder
Copy link
Collaborator

@atammy-narmi As mentioned in #50 (comment), can you try to avoid hard-coding the trigger types?
Can you create a REST API to get list of trigger types?
opensearch-project/alerting#1422

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📦 Backlog
Development

Successfully merging this pull request may close these issues.

5 participants