-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Security Solution][Detections] Truncate lastFailureMessage for siem-detection-engine-rule-status documents #112257
[Security Solution][Detections] Truncate lastFailureMessage for siem-detection-engine-rule-status documents #112257
Conversation
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
x-pack/plugins/security_solution/server/lib/detection_engine/rules/saved_object_mappings.ts
Outdated
Show resolved
Hide resolved
...gins/security_solution/server/lib/detection_engine/rule_execution_log/utils/normalization.ts
Outdated
Show resolved
Hide resolved
...gins/security_solution/server/lib/detection_engine/rule_execution_log/utils/normalization.ts
Show resolved
Hide resolved
...ecurity_solution/server/lib/detection_engine/rule_execution_log/rule_execution_log_client.ts
Show resolved
Hide resolved
...ecurity_solution/server/lib/detection_engine/rule_types/create_security_rule_type_factory.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/server/lib/detection_engine/rules/saved_object_mappings.ts
Outdated
Show resolved
Hide resolved
cd02610
to
5b25da2
Compare
5b25da2
to
8946be2
Compare
8946be2
to
236009c
Compare
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @banderror |
@@ -47,11 +48,28 @@ export const ruleStatusSavedObjectMappings: SavedObjectsType['mappings'] = { | |||
}, | |||
}; | |||
|
|||
const truncateMessageFields: SavedObjectMigrationFn<Record<string, unknown>> = (doc) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Record<string, unknown>
doesn't really add any type safety. Could you use IRuleStatusSOAttributes
https://github.com/elastic/kibana/blob/master/x-pack/plugins/security_solution/server/lib/detection_engine/rules/types.ts#L113-L125
Don't have to block on this, but I think this is a good pattern to adopt for migrations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general IRuleStatusSOAttributes
would correspond to the current (target for this migration) interface, not to the previous interface (prior to migration). Although in this particular case no changes to IRuleStatusSOAttributes
have been made, it doesn't mean we wouldn't change it in the future. Any substantial change to the TS interface in a future version would keep this function statically typed but it would not be safe anymore - we'd need to adjust the code of the migration function to conform to the changed interface, thus making the function prone to bugs. Maintaining history of these interfaces (like IRuleStatusSOAttributes_v15_1
etc) would help keeping it fully statically typed and correct, but we don't do this and effort/value ratio of this seems to be too high. Specifying target SO attributes (MigratedAttributes
) as IRuleStatusSOAttributes
is actually prone to the same issues.
I think unless we start maintaining a history of TS interfaces for the SO attributes, introducing type safety here actually means introducing risk of making migrations incorrect in the future.
Also, we'll likely get rid of this SO type very soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the changes, Georgii👍
We could address outstanding questions separately, this PR LGTM!
…detection-engine-rule-status documents (elastic#112257) **Ticket:** elastic#109815 ## Summary **Background:** `siem-detection-engine-rule-status` documents stores the `lastFailureMessage` a string which is indexed as `type: "text"` but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch's `http.max_content_length` which defaults to 100mb. This PR truncates `lastFailureMessage` and `lastSuccessMessage` in the following cases: 1. When we write new or update existing status SOs: - The lists of errors/warnings are deduped -> truncated to max `20` items -> joined to a string - The resulting strings are truncated to max `10240` characters 2. When we migrate `siem-detection-engine-rule-status` SOs to 7.15.2: - The two message fields are truncated to max `10240` characters ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
💔 Backport failed
Successful backport PRs will be merged automatically after passing CI. To backport manually run: |
I 👀 the failed backport, will manually make it. UPD: #115166 |
…detection-engine-rule-status documents (#112257) (#115038) **Ticket:** #109815 ## Summary **Background:** `siem-detection-engine-rule-status` documents stores the `lastFailureMessage` a string which is indexed as `type: "text"` but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch's `http.max_content_length` which defaults to 100mb. This PR truncates `lastFailureMessage` and `lastSuccessMessage` in the following cases: 1. When we write new or update existing status SOs: - The lists of errors/warnings are deduped -> truncated to max `20` items -> joined to a string - The resulting strings are truncated to max `10240` characters 2. When we migrate `siem-detection-engine-rule-status` SOs to 7.15.2: - The two message fields are truncated to max `10240` characters ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Georgii Gorbachev <[email protected]>
…r siem-detection-engine-rule-status documents (elastic#112257) **Ticket:** elastic#109815 **Background:** `siem-detection-engine-rule-status` documents stores the `lastFailureMessage` a string which is indexed as `type: "text"` but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch's `http.max_content_length` which defaults to 100mb. This PR truncates `lastFailureMessage` and `lastSuccessMessage` in the following cases: 1. When we write new or update existing status SOs: - The lists of errors/warnings are deduped -> truncated to max `20` items -> joined to a string - The resulting strings are truncated to max `10240` characters 2. When we migrate `siem-detection-engine-rule-status` SOs to 7.15.2: - The two message fields are truncated to max `10240` characters Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…r siem-detection-engine-rule-status documents (#112257) (#115166) **Ticket:** #109815 **Background:** `siem-detection-engine-rule-status` documents stores the `lastFailureMessage` a string which is indexed as `type: "text"` but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch's `http.max_content_length` which defaults to 100mb. This PR truncates `lastFailureMessage` and `lastSuccessMessage` in the following cases: 1. When we write new or update existing status SOs: - The lists of errors/warnings are deduped -> truncated to max `20` items -> joined to a string - The resulting strings are truncated to max `10240` characters 2. When we migrate `siem-detection-engine-rule-status` SOs to 7.15.2: - The two message fields are truncated to max `10240` characters Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
Ticket: #109815
Summary
Background:
siem-detection-engine-rule-status
documents stores thelastFailureMessage
a string which is indexed astype: "text"
but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch'shttp.max_content_length
which defaults to 100mb.This PR truncates
lastFailureMessage
andlastSuccessMessage
in the following cases:20
items -> joined to a string10240
characterssiem-detection-engine-rule-status
SOs to 7.15.2:10240
charactersChecklist
Delete any items that are not applicable to this PR.