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


How do I disable the generation of "Result of Sensor XXXX.Data.txt" files?

Votes:

0

Your Vote:

Up

Down

I recently updated from v15 to v16, and now all the "EXE/Script Advanced" sensors are dumping their output in the "Logs (Sensors)" directory, even though they all are explicitly set to "Write EXE result to disk in case of error".

If I set it to "Discard EXE result" it stops generating the "Result of Sensor XXXX.Data.txt" file, but this prevents easy access to debugging info in case of erroneous output from a sensor. Also, it's quite tedious having to manually set this on every single sensor, just to enable it again if you have problems with a specific sensor.

Why doesn't the EXE/Script Advanced sensor have a setting to disable the "Result of Sensor XXXX.Data.txt" files? All other sensors have this setting, except the "EXE/Script Advanced" and "EXE/Script" sensors it seems.

There are literally hundreds of these files continuously being created on my system every minute here, and it's very frustrating not having control over the contents in the Logs directory anymore, and adds frustration to the troubleshooting process when working on new sensor scripts.

data-txt debug exe exexml logs

Created on Jun 19, 2016 4:10:26 PM by  Ivan (193) 1 1



6 Replies

Votes:

0

Your Vote:

Up

Down

Dear Ivan

The .Data.txt file should only be created together with the other .txt logfile. EXE/Script Advanced should also have an option to disable the log output. edit: This is not true, see below

It can be enabled or disabled only on a per-sensor basis. Via multi-edit, you can change this option for many sensors at the same time.

Created on Jun 21, 2016 1:47:34 PM by  Arne Seifert [Paessler Support]

Last change on Jun 22, 2016 11:48:46 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

> ...should only be created together...

It doesn't behave like that here at all.

On the systems here the data.txt is always generated every time the sensor is updated as long "Write EXE result to disk in case of error" is enabled. Just to be clear: that means even if there is no error on that sensor.

Is it only my PRTG that's misbehaving, or does this happen with others as well? (Have you tested this feature in your end recently?) Could it be that this new feature that creates data.txt is somewhat bugged and is not properly implemented on the "EXE/Script" sensors? (Could also be on other sensors. I haven't tested/noticed).

Created on Jun 21, 2016 4:02:41 PM by  Ivan (193) 1 1



Votes:

0

Your Vote:

Up

Down

Dear Ivan

We currently try to reproduce this.

Created on Jun 22, 2016 9:03:52 AM by  Arne Seifert [Paessler Support]

Last change on Jun 22, 2016 9:04:35 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear Ivan

My previous statement was wrong. The .data.txt will be written if logging is enabled at all. The reason is that this log is created prior to the sensor scan, containing data send by the core to the probe. Therefore it is unknown yet if the scan results in an error.

Created on Jun 22, 2016 11:50:15 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hmm, ok. So what purpose does the data.txt serve? Do you have an example of a situation showing how you'd use the data.txt for troubleshooting? Do you have any information on the structure of the data.txt so I can understand its contents better?

The reason for why I'm asking is because after updating from v15 to v16, all the WMI/Performance Counter sensors (example: "Windows Network Card") now have 10 minute gaps a couple of times every hour. All day. And I'm not able to figure it out. There are no problems or strange readings in the "Core Health" or "Probe Health" sensors compared to v15. It looks fairly normal. Needless to say I'm a bit wary of updating to v16 on my clients' servers as long as I cannot figure out this problem here on my test PRTG installation.

I have an example here showing a screenshot and data.txt (FYI there are no filters on this sensor)...

screenshot sensor 2704

'Result of Sensor 2704.Data.txt' at the time this gap is happening in the screenshot above: Data['blockedsens'].asString := ''; Data['canlinux'].asString := '0'; Data['channelnames'].asString := 'Traffic in'#$D#$A + '0'#$D#$A + 'Traffic out'#$D#$A + '1'#$D#$A + 'Packets'#$D#$A + '2'#$D#$A + ''; Data['counters'].asString := '\Network Interface(Realtek PCIe GBE Family Controller)\Bytes Received/sec::Count'#$D#$A + '\Network Interface(Realtek PCIe GBE Family Controller)\Bytes Sent/sec::Count'#$D#$A + '\Network Interface(Realtek PCIe GBE Family Controller)\Packets/sec::Count'#$D#$A + ''; Data['expandinstance'].asString := '0'; Data['fastcount'].asString := '10'; Data['host'].asString := '192.168.0.55'; Data['hostv6'].asString := ''; Data['inerror'].asString := ''; Data['interfaceid'].asString := 'Realtek PCIe GBE Family Controller'; Data['interfacenumber'].asString := 'Realtek PCIe GBE Family Controller'; Data['inum'].asString := ''; Data['ipversion'].asString := '0'; Data['isdifferential'].asString := '1'; Data['isexesensor'].asString := '0'; Data['ishybrid'].asString := '1'; Data['lastuptime'].asString := '0'; Data['reboot'].asString := '42542.4393020255'; Data['resultfile'].asString := 'Result of Sensor 2704.txt'; Data['rpcport'].asString := ''; Data['sensorid'].asString := '2704'; Data['simulate'].asString := '0'; Data['timeout'].asString := '90'; Data['tlsexplicit_default'].asString := ''; Data['tlsexplicit_ftp'].asString := ''; Data['tlsexplicit_imap'].asString := ''; Data['tlsexplicit_pop3'].asString := ''; Data['tlsexplicit_port'].asString := ''; Data['tlsexplicit_smtp'].asString := ''; Data['uptimecount'].asString := '0'; Data['usednstime'].asString := '0'; Data['windowslogindomain'].asString := 'SERVER'; Data['windowsloginpassword'].asString := '***'; Data['windowsloginusername'].asString := 'Username'; Data['wmiclass'].asString := 'I'; Data['wmiorpc'].asString := '3';

It's definitively not because of 32bit limitations, because it happens even when there is no real amount of traffic. And it also happens with channels that have very low counter values (i.e. Packets). I've tried bot WMI and Performance Counters. There's no warning or error (as you can see in the screenshot above), and no "No data" messages on the sensors. It just shows the last data value received like 10 minutes ago when it stopped receiving new data. I see the same problem on all sensors on that device (i.e. "Windows Physical Disk I/O"), happening at the same time in parallel. And this happens on absolutely all devices that are using PRTG's internal WMI/Perf Counter sensors. It also happens on the localhost that's running the server/probe.

So I'm unsure if it's the sensor not gathering data, or if it's the core not receiving any data. Either way I'm very stuck.

I have other sensors on the same devices that are collecting WMI data (using WMIC in batch scripts) in "EXE/Script Advanced" sensors, and they have no problems whatsoever collecting data when this happens, so it's definitively not issues with WMI on the device.

(Should I create a new KB post for this issue?)

As a final note, a separate setting to control data.txt generation would be nice so it's not controlled by the "Write EXE result to disk in case of error" setting. There's also a cosmetic issue in the mentioned configuration that controls these .txt files... the interface doesn't use the same naming convention for the data.txt and .txt files throughout its configuration webpages. Some places they file are referred to as "Result of Sensor [ID].txt" even though it's clearly a DATA.txt that's created. Example: the "Windows Network Card" sensor. Might wanna look into this as its rather confusing at times.

Created on Jun 22, 2016 1:48:40 PM by  Ivan (193) 1 1



Votes:

0

Your Vote:

Up

Down

Dear Ivan

There is no documentation available for this file, because it is intended to be used by our developers. The file logs the data the probe is getting from the core. This helps to find out why a sensor scan failed.

Seperating the .data.txt file would require another option in the interface. We really try to keep the amount of options low, even if we have to trade some flexibility for that.

About the WMI Network card sensor gaps, please open a support ticket. Please use the PRTG webinterface, menu Setup / Contact Support. Please check if the basic support bundle feature is enabled, to send us that collection of of important log files with your support ticket. Once you get the ticket confirmation email, please reply and attach one or two sensor images demonstrating the issue. Important are the overview tab and the logs tab of the sensor.

Created on Jun 23, 2016 8:43:12 AM by  Arne Seifert [Paessler Support]

Last change on Jun 23, 2016 8:45:11 AM by  Arne Seifert [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.