Simple look at OMS Alert Remediation with Runbooks: Part 2

  • Article

Alerting in OMS was recently updated with the GA release. One of the great features this offers is the ability to automatically trigger an Azure Automation Runbook.

There are already some great blogs out there, but in this series I wanted to take a simple look how this works, now it's generally available.

Link to Part 1

Link to Part 3

Working with alert data

In the first blog, we saw how to trigger a Runbook from an OMS Alert.

In this blog, we'll look at the output data & how to extract useful information.

Step 1: Reading $WebhookData.RequestBody

In the last blog, we saw that all the useful info was in $WebhokData.Requestbody.

This looked a little cryptic, something like the below. Probably not what you want to read when sipping your morning coffee J

 

This is JSON data & we can easily parse this out in our Runbook. However, before we do that, let's just take a look at this info.

To read it manually, I did the following to make it easier:

  • Copied the $WebhokData.Requestbody info from the Output screen
  • Pasted it into a Visual Studio Code
  • Saved as output.json
  • Formatted the code (Alt Shift F) so it's easier to read!

 

Now that's easier to look at! I've highlighted some of the useful bits below:

  • All of the content is inside SearchResults
  • In Green, you can see there are 2 main sections:
    • __metadata shows us some metadata about the OMS search
    • value: This contains the actual event
  • In Red you can see I've pulled out specifics, such as the Computer the event was on, the event log, the event ID & we can see the contents in the ParameterXml.

 

 

Step 2: Parsing the RequestBody

How do we read this JSON data & make use of it in our Runbook? Luckily PowerShell is to the rescue here!

This output is JSON formatted data, so all we need to do, is use the ConvertFrom-Json cmdlet.

Next up, I'm going to go back to my OMSAlertTrigger Runbook & click Edit.

First up, I will get delete $WebhookData.WebhookName and $WebhookData.RequestHeader, as I don't care about those right now.

Next, I'll use ConvertFrom-Json to load the RequestBody into a PowerShell object. This makes it much easier to navigate through the JSON.

For example, below we get the converted JSON and put it in $alertData

$alertData = ConvertFrom-Json $WebhookData.RequestBody

I can now navigate to the EventID using $alertData.SearchResults.value.EventID

 

Before I complete this, I've got two scenarios I want to cope with:

  • What if the WebhookData is empty
  • What if there are more than 1 alerts passed in the results (multiple value tags in the JSON)

 

Taking this into consideration, here's my new OMSAlertTrigger Runbook. A few notes:

  • Line 5: We check the WebhookData isn't null. If it is, we write an error
  • Line 6: Converts the JSON data into a PowerShell object
  • Line 8: In case there are multiple alerts, we loop through each value in the SearchResults
  • Line 9: I've selected a few elements from the JSON and written them out in a friendly way

 

Save & Publish the new Runbook!

 

Step 3: Trigger the updated Runbook

As before, I'll trigger the Runbook by manually raising event 123 on one of my OMS managed machines. I ran this several times, to rest out multiple alerts:

Write-EventLog -LogName Application -Source MsiInstaller -EventId 123 -Message "hello"

I'll wait for a moment to get the Alert notification, then check the Runbook Job in the portal.

 

Now if we look at the Job Output, we can see I raised the event 123 four times on the computer SQL.contoso.work.

The OMS Alert picked this up had occurred 4 times, so triggered the Runbook with al 4 alerts in the Web hook Data.

In the output, we can see that we parsed out each alert & wrote the output in a friendly way:

 

Great! So, now we know how to trigger the Runbook and read out the alert details in a straightforward way.

What other cool stuff can we do with this capability? That's what we'll look at in part 3