Skip to content
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

[ResponseOps] improve query-result-out-of-time-range message in ES Query rule #200023

Closed
pmuellr opened this issue Nov 13, 2024 · 3 comments · Fixed by #203328
Closed

[ResponseOps] improve query-result-out-of-time-range message in ES Query rule #200023

pmuellr opened this issue Nov 13, 2024 · 3 comments · Fixed by #203328
Assignees
Labels
Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Nov 13, 2024

The ES Query rule type has some processing to try to catch the case where it is returning documents outside the time range being searched for, as part of investigating #175980:

function checkHitsForDateOutOfRange(
logger: Logger,
ruleId: string,
hits: Array<estypes.SearchHit<unknown>>,
timeField: string | undefined,
dateStart: string,
dateEnd: string,
query: unknown
) {

There are a few problems with this:

  • it's testing with the source time field, but should be using the value from fields for the time field instead. The source field can be all sorts of wacky formats, the fields value seems to be an ISO date
  • we don't need anything from the doc but the source time field, and the fields time field (as noted above)
  • in general, you can't "eyeball" this at all (not human readable), but should be machine readable (scriptable)
  • for searchSource (KQL) flavor, the field timeField seems like it will generally be filled in, but is in fact not used (time field is saved in the data view), and I've seen cases where the rule's timeField is different than what the data view uses)

Suggestions:

  • extract the time fields from the query ; start and stop of the range, plus the optional one added when you exclude matches from previous runs
  • have the comparison use the fields time, not source time
  • print all four time fields, range start, range end, fields time, exclude matches date, source time - will be "lined up" nicely for humans, followed by the query, doc not required
  • arrange to get the time field from the data view for searchSource type, rather than use the rule's field
@pmuellr pmuellr added Feature:Alerting Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Nov 13, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@mikecote
Copy link
Contributor

mikecote commented Dec 2, 2024

@pmuellr with the latest findings on the field caps behaviour, do we still this improvement at this time?

@pmuellr
Copy link
Member Author

pmuellr commented Dec 2, 2024

Thinking we at least need to mute the false positives - which would be most easily done by just deleting all that diagnostic code. Especially considering that we think we know the cause. We can always add it back later, if something else comes up ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants