[RAC] Change @timestamp value to be last updated

[jasonrhodes]

📝 Summary

The Observability Alerts table's at the moment has a Triggered column, which reads the value from kibana.alert.start

✔️ Acceptance criteria

• this column should read the timestamp value (last updated for that alert document) and not the "triggered" value that we read from now.
• the label should be updated to Last updated

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[mgiota]

@jasonrhodes I'll update the value to be read from kibana.alert.rule.updated_at.

Regarding the label we display in the header I had last updated in my mind, but security uses @timestamp, so maybe we should be consistent with them. What did you have in mind?

cc @mdefazio @weltenwort

[weltenwort]

"Last Updated" seems most descriptive to me. In contrast, "@timestamp" doesn't convey the meaning of the point in time.

[mdefazio]

If my thinking is correct, Security won't benefit from a 'Last updated' label. Their alerts will occur at a specific point in time and live on until an action is done on them. So timestamp makes sense for them. I get this is different for Obs alert classes.

So I'm open to discuss how to try and keep consistency here but obviously try and be clear enough. Would duration go off last updated? Would last updated change only between alert groups (Warning --> Critical --> Warning)?

[mgiota]

@weltenwort I am checking the implementation and at the moment we don't index kibana.alert.rule.updated_at. Let's quickly bring this into our today's rac sync. @mdefazio Good points, we'll discuss further today

[weltenwort]

Isn't @timestamp updated on every change?

kibana/x-pack/plugins/rule_registry/server/utils/create_lifecycle_executor.ts

Line 248 in eca7146

[TIMESTAMP]: timestamp,

[mgiota]

Yep I just realized this, so I can use the @timestamp field

[katrin-freihofner]

Related: #108035

[mgiota]

Related: #107639