Dimensions in webhook payload

Brass Contributor

Hi Azure Monitor team!
Recent blog update from 24 June mentions dimensions in fired alerts now showing better what was affected. When using common alert schema, it appears I'm starting to consistently see the actual affected device from a searchquery result in AffectedConfigurationItems. Is AffectedConfigurationItems the "best" place searchresults always will be placed in? I'm asking so that I know what part of the json webhook payload I need to go through to see what device the alert is for.

6 Replies

@-Akos- standard schema definition is service specific. Here are samples for each of the services. https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-common-schema-definitions. Please let us know if this doesn't answer your question.

Best,  Michael
-Azure Monitor Product Management

@Michael_Milirud  I've had that page sort of like a bible bookmarked and read it a number of times, but no, it doesn't say everything I need to know. With a Log Analytics query based alert, I would like to know if the AffectedConfigurationItems section will always hold the data of affected servers. I've noticed a few times that section in the json was empty, but there was data in the search results table.

 

btw, I mentioned a blog, this one was it.

 

Also, Log analytics links to the portal are supposed to be compressed, but I'm still seeing very long links in the json data.

@-Akos- I've reached out to our alerting team to get an answer for you on this. If you are still seeing uncompressed links we should take a look at your repro. Can you share a sample JSON that you are seeing with issues highlighted?

Best,  Michael

@Michael_Milirud I will send you a message offline with some json data. I may need to redact some sensitive data, but the data will be intact otherwise

@-Akos- The post was about the new 'Dimensions' section in the payload for metric measure log alert type that you control, that split the alerts and provide the context of the fired alerts.

AffectedConfigurationItems is an old and only partly reliable feature that uses heuristics of column names.  Future API version will not have AffectedConfigurationItems, but will make it easier to define dimensions even for simple count of rows.

 

There is an example here (and in the common schema definition page you have):

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-log-webhook#log-alert-for-log-a...

Hi @yalavi 

Thank you for your answer, but that is a bit of a shame. Currently I'm using this piece of code then to parse Log Analytics queries to get a list of affected machines:

        if($WebhookBody.SearchResult -ne $null){
            $SearchResultRows = $WebhookBody.SearchResult.tables[0].rows
            $SearchResultColumns = $WebhookBody.SearchResult.tables[0].columns;
            $Records = @()
            foreach ($SearchResultRow in $SearchResultRows){
                $Column = 0
                $Record = New-Object –TypeName PSObject
                foreach ($SearchResultColumn in $SearchResultColumns){
                    $Name = $SearchResultColumn.name
                    $ColumnValue = $SearchResultRow[$Column]
                    $Record | Add-Member –MemberType NoteProperty –Name $name –Value $ColumnValue -Force
                    $Column++
                }
                $Records += $Record
            }

But if I just could read out a single entry like $WebhookBody.data.alertContext.AffectedConfigurationItems it would have made life somewhat easier. 

 

The link you are referring to shows all sorts of examples that are not in the Common Alert Schema, which is what I want to avoid. I want to be able to properly parse json data, and I find it difficult enough as is. 

 

You mention a future API version; I hope enough examples will be put online on what the output will look like :smile: