[Metrics UI] Add timestamp to the context parameters

[sorantis]

When alert notifications are forwarded to a queue, they might go through a few steps before getting parsed and pushed forward to event management systems. This introduces delays, which today makes it hard to understand when an alert was triggered because we don't provide the original timestamp in the notification body.

Add {{context.timestamp}} parameter to threshold alerts.

[elasticmachine]

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

[bvader]

@sorantis
Another more clear and obvious use case (and asked for)

As an Infra Operator and Alert Creator I want like to provide/construct a URL in the alert body so that I can direct the operator to a custom dashboard or Kibana App with the proper time range so that they can immediately go from alert to focused information to aid / speed diagnosis and resolution.

[sorantis]

@bvader thanks for clarifying the use case. The notification message input supports markdown it so it should be possible to provide a pretty link to a dashboard with timestamp formatted like this:
kibana/app/dashboards#/view/Metricbeat-system-overview-ecs?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:'{{context.timestamp}}'))&_a=(description:'Overview%20of%20system%20metrics',filters:!(),fullScreenMode:!f,options:(darkTheme:!f),query:(language:kuery,query:''),timeRestore:!f,title:'%5BMetrics%20System%5D%20Overview%20ECS',viewMode:view)

Metrics Explorer too:
kibana/app/metrics/explorer?metricsExplorer=(chartOptions:(stack:!f,type:area,yAxisMode:fromZero),options:(aggregation:max,filterQuery:%27%27,groupBy:host.hostname,metrics:!((aggregation:max,color:color0,field:system.load.15),(aggregation:max,color:color1,field:system.load.norm.5))),timerange:(from:%{{context.timestamp}}%27,interval:%3E%3D10s,to:now))

[jasonrhodes]

OK I'm trying to understand the order of things here.

Time A: Alert executor runs, discovers triggering value
[some amount of lag time passes?]
Time B: Action runs, with context.* values passed to template
[some other amount of lag time passes]
Time C: Receiving system gets alert, wants to know TIME A

Is the problem that we aren't giving them TIME A at all, or is the problem that when the executor runs, it may discover a triggering value outside of TIME A (earlier) somehow?

If we just need to provide TIME A, the alerting core system should know that since it knows when it runs the executor function, right? cc: @phillipb

[jasonrhodes]

Looks like the Alerting team is on board with providing the "TIME A" mentioned above, if that's what we want. See: #67389