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)...
'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.
Add comment