Marshall Main
Marshall Main
> Which expected timestamp values are you referring to? The original_time is always @timestamp, no? I am writing integration tests to ensure that alert generation works as expected with a...
> @marshallmain Could be missing something, but `original_time` is always just the `@timestamp` AFAICT. https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/factories/utils/build_alert.ts#L179-L182 ... For threshold alerts we pass a "synthetic" source document in to buildAlert though, and...
This should also fix https://github.com/elastic/kibana/issues/138254
`parallel_bulk` doesn't have any retry logic in it, each bulk action is sent exactly once regardless of network or server failures. A TransportError or BulkIndexError should be raised if a...
Update: with the merging of [this PR](https://github.com/elastic/kibana/pull/140064), the saved query behaviors have been updated to resolve most of the issues described in this issue. 1. I thought I saw the...
For the UI label, I think we should consider adding the timeframe to the name as well - `Max alerts per run`. Otherwise it may appear to users that the...
> The current behavior would have our rules error out when the config max setting for alerts was hit. I think that's a "good" outcome and a user shouldn't start...
> For example, if you have a clean ES (no docs indexed) and install a Prebuilt Rule such as ESXI Timestomping using Touch Command, then go to its Rule Editing...
> In summary: I think the behaviour should be: > - If the indices don't exist -> warning in create/edit UI, warning at rule execution time. (agree with you here)...
> Having a strict validation that validates source data (what we have now) or having a looser validation but allowing users to customize prebuilt rules (what we are suggesting to...