[alerting] add ignore_above to alerts params mappings to handle immense params #100726
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…se params resolves elastic#100607 This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update). Document contains at least one immense term in field=\"alert.params\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. After the fix, you can alerts with immense params can be saved and executed. Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
pmuellr
added
Feature:Alerting
v8.0.0
release_note:skip
|
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
mikecote
approved these changes
May 26, 2021
💚 Build SucceededMetrics [docs]
To update your PR or re-run it, just comment with: |
pmuellr
added a commit
to pmuellr/kibana
that referenced
this pull request
May 27, 2021
…se params (elastic#100726) resolves elastic#100607 This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update). Document contains at least one immense term in field=\"alert.params\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. After the fix, alerts with immense params can be saved and executed. Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
pmuellr
added a commit
to pmuellr/kibana
that referenced
this pull request
May 27, 2021
…se params (elastic#100726) resolves elastic#100607 This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update). Document contains at least one immense term in field=\"alert.params\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. After the fix, alerts with immense params can be saved and executed. Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
pmuellr
added a commit
that referenced
this pull request
May 27, 2021
…se params (#100726) (#100772) resolves #100607 This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update). Document contains at least one immense term in field=\"alert.params\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. After the fix, alerts with immense params can be saved and executed. Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
pmuellr
added a commit
that referenced
this pull request
May 27, 2021
…se params (#100726) (#100773) resolves #100607 This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update). Document contains at least one immense term in field=\"alert.params\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. After the fix, alerts with immense params can be saved and executed. Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
|
I tested an actual migration as well, thought I'd point out. From the 7.12 dev branch to master branch. No problem. |
timroes
added
release_note:fix
and removed
release_note:skip
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
resolves #100607
Summary
This fixes a problem when very large parameters (over 32K bytes) are saved with an alert. Before this fix, an error from elasticsearch would be thrown with the following message, and a 400 returned from create (and presumably update).
After the fix, alerts with immense params can be saved and executed.
Note that the immense params will not be searchable, since they won't be indexed, but that seems both unavoidable, and not a severe issue.
Checklist
Delete any items that are not applicable to this PR.
Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n supportDocumentation was added for features that require explanation or tutorialsAny UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker listThis renders correctly on smaller devices using a responsive layout. (You can test this in your browser)This was checked for cross-browser compatibilityFor maintainers
This was checked for breaking API changes and was labeled appropriately