Hmm, that theory makes a lot of sense. Since I have also seen files like e-series-dcuriolat,vnet.rrd which looks like it comes from the ifstat section.
But of course, that would be too easy. :-) I am also seeing e-series-dmaxiolat,syndev72.rrd And syndev72 is the hostname of a system completely unrelated to the test where I am seeing the issues. There are a few others like that which have hostnames in them.
I am also seeing the likes of e-series-dcuriolat,vdc1.rrd There are only 2 hosts throwing out "vdc?" data points, and they also has nothing to do with the e-series. The vdc? is from another custom script, which logs and graphs the % busy of LUNs on 2 servers that are sensitive to disk latency fluctuation.
These hosts all have nothing at all to do with the storage arrays being monitored, which makes me think the client data might be a red herring.
I have asked Martin if he's seeing the same issue, but he hasn't got back to me yet.
The Xymon version I have here is 4.3.12, but I have also seen it at my other customers on version 4.3.17 and 4.3.18 (although to a far lesser degree)
Regards Vernon
On 25 February 2015 at 12:30, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
Yes, I'd be surprised if it's a problem in the script.
On 25 February 2015 at 14:40, Vernon Everett <everett.vernon at gmail.com> wrote:
e-series-dcuriolat,ipv6OutFragFails.rrd e-series-dcuriolat,UDP_udpInDatagrams.rrd e-series-dcuriolat,udpInCksumErrs.rrd
These all look to be coming from the [netstat] client data. Perhaps have a look at the server's client data, scan through to the [netstat] section, and see if there are an unusual characters or corruption, either within [netstat] or the sections before and after it.
I'm not sure what you'd be looking for, but worth a look.
J
-- "Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton