-
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] Switches remaining rule types to use new Rule Preview API #116374
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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-index
with@timestamp
field with date mapping - post an event to
test-index
, with current timestamp andtest_id: 123
- create a custom query rule for
test-index
withtest_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 |
@@ -54,6 +54,10 @@ export class RuleDataClient implements IRuleDataClient { | |||
return this.options.indexInfo.kibanaVersion; | |||
} | |||
|
|||
public indexNameWithNamespace(namespace: string): string { |
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.
👍
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -24,13 +24,13 @@ import { ESQuery } from '../../../../../common/typed_json'; | |||
*/ | |||
export const isNoisy = (hits: number, timeframe: Unit): boolean => { | |||
if (timeframe === 'h') { | |||
return hits > 1; | |||
return hits > 20; |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
) { | ||
return response.ok({ body: { errors: ['Invalid invocation count'] } }); | ||
} | ||
|
||
if (request.body.type === 'threat_match') { | ||
return response.ok({ body: { errors: ['Preview for rule type not supported'] } }); |
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.
👍
{ | ||
index: previewRuleDataClient.indexNameWithNamespace(spaceId), | ||
}, | ||
{ ignore: [404] } |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
LGTM
Nice work
@@ -22,6 +23,9 @@ interface PreviewRouteParams { | |||
ruleType: Type; | |||
timeFrame: Unit; | |||
threatMapping: ThreatMapping; | |||
threshold: FieldValueThreshold; | |||
machineLearningJobId: string[]; | |||
anomalyThreshold: number; |
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.
Mixing params from different rule types is something of an anti-pattern IMO.
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.
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 <[email protected]>
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/preview
to preview all rulesx-pack/plugins/security_solution/public/detections/components/rules/rule_preview
x-pack/plugins/security_solution/cypress/integration/detection_rules
with new selectors if necessary, and add preview coverage to theindicator_match_rule
test.x-pack/test/detection_engine_api_integration/security_and_spaces/tests
for the preview endpoint as well as the preview/index endpointx-pack/plugins/security_solution/public/detections/components/rules/query_preview
directoryNote
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