In Azure Application Insights Alerts we have configured Webhooks to send Json Payload to ServiceNow (third party ticket generation app). Alerts are fired and we can view that on Azure Portal but is there anyway to know what was the PAYLOAD that was sent at that specific time when the Alert was fired. I can see the history of the Alerts fired but there is no view/information on what was the payload that was generated and sent thru webhook.
is it possible?
You can view the alert's payload by running a query against the Alerts Management REST API: https://learn.microsoft.com/en-us/rest/api/monitor/alertsmanagement/alerts/getbyid
If you're using the common alerts schema, the payload you'll get is exactly the one that was sent through the webhook. Otherwise, some fields might appear under the 'essentials' section instead of under the 'context' section.
Related
I am sure this has been asked many times but am unable to find relevant answer. Is there any way to send Azure monitor alerts to slack via Logic apps or some other way. I have found this template - https://github.com/Azure/azure-quickstart-templates/tree/master/demos/alert-to-slack-with-logic-app and integrated it into my azure system but it is not working.
Have tried some work around mentioned at - https://github.com/Azure/azure-quickstart-templates/issues/3319 but all in vain
Direct Webhook from action group using slack incoming webhook is not supported , as azure sends alert using its own schema.
Any input is highly appreciated ...
Azure Logic Apps is definitely an option, but if you are not needing complicated workflows, just send the alert directly from Azure Monitor to a Slack channel. You can do this by generating a unique email for the Slack channel and using that email in your Azure Monitor alert action group settings. Another option would be to send the alert to your company alert email inbox and have it automatically forwarded to that Slack channel email address. With this approach you completely remove the dependency and complexity of Azure Logic Apps.
https://slack.com/help/articles/206819278-Send-emails-to-Slack#h_01F4WDZG8RTCTNAMR4KJ7D419V
I am using service that can only send messages using webhook. The only thing I can set up in that webhook are HTTP endpoint, user name and password (you can see it on the screenshot below). I would like to send messages to my event hub, but I don't know how to find its HTTP endpoint. The only thing I could find was SAS Endpoint.
Event Hubs offers a REST API that allows you to perform a subset of the operations supported by its AMQP API. Publishing basic events via REST is possible and would use the endpoint: https://{servicebusNamespace}.servicebus.windows.net/{eventHubPath}/messages.
The full set of documentation for the REST API can be found here, and the specifics for sending events here.
I have an Azure alerts action group set up which sends an email to myself and 5 colleagues. No problem at all, we all receive the email.
In the same action group I have created another action this time as a Webhook instead of Email/SMS. The webhook URL that I am providing is for a Microsoft Team's channel which has the "Incoming Webhook" connector configured.
When alerts fire and the action group is alerted, the webhook does not appear to be working. Unfortunately, given the restraints of Azure, I cannot actually see any errors or attempts when sending to the webhook.
Anybody else encountered this issue?
Someone else had an issue around this a few weeks ago, perhaps your issue is the same - please check Azure Monitor Alerts using webhook to Microsoft Teams - No messages to Teams
I have an Alert configured to my app service. Consider I have server down check alert.
Whenever the alert gets triggered , I want the mail to be delivered to our mailbox with sufficient details. To achieve this, Iam directly calling the sendgrid api from Azure Alert Webhook. Im able to send mail with hardcoded data. I would want to utilise the details , Azure Alert possess, to include in the mail.
Webhook url is as follow:
https://api.sendgrid.com/api/mail.send.json?api_user=********&api_key=****&to=*****&toname=*&subject=&text=#workspaceid%20#applicationid&from=**
"#workspaceid" is a parameter of json that is being sent.
However the approach does not work.
I would like to have entire json content that is initiated by Azure alerts to be included in mail body.
The JSON payload send by the alert needs to be parsed, somehow, and sent onwards to SendGrid. I haven't found any way to do this elegantly, so that you could just call a parameter from the JSON and pass it along the mail call.
However, there are still way we could build this :)
Microsoft Flow
Using a flow we can trigger it from a HTTP request and have it parse the input. Once the input is parsed we can get the relevant parameters and form the SendGrid URL for sending the email.
This approach is a bit more involved but it opens a lot more doors for setting up all kinds of logic an alert could trigger.
See this link for how to create a flow triggered from a HTTP request.
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..