New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Network adapter template

Votes:

0

Your Vote:

Up

Down

I want to monitor Hyper-V host network adapters. Auto discovery find many network adapters. I tried delete needless network adapter sensors and create device template. When I make device discovery whit this template, it find all network adapters again. Any help, how edit this template?

customization device-template discovery interface network-monitor prtg

Created on Jul 26, 2016 9:59:40 AM by  svecm (0) 1

Last change on Sep 14, 2016 11:29:52 AM by  Luciano Lingnau [Paessler Support]



Best Answer

Accepted Answer

Votes:

2

Your Vote:

Up

Down

Disclaimer: This is Not an Officially Supported Feature

Thank you for the clarification.
I've checked with development and there is an unofficial way to provide a list (similar to a response file) with one entry per interface that you want to have a sensor for, to be used with Auto-Discovery. Please check the following device template for reference:

<?xml version="1.0" encoding="UTF-8"?>
  <devicetemplate id="custom" name="Custom Traffic Createdata" priority="1">
    <check id="ping" meta="ping"/>
    <check id="snmp" meta="snmp" requires="ping"/>
    <create id="snmptraffic_vEthernet" kind="snmptraffic" requires="snmp" displayname="Traffic vEthernet">
      <createdata>
		<interfacenumber>901:vEthernet</interfacenumber>
      </createdata>
    </create>
	<create id="snmptraffic_vSwitch" kind="snmptraffic" requires="snmp" displayname="Traffic vSwitch">
      <createdata>
		<interfacenumber>902:vSwitch</interfacenumber>
      </createdata>
    </create>
  </devicetemplate>

The device template above will always only add two SNMP Traffic Sensors, associated with two distict interfaces named vEthernet and vSwitch. This is only practical if you have hundreds of servers which have interfaces with exactly the same name.

Usage Notes

  • The index (901, 902) should be an interface name that doesn't exist. That causes the sensor's "Interface Index Tracking" logic to kick-in and identify the correct interface index after the first scan.
  • You'll have to use multiple <create> statements, each will contain a different <createdata> with a DIFFERENT id.
  • The <interfacenumber> must contain the name of the interface that the sensor will monitor(exactly as it shows up in the sensor's settings for an existing deployed sensor)
  • The sensors within the defined create will ALWAYS be deployed, regardless of there being an interface with the corresponding name.
  • The property provided in the </interfacenumber> should match the defined identification property from the SNMP Compatibility Options.

Related

As of recent recent PRTG versions it is possible to have a "custom meta-scan", which would allow the creation of custom rules within a metascan for interfaces:

Now that you understand how this works, it's time to go one step further and automate this. Please refer to:

Support-related notes

  • Editing templates manually is not officially supported, we can't guarantee this will always work as expected
  • We can't provide Technical Support for this features
  • This feature's behavior may change without prior notice.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Aug 2, 2016 1:35:47 PM by  Luciano Lingnau [Paessler Support]

Last change on Oct 10, 2017 7:56:58 AM by  Luciano Lingnau [Paessler Support]



7 Replies

Votes:

0

Your Vote:

Up

Down

Hello and thank you for your KB-Post.

The issue with Network Adapters is that most systems will have many, the same applies to hard disks. As PRTG doesn't know "which one you want to monitor". During an auto-discovery PRTG will query the target host for a list of existing adapters/interfaces. It will then deploy one sensor per active/existing interface. This behavior cannot be changed I'm afraid.

If you intend to perform further auto-discoveries on this device, pause the unwanted sensors instead of deleting them. They will not be deployed by further discoveries again, will have a minimal performance impact and will not count toward the total number of sensors used from the license.

This behavior is described here:


Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jul 26, 2016 2:00:44 PM by  Luciano Lingnau [Paessler Support]

Last change on Aug 2, 2016 1:47:11 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

ok, thank You. Its any other option for automatic copy existing sensors (by its id) to other devices with stored position for first deploy?

Have a nice day Marek

Created on Jul 27, 2016 1:30:39 PM by  svecm (0) 1



Votes:

0

Your Vote:

Up

Down

I have this code from other template <create id="snmptraffic13:Ethernet 213:Ethernet 213:Ethernet 213:Ethernet 213:Ethernet 2"> which add only right network adapters, but i dont know section after snmptraffic for other network interfaces.

M.

Created on Jul 27, 2016 1:33:46 PM by  svecm (0) 1



Accepted Answer

Votes:

2

Your Vote:

Up

Down

Disclaimer: This is Not an Officially Supported Feature

Thank you for the clarification.
I've checked with development and there is an unofficial way to provide a list (similar to a response file) with one entry per interface that you want to have a sensor for, to be used with Auto-Discovery. Please check the following device template for reference:

<?xml version="1.0" encoding="UTF-8"?>
  <devicetemplate id="custom" name="Custom Traffic Createdata" priority="1">
    <check id="ping" meta="ping"/>
    <check id="snmp" meta="snmp" requires="ping"/>
    <create id="snmptraffic_vEthernet" kind="snmptraffic" requires="snmp" displayname="Traffic vEthernet">
      <createdata>
		<interfacenumber>901:vEthernet</interfacenumber>
      </createdata>
    </create>
	<create id="snmptraffic_vSwitch" kind="snmptraffic" requires="snmp" displayname="Traffic vSwitch">
      <createdata>
		<interfacenumber>902:vSwitch</interfacenumber>
      </createdata>
    </create>
  </devicetemplate>

The device template above will always only add two SNMP Traffic Sensors, associated with two distict interfaces named vEthernet and vSwitch. This is only practical if you have hundreds of servers which have interfaces with exactly the same name.

Usage Notes

  • The index (901, 902) should be an interface name that doesn't exist. That causes the sensor's "Interface Index Tracking" logic to kick-in and identify the correct interface index after the first scan.
  • You'll have to use multiple <create> statements, each will contain a different <createdata> with a DIFFERENT id.
  • The <interfacenumber> must contain the name of the interface that the sensor will monitor(exactly as it shows up in the sensor's settings for an existing deployed sensor)
  • The sensors within the defined create will ALWAYS be deployed, regardless of there being an interface with the corresponding name.
  • The property provided in the </interfacenumber> should match the defined identification property from the SNMP Compatibility Options.

Related

As of recent recent PRTG versions it is possible to have a "custom meta-scan", which would allow the creation of custom rules within a metascan for interfaces:

Now that you understand how this works, it's time to go one step further and automate this. Please refer to:

Support-related notes

  • Editing templates manually is not officially supported, we can't guarantee this will always work as expected
  • We can't provide Technical Support for this features
  • This feature's behavior may change without prior notice.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Aug 2, 2016 1:35:47 PM by  Luciano Lingnau [Paessler Support]

Last change on Oct 10, 2017 7:56:58 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Disclaimer: This is Not an Officially Supported Feature

Remarks

  • Requires snmpwalk.exe from net-snmp to work.

As of PRTG version 17.1.33 it should be possible to use generic meta-scans with the SNMP Traffic sensor. This effectively allows one to deploy only the sensors for specific interfaces. Here's the relevant data for an example:

\devicetemplates\Custom Traffic CustomMeta.odt
<?xml version="1.0" encoding="UTF-8"?>
  <devicetemplate id="custom" name="Custom Traffic CustomMeta" priority="1">
    <check id="ping" meta="ping"/>
    <check id="snmp" meta="snmp" requires="ping"/>
    <create id="snmptraffic" kind="snmptraffic" meta="customexexmlgeneric" requires="snmp" displayname="SNMP Traffic">
    <metadata>
      <exefile>snmp_traffic_metascan.ps1</exefile>
	  <exeparams>-deviceaddress '%host' -filterstring '*(paessler.de)'</exeparams>
    </metadata>
    </create>
  </devicetemplate>

In this file you can define what sort of filter will be used (this example is based on the interface name). -filterstring '*(paessler.de)' defines that only interfaces who's name ends in (paessler.de).

snmp_traffic_metascan.ps1
param(
    $deviceaddress = "localhost",
	$filterstring = "*Ethernet*"
    )

# Store the output in the variable $data
$data = snmpwalk.exe -v 2c -c "public" -"OQ" $deviceaddress .1.3.6.1.2.1.31.1.1.1.18
$interfaceList = @()

#Add results to object
FOREACH ($line in $data)
{
    
    # Remove the whitespace at the beginning on the line and Split on whitespaces characteres
    $line = $line -replace '^([^.]*).', ''
    $line = $line -split '\s=\s'
    
    # Define Properties
    $properties = @{
        if_index = $line[0]
        if_name = $line[1]
    }
    
    # Add to object
    $interface = New-Object -TypeName PSObject -Property $properties
    $interfaceList += $interface
}

Write-Output "<?xml version=`"1.0`" encoding=`"UTF-8`"?>"
Write-Output "<prtg>"

foreach ($entry in $interfaceList| Where-Object {$_.if_name -like $filterstring}){
    
    #Where the magic happens
    Write-Output "<item>"
	Write-Output "<name>($($entry.if_index)) $($entry.if_name) Traffic</name>"
    Write-Output "<interfacenumber>$($entry.if_index):$($entry.if_name)</interfacenumber>"
    Write-Output "</item>"

}

Write-Output "</prtg>"

This file defines the actual processing and rules, it's output determinates which interfaces will be created/deployed.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jul 21, 2017 1:57:41 PM by  Luciano Lingnau [Paessler Support]

Last change on May 10, 2018 8:13:55 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear Support
I have done exactly what is mentioned here , yet an auto discovery with a custom template is not giving any result. This is a major and critical issue for us. Our case:
We have 86 Juniper MX routers in our network, and a regular autodiscovery would yield +2000 SNMP traffic sensor per device since the integrated "PortScan" Meta Scan is inculing all VLANs under each physical interface as separate entries:

for example:

ae1 ==>PHYSICAL

>LOGIAL

ae1.1369
ae1.1593
ae1.1817
ae1.2261
ae1.2262
ae1.2392
ae1.2541
ae1.2668
ae1.3261
ae1.3262
ae1.32767
ae1.3392
ae1.3768
ae1.3820
ae1.3821
ae1.3822
ae1.3823
ae1.4070
ae1.487 ... ETC

We are not interested to view all interfaces with "." suffix.

Imagine integrating these 86 routers, we would end up with 172000 SNMP traffic sensor which is something that would kill PRTG and there isn't any PRTG setup that can withstand such number.

We are upgrading our license now from XL1 to XL5, yet this limitation is killing the use of your system.

All other competitor tools have the option to add a rule for any Autodiscovery on Device/iNTERFACE levels.

Please support us on this since your reply would be the final decision for us if we should cancel PRTG upgrade and move for another Tool.

Appreciating your reply

Created on May 16, 2018 6:46:00 AM by  Ehab (0)

Last change on May 16, 2018 11:50:57 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Following up with Ehab via E-mail. We'll have to have a much closer look at the data and behavior to find out what is going on.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on May 17, 2018 11:26:20 AM by  Luciano Lingnau [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.