You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a timestamp override field is defined for detection engine rules, @timestamp is always added automatically as a fallback timestamp field. This is useful in cases where multiple data sources are being queried by the same rule, but not all data sources populate the timestamp override field. However, in other cases @timestamp may be completely unreliable and we would like to avoid querying it at all. We should make the @timestamp fallback behavior more configurable, perhaps allowing multiple timestamp overrides to be defined or creating a flag that disables the fallback.
These changes allow user to configure @timestamp fallback when timestamp override is defined. There is a new checkbox which allows to disable fallback to @timestamp when Timestamp Override is defined.
For the 8.4 release, we need to update documentation for the security rule creation. We added a new optional configuration parameter timestamp_override_fallback_disabled in this PR as part of these ticket. The new parameter needs to be added along the timestamp_override which is listed here in the UI docs and here in the create API docs, and also the other APIs (update etc).
We also noticed that timestamp_override is listed in the wrong section there, it should be listed as optional for all rule types, not just EQL, query, and threshold. We should add the timestamp override fallback param in the same places timestamp override appears.
jmikell821
changed the title
[DOCS][8.4] Create documentation for the new configuration parameter in Create Rule flow
[DOCS][8.4] Fallback to @timestamp is configurable when timestamp override is defined
Aug 4, 2022
Issue: elastic/kibana#112315
PR: elastic/kibana#135116
Background
Currently, when a timestamp override field is defined for detection engine rules,
@timestamp
is always added automatically as a fallback timestamp field. This is useful in cases where multiple data sources are being queried by the same rule, but not all data sources populate the timestamp override field. However, in other cases@timestamp
may be completely unreliable and we would like to avoid querying it at all. We should make the@timestamp
fallback behavior more configurable, perhaps allowing multiple timestamp overrides to be defined or creating a flag that disables the fallback.These changes allow user to configure @timestamp fallback when timestamp override is defined. There is a new checkbox which allows to disable fallback to
@timestamp
when Timestamp Override is defined.For the 8.4 release, we need to update documentation for the security rule creation. We added a new optional configuration parameter
timestamp_override_fallback_disabled
in this PR as part of these ticket. The new parameter needs to be added along thetimestamp_override
which is listed here in the UI docs and here in the create API docs, and also the other APIs (update etc).We also noticed that
timestamp_override
is listed in the wrong section there, it should be listed as optional for all rule types, not just EQL, query, and threshold. We should add the timestamp override fallback param in the same places timestamp override appears.cc @joepeeples
The text was updated successfully, but these errors were encountered: