[Security Solution] Switches remaining rule types to use new Rule Preview API#116374
[Security Solution] Switches remaining rule types to use new Rule Preview API#116374dplumlee merged 35 commits intoelastic:mainfrom
Conversation
cfaff97 to
c3441ec
Compare
44971a8 to
a624960
Compare
0d47948 to
1656bdf
Compare
4dbfc45 to
dd39c1e
Compare
dd39c1e to
7adb090
Compare
There was a problem hiding this comment.
I was testing this PR locally and I came across a critical issue (409 w/ version_conflict_engine_exception) - please let me know if you are not able to reproduce it.
- create a
test-indexwith@timestampfield with date mapping - post an event to
test-index, with current timestamp andtest_id: 123 - create a custom query rule for
test-indexwithtest_id: *query - observe that the preview returns no results on the UI (expecting 1)
- observe that inspecting matrix histogram query there are no results (expecting 1)
- observe that once the rule is created 1 alert is generated as expected
- observe via devtools that there is a preview event on the preview index as expected
this was the error was in the console
[2021-12-06T14:48:35.044-05:00][ERROR][plugins.ruleRegistry] ResponseError: {"took":0,"errors":true,"items":[{"create":{"_index":".internal.preview.alerts-security.alerts-default-000001","_id":"80c7e30e7572dc2fa9ef510d5c3747fafda0a10dec8f0c5afa7e03817840841a","status":409,"error":{"type":"version_conflict_engine_exception","reason":"[80c7e30e7572dc2fa9ef510d5c3747fafda0a10dec8f0c5afa7e03817840841a]: version conflict, document already exists (current version [1])","index_uuid":"sKKOrC7YSySyt16-FqFNQg","shard":"0","index":".internal.preview.alerts-security.alerts-default-000001"}}}]}
at /Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/rule_data_client/rule_data_client.ts:194:31
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at alertWithPersistence (/Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/utils/create_persistence_rule_type_wrapper.ts:94:34)
at /Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/factories/bulk_create_factory.ts:47:31
at searchAfterAndBulkCreate (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/signals/search_after_bulk_create.ts:158:13)
at Object.executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/query/create_query_alert_type.ts:66:22)
at Object.executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/create_security_rule_type_wrapper.ts:246:51)
at executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/utils/create_persistence_rule_type_wrapper.ts:20:23)
at lists (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts:140:11)
at /Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts:178:11
at Router.handle (/Users/eceozalp/Workspace/kibana/src/core/server/http/router/router.ts:275:30)
at handler (/Users/eceozalp/Workspace/kibana/src/core/server/http/router/router.ts:230:13)
at exports.Manager.execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
at Object.internals.handler (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
at exports.execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
at Request._lifecycle (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/request.js:371:32)
at Request._execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/request.js:281:9)
I deleted my preview index and started kibana again, and tried to preview the same event with a different new rule, and the problem persisted.
|
@ecezalp The error you're seeing in the console is a side effect of the new dedup logic we're using for the rule registry executors. It's not actually impacting the data we're getting back and displaying in the preview index/histogram. The real issue was the index having a bit of a race condition between refreshing and the read call the histogram is sending, the data was not always being indexed fully thus making it unable to be read by the histogram. In the latest commit, we add an await clause to refresh the alias + namespace before returning the initial preview call so that the UI should always be able to read the entire index correctly. As for the console error itself, @marshallmain has this PR that addresses logging the message instead of throwing the error, but from my understanding it's more of an indication that the dedup is working and not causing data to not be written properly |
|
following the instructions from my previous comment, I am still seeing no preview results when trying to preview a custom query rule. preview index seems to get populated, but the matrix histogram query doesn't return anything. I have tested by pulling the latest changes & deleting the data directory & bootstrapping & following the steps shared above |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @dplumlee |
| return this.options.indexInfo.kibanaVersion; | ||
| } | ||
|
|
||
| public indexNameWithNamespace(namespace: string): string { |
|
Removed the blocker as Davis pointed out that the bug identified is an existing one, and is logged here |
There was a problem hiding this comment.
LGTM, thank you for the hard work!
I was able to locally run the code and confirm that custom query rules, threshold rules, and EQL rules can be previewed as expected.
There is still some relevant work that needs to be completed, which we should do during the FF
| export const isNoisy = (hits: number, timeframe: Unit): boolean => { | ||
| if (timeframe === 'h') { | ||
| return hits > 1; | ||
| return hits > 20; |
There was a problem hiding this comment.
was there a particular reason for this change? as far as I know, the noisiness criteria was 1 alert per hour for all scenarios
There was a problem hiding this comment.
Ah maybe i misunderstood the code prior to then, I thought we were going based of the invocations themselves, we can switch that back and get a more solidified answer for noisiness in all rule scenarios
| } | ||
|
|
||
| if (request.body.type === 'threat_match') { | ||
| return response.ok({ body: { errors: ['Preview for rule type not supported'] } }); |
| { | ||
| index: previewRuleDataClient.indexNameWithNamespace(spaceId), | ||
| }, | ||
| { ignore: [404] } |
There was a problem hiding this comment.
hmm why are we ignoring 404 here? doesn't that mean that the preview index hasn't been properly created & functionality won't work?
There was a problem hiding this comment.
At this point, the 404 error would show up if there were no alerts written to the index and we wouldn't have created it because no alerts were found with the preview query. I believe in the event of the index not being properly created, there are other error handlers that would throw still
There was a problem hiding this comment.
so if the first preview ever doesn't have any results, you get a 404, which is then suppressed? that's sounds like an edge case. I think it's conceptually not very good to suppress errors like this in general, so maybe we should let the users see the error in that case.. we could ask product
There was a problem hiding this comment.
We can definitely ask, but as I understand it, this is expected behavior as it wouldn't be an error from the user's perspective. It's more of an internal error dealing with the rule registry's design behavior of creating an index only if alerts exist. Users would get no data back and the resulting histogram would be empty which would be accurate from their POV and they need not know if the index was created or not. We can for sure discuss it further though
| threatMapping: ThreatMapping; | ||
| threshold: FieldValueThreshold; | ||
| machineLearningJobId: string[]; | ||
| anomalyThreshold: number; |
There was a problem hiding this comment.
Mixing params from different rule types is something of an anti-pattern IMO.
There was a problem hiding this comment.
From a UI perspective, these are always present since it's just the form state. They do get separated into their different rule types later. There's probably better ways to pass that through though
|
The following labels were identified as gaps in your version labels and will be added automatically:
If any of these should not be on your pull request, please manually remove them. |
💔 Backport failed
To backport manually run: |
…view API (elastic#116374) # Conflicts: # x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts
…le Preview API (#116374) (#120700) * [Security Solution] Switches remaining rule types to use new Rule Preview API (#116374) # Conflicts: # x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts * fix conflicts Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Overview
This PR switches the rule preview feature over to our new rule preview API that uses the actual rule executors instead of solely relying on a limited search strategy call over existing data. By using the actual executors, we are able to return real warnings and errors that occur in the execution process that previously couldn't be seen until the rule was created and actually ran. It also allows us to display a more accurate preview akin to what the real rule execution would show and gives us the ability to add more rule types and features to the preview functionality down the line.
Remaining tasks
/api/detection_engine/rules/previewto preview all rulesx-pack/plugins/security_solution/public/detections/components/rules/rule_previewx-pack/plugins/security_solution/cypress/integration/detection_ruleswith new selectors if necessary, and add preview coverage to theindicator_match_ruletest.x-pack/test/detection_engine_api_integration/security_and_spaces/testsfor the preview endpoint as well as the preview/index endpointx-pack/plugins/security_solution/public/detections/components/rules/query_previewdirectoryNote
Cypress tests related to threshold preview were disabled in this PR because of the way we implement the es archive data. The current method for testing the preview functionality is hard coding the look back time for the rule to 50,000 hours so it can get the data (timestamped 2019) to show up. With the new updates added in this PR, we no longer have the ability to hard code a look back time. While this is planned to be added in a future PR, it's still not a great way to maintain the tests and so I've opened an issue around updating the data generation for these (and perhaps more) cypress tests that will align with unskipping those specific cypress tests
Checklist
Delete any items that are not applicable to this PR.
For maintainers