<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic PRO TIP: Monitoring Network Device Availability with NAM and DQL in Dynatrace tips</title>
    <link>https://community.dynatrace.com/t5/Dynatrace-tips/PRO-TIP-Monitoring-Network-Device-Availability-with-NAM-and-DQL/m-p/300931#M1916</link>
    <description>&lt;DIV&gt;Hi Dynatracers,&lt;BR /&gt;We are using &lt;STRONG&gt;Dynatrace Network Availability Monitors (NAM)&lt;/STRONG&gt; to collect the availability of network devices through &lt;STRONG&gt;Ping/ICMP, DNS, and TCP checks&lt;/STRONG&gt;. NAM supports ICMP, TCP, and DNS monitor types to validate the availability of hosts, devices, and services from a network perspective.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Example of Powerful DQL I use :&amp;nbsp;&lt;BR /&gt;&lt;TABLE border="1" width="100%"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD width="100%"&gt;timeseries availability = avg(dt.synthetic.multi_protocol.request.availability),&lt;BR /&gt;by: {&lt;BR /&gt;dt.entity.multiprotocol_monitor,&lt;BR /&gt;multi_protocol.request.target_address,&lt;BR /&gt;request.target_address&lt;BR /&gt;}&lt;BR /&gt;| fieldsAdd targetAddress = coalesce(request.target_address, multi_protocol.request.target_address)&lt;BR /&gt;| lookup [&lt;BR /&gt;fetch `dt.entity.network:device`&lt;BR /&gt;| expand dt.ip_addresses&lt;BR /&gt;| fields&lt;BR /&gt;deviceId = id,&lt;BR /&gt;deviceName = entity.name,&lt;BR /&gt;lookupIp = dt.ip_addresses&lt;BR /&gt;],&lt;BR /&gt;sourceField: targetAddress,&lt;BR /&gt;lookupField: lookupIp,&lt;BR /&gt;fields: { deviceId, deviceName }&lt;BR /&gt;| fieldsAdd monitorName = entityName(dt.entity.multiprotocol_monitor)&lt;BR /&gt;| fieldsAdd deviceName = coalesce(deviceName, "No matching network device")&lt;BR /&gt;| fields monitorName, deviceName, deviceId, targetAddress, availability&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;DIV&gt;&lt;H2&gt;Result :&amp;nbsp;&lt;/H2&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="uros_djukic1_0-1781778506400.png" style="width: 400px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/33476i5273D8E22E2555CB/image-size/medium?v=v2&amp;amp;px=400" role="button" title="uros_djukic1_0-1781778506400.png" alt="uros_djukic1_0-1781778506400.png" /&gt;&lt;/span&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;FONT face="arial black,avant garde" size="4"&gt;&lt;STRONG&gt;Remark :&amp;nbsp;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;DIV&gt;Reachability is the key KPI because it measures whether the target network device or service is actually reachable from the monitoring location, regardless of the underlying protocol used: ICMP, DNS, or TCP.&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Reachability (%) = average availability of NAM requests over the selected timeframe&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/DIV&gt;&lt;H2&gt;Why Ping, DNS, and TCP Are Useful&lt;/H2&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Ping / ICMP&lt;/STRONG&gt; checks whether the device is reachable on the network.&lt;BR /&gt;In simple terms: &lt;EM&gt;Can I reach the device?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;DNS&lt;/STRONG&gt; checks whether the device or service name can be resolved correctly.&lt;BR /&gt;In simple terms: &lt;EM&gt;Does the hostname resolve to the expected IP address?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;TCP&lt;/STRONG&gt; checks whether a specific port is open and accepting connections.&lt;BR /&gt;In simple terms: &lt;EM&gt;Is the expected service actually reachable on its port?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;/DIV&gt;Conclusion :&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;DIV&gt;Ping validates network reachability, DNS validates name resolution, and TCP validates service-level accessibility. The DQL lookup then connects these checks back to the corresponding Dynatrace network device entity.&lt;BR /&gt;&lt;BR /&gt;Hope it helps,&lt;BR /&gt;Cheers!&lt;/DIV&gt;&lt;/DIV&gt;</description>
    <pubDate>Thu, 18 Jun 2026 10:30:46 GMT</pubDate>
    <dc:creator>uros_djukic1</dc:creator>
    <dc:date>2026-06-18T10:30:46Z</dc:date>
    <item>
      <title>PRO TIP: Monitoring Network Device Availability with NAM and DQL</title>
      <link>https://community.dynatrace.com/t5/Dynatrace-tips/PRO-TIP-Monitoring-Network-Device-Availability-with-NAM-and-DQL/m-p/300931#M1916</link>
      <description>&lt;DIV&gt;Hi Dynatracers,&lt;BR /&gt;We are using &lt;STRONG&gt;Dynatrace Network Availability Monitors (NAM)&lt;/STRONG&gt; to collect the availability of network devices through &lt;STRONG&gt;Ping/ICMP, DNS, and TCP checks&lt;/STRONG&gt;. NAM supports ICMP, TCP, and DNS monitor types to validate the availability of hosts, devices, and services from a network perspective.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Example of Powerful DQL I use :&amp;nbsp;&lt;BR /&gt;&lt;TABLE border="1" width="100%"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD width="100%"&gt;timeseries availability = avg(dt.synthetic.multi_protocol.request.availability),&lt;BR /&gt;by: {&lt;BR /&gt;dt.entity.multiprotocol_monitor,&lt;BR /&gt;multi_protocol.request.target_address,&lt;BR /&gt;request.target_address&lt;BR /&gt;}&lt;BR /&gt;| fieldsAdd targetAddress = coalesce(request.target_address, multi_protocol.request.target_address)&lt;BR /&gt;| lookup [&lt;BR /&gt;fetch `dt.entity.network:device`&lt;BR /&gt;| expand dt.ip_addresses&lt;BR /&gt;| fields&lt;BR /&gt;deviceId = id,&lt;BR /&gt;deviceName = entity.name,&lt;BR /&gt;lookupIp = dt.ip_addresses&lt;BR /&gt;],&lt;BR /&gt;sourceField: targetAddress,&lt;BR /&gt;lookupField: lookupIp,&lt;BR /&gt;fields: { deviceId, deviceName }&lt;BR /&gt;| fieldsAdd monitorName = entityName(dt.entity.multiprotocol_monitor)&lt;BR /&gt;| fieldsAdd deviceName = coalesce(deviceName, "No matching network device")&lt;BR /&gt;| fields monitorName, deviceName, deviceId, targetAddress, availability&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;DIV&gt;&lt;H2&gt;Result :&amp;nbsp;&lt;/H2&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="uros_djukic1_0-1781778506400.png" style="width: 400px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/33476i5273D8E22E2555CB/image-size/medium?v=v2&amp;amp;px=400" role="button" title="uros_djukic1_0-1781778506400.png" alt="uros_djukic1_0-1781778506400.png" /&gt;&lt;/span&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;FONT face="arial black,avant garde" size="4"&gt;&lt;STRONG&gt;Remark :&amp;nbsp;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;DIV&gt;Reachability is the key KPI because it measures whether the target network device or service is actually reachable from the monitoring location, regardless of the underlying protocol used: ICMP, DNS, or TCP.&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Reachability (%) = average availability of NAM requests over the selected timeframe&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/DIV&gt;&lt;H2&gt;Why Ping, DNS, and TCP Are Useful&lt;/H2&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Ping / ICMP&lt;/STRONG&gt; checks whether the device is reachable on the network.&lt;BR /&gt;In simple terms: &lt;EM&gt;Can I reach the device?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;DNS&lt;/STRONG&gt; checks whether the device or service name can be resolved correctly.&lt;BR /&gt;In simple terms: &lt;EM&gt;Does the hostname resolve to the expected IP address?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;TCP&lt;/STRONG&gt; checks whether a specific port is open and accepting connections.&lt;BR /&gt;In simple terms: &lt;EM&gt;Is the expected service actually reachable on its port?&lt;/EM&gt;&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;/DIV&gt;Conclusion :&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;DIV&gt;Ping validates network reachability, DNS validates name resolution, and TCP validates service-level accessibility. The DQL lookup then connects these checks back to the corresponding Dynatrace network device entity.&lt;BR /&gt;&lt;BR /&gt;Hope it helps,&lt;BR /&gt;Cheers!&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Thu, 18 Jun 2026 10:30:46 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Dynatrace-tips/PRO-TIP-Monitoring-Network-Device-Availability-with-NAM-and-DQL/m-p/300931#M1916</guid>
      <dc:creator>uros_djukic1</dc:creator>
      <dc:date>2026-06-18T10:30:46Z</dc:date>
    </item>
  </channel>
</rss>

