[Alerting Core] Add timestamp to provided template values

[jasonrhodes]

By default it looks like alerts provide alert message templates with some core values like alertId, alertName, spaceId, tags, etc. We'd also like to have a timestamp value available that represents the exact time at which the executor ran when it encountered the triggering event.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[dgieselaar]

not sure if it belongs here, but it would be useful to have @timestamp on AlertInstance as well. For instance, I have a use case where I index an annotation when firing an alert. I'd like to keep the timestamp of the annotation in sync with the alert, but I have to create my own timestamp right now (AFAICT).

[pmuellr]

not sure if it belongs here, but it would be useful to have @timestamp on AlertInstance as well. For instance, I have a use case where I index an annotation when firing an alert. I'd like to keep the timestamp of the annotation in sync with the alert, but I have to create my own timestamp right now (AFAICT).

Wow, from last May, sorry for the very delayed response.

Probably is the wrong place, but some thoughts - open a new issue for further discussion if you'd likee.

Sounds like you could maintain the timestamp in the alert instance state, or even the alert state. But it's going to be overwritten the next time the executor runs (presumably), or "erased" if the instance didn't schedule any actions, or if in the alert state, you'll have to manage the lifetime it's in the state. So I'm not sure there's much point in trying to keep that in sync. Note: the state gets destroyed when the alert is disabled, so should not be considered totally persistent.

There should be an event log record for this though. There should be an execute-action message logged before the action actually runs, so you could search for the earliest one since the timestamp of the annotation to find it.

[pmuellr]

I happened to notice that we need to add the "action group" to the top-level template variables, as well as the timestamp. Should do both at the same time, I'd guess.

Maybe poke around the alert and see if there's more?

Note that the executionStatus property is reset based on the whether instances schedule action groups, and perhaps is not set to it's "current state" by the time the values are interpolated, so that might not be a good candidate, right now.

[pmuellr]

I'm starting to look into this one, wondering what variable value the "date" should have. Currently I'm going with ISO, but that seems not very human friendly.

Perhaps we could extend the date variable to an object, with properties that are methods, that would let you select a particular timezone or date format to use; eg {{date.en_us.EST}} would give you a US-formatted date in eastern time zone. Sounds messy :-)