Showing results for 
Show  only  | Search instead for 
Did you mean: 

Azure Metric Events management report - Azure Resources served by Metric Events

We have Dynatrace integration with Azure in my company, but because it is a giant company with "x" Azure resources, we are faced with a difficulty in easily, practically and automatically obtaining which alerts are enabled by Azure resource and in which settings these alerts are adjusted (I mean a more automatic way than manually entering the alert and checking which threshold is set), I mean a management view of the part of alerts focusing on Azure resources. We know that the integration is active, that the resources are being monitored by Dynatrace, but we don't have management information about which Metric Events are serving a certain resource/entityid from Azure. In order to get to this type of management report, it would be necessary to obtain the resource information using some Dynatrace APIs and from there prepare a logic/automation that would deliver this management vision. Has anyone on this forum had a similar experience/need?


Dynatrace Champion
Dynatrace Champion

Hey Heloisa,

I have not come across a need for this before however I would suggest coming up with some sort of naming rule for metric events to make them easier to sort through. For example (cloud - app - entity - description) which would become (AWS - Easytravel - DB - high failure rate). It doesn't have to be that exactly, if you only use/monitor azure then cloud wouldn't be necessary. Since the list of metric events is in alphabetical order you would get metric events grouped by cloud, app and entity allowing for easier navigation.

If you're interested in building something you could use the settings API to request all of the metric events and then filter for the metric expression field and go digging in there for entity IDs however that seems like a hellish task. To see an example of using the API in the top right of the page there is an option for that or you can also check out the swagger to play around with API calls



Working with the Metric Event naming pattern(we have already worked with a pattern similar to what you indicated) would not be as effective when we have filters within Metric Events, for example, I may be using an alert for only a few Azure resources that have the "x" tag, or I may have some alert with the custom Metric Selector (not covering all resources of a resource type). So we were looking for a managerial view of what Azure resources particular Metric Events is covering.

Featured Posts