Is the monitor id available in trigger context about alerting HOT 7 CLOSED

Hi @ammardodin,

It's just left out of the documentation. You have access to the id as {{ctx.monitor.id}}, when testing with the preview in Kibana or "Send test message" it appears this is empty, but during actual execution it will be correctly supplied.

It does look like we have inconsistent values being passed in Kibana UI and Elasticsearch though when comparing the actual context values with what's listed on the documentation:
https://github.com/opendistro-for-elasticsearch/alerting/blob/master/alerting/src/main/kotlin/com/amazon/opendistroforelasticsearch/alerting/model/Monitor.kt#L79

from alerting.

This is a bug / discrepancy between the UI and backend documentation. Kibana is using the execute API which is providing different context variables than during actual monitor execution.

from alerting.

Unfortunately, it seems that {{ctx.monitor.id}} is rendered as an empty string. Same is true for {{ctx.alert.id}}, which is extremely problematic.

from alerting.

@ammardodin
The UI is rendering it as an empty string, but it should actually be provided in the message being sent. This is a discrepancy between Kibana plugin and Elasticsearch plugin providing different context values for the message preview. You should be able to see the actual value from your destination when clicking "send test message". If you still do not see it let me know from your destination and I can look into it more.

Edit: Looked into it a bit more. The Kibana UI is calling the Execute API with dryrun=false and no MonitorID. This is because our current logic only sends out notifications when dryrun=false, but will also save an alert if dryrun=false AND MonitorID exists. Because of this we do not have a MonitorID while in the Execute API. So when providing the monitor to the context variable, it has no MonitorID to access during the "send test message". That being said, you will have the monitor ID during an actual alert.

from alerting.

@dbbaughe to clarify, I am not using Kibana. I am using the API to create my monitors. It seems that I can access the monitor id via {{ctx.monitor._id}} not {{ctx.monitor.id}}.

As for the alert id, I still can't access it via {{ctx.alert.id}}, as that is being returned as an empty string, even though that I definitely see an active alert for the monitor in question in the .opendistro-alerting-alerts index.

To reproduce on 0.7.1 using the API:

1. Create a Slack destination.
2. Create a monitor with a truthy trigger, i.e. return true;.
3. Point monitor action to destination id from 1, and use {{ctx.alert.id}} as the action message.

from alerting.

@ammardodin,

This is what's currently provided on the monitor on the ctx variable during trigger execution and action execution. The documentation should be updated to reflect this (and this should probably provide more than just this information).

This is what's currently provided on the alert on the ctx variable. This was updated in v0.9.0 which included this PR.

The thing to be aware of though is that this is referring to the current existing alert (if one exists) during this execution. So for your very first alert there would be no alert.id because no alert exists. And the next alert would contain an alert.id of the existing alert (again, only if one exists).

from alerting.

Closing based on last comment. Feel free to reopen, if this is still an issue.

from alerting.