topic DQL - Need to split network i/o process metrics for azure VMs in a dt.entity.process_group in DQL

DQL - Need to split network i/o process metrics for azure VMs in a dt.entity.process_group

jstead — Thu, 12 Dec 2024 12:04:08 GMT

Hello

I am trying to create a DQL query for a dashboard that can output process network I/O metrics (dt.process.network.bytes_rx and dt.process.network.bytes_tx) for two pairs of Azure virtual machines (with OneAgent installed) that run the same service (named) in the same network. Dynatrace has automatically created a process group for named which contains all four virtual machines, however I only want to query two virtual machines from the process group. I don't want to query using the hosts name because dynatrace has created a unique name that will be updated regularly but instead I want to use the Azure resource name (azure.vm.name). Can this be done?

Thanks

VM names:

Pair one: npd-uk-pri00-abc(abc is changed regularly to a random string)

Pair two: npd-uk-sec00-abc(abc is changed regularly to a random string)

Re: DQL - Need to split network i/o process metrics for azure VMs in a dt.entity.process_group

krzysztof_hoja — Mon, 16 Dec 2024 20:21:58 GMT

To achieve this you need to have your metrics also by host and then using entity model relationships connect host to Azure VMs.

Example of such query:

timeseries {rx=sum(dt.process.network.bytes_rx), tx=sum(dt.process.network.bytes_tx)}, by: {dt.entity.host, dt.entity.process_group}, filter: dt.entity.process_group=="PROCESS_GROUP-0EA1068B7FD50946" | fieldsAdd entityAttr(dt.entity.host,"runs_on") | fieldsAdd dt.entity.azure_vm=dt.entity.host.runs_on[dt.entity.azure_vm] | fieldsAdd entityName(dt.entity.azure_vm)

get metrics by process group and host for chosen PG
search for related VMs using runs_on[dt.entity.azure_vm] relationship
get name for each VM

Result looks like this on my environment:

Re: DQL - Need to split network i/o process metrics for azure VMs in a dt.entity.process_group

jstead — Mon, 27 Jan 2025 16:11:59 GMT

Really useful @krzysztof_hoja, this helped sort the issue. Thanks very much.