0

I want to monitor + export in/out traffic data to XML with MRTG and rrdtool xport. I have several problems:

  • The exported XML has the same timestamp for start and end in the meta section. I specified --start 1429862400 --end 1429894800, the output values start at 1429862700 and end at 1429886100, also I'm getting quite a few NaNs.

  • I mapped ds0 and ds1 to my in/out variables, but I'm not actually sure where to define ds's in the first place. How can I map my variables to network in and out traffic? Where are the ds-devices configured?

    • Ds1, probably because not properly configured, produces faulty values.

I'm running

rrdtool xport\
DEF:out_bytes=localhost_2.rrd:ds0:AVERAGEDEF:in_bytes\
=localhost_2.rrd:ds1:AVERAGE CDEF:io_bytes=out_bytes,in_bytes,+\ 
XPORT:in_bytes:outbytes XPORT:out_bytes:inbytes XPORT:io_bytes:iobytes\ 
--enumds --start 1429862400 --end 1429894800

to export.

This is my mrtg.cfg

WorkDir: /var/www/mrtg/graph
WriteExpires: Yes
Title[^]: Traffic Analysis for
EnableIPv6: no
Target[localhost_2]: 2:public@127.0.0.1:
SetEnv[localhost_2]: MRTG_INT_IP="No Ip" MRTG_INT_DESCR="eth0"
MaxBytes[localhost_2]: 1250000
Title[localhost_2]: Traffic Analysis for 2 -- SMDSP01
XSize[localhost_2]: 256
YSize[localhost_2]: 64
XScale[localhost_2]: 0.65
YScale[localhost_2]: 0.6
Unscaled[localhost_2]: d
WithPeak[localhost_2]: d

Here's a snipped of the output

<?xml version="1.0" encoding="UTF-8"?> <xport>    <meta>
      <start>1429862700</start>
      <step>300</step>
      <end>1429862700</end>
      <rows>109</rows>
      <columns>3</columns>
      <legend>
         <entry>outbytes</entry>
         <entry>inbytes</entry>
         <entry>iobytes</entry>
      </legend>    </meta>    <data>
      <row>
         <t>1429862700</t>
         <v0>7.5489722222e+00</v0>
         <v1>1.4522986944e+05</v1>
         <v2>1.4523741842e+05</v2>
      </row>
      <row>
         <t>1429863000</t>
         <v0>9.3254770432e+00</v0>
         <v1>1.6219456095e+05</v1>
         <v2>1.6220388643e+05</v2>
      </row>
      <row>
         <t>1429863300</t>
         <v0>6.4311896235e+00</v0>
         <v1>1.6358109508e+05</v1>
         <v2>1.6358752627e+05</v2>
      </row>
      <row>
         <t>1429863600</t>
         <v0>9.8945000000e+00</v0>
         <v1>4.6888782408e+05</v1>
         <v2>4.6889771858e+05</v2>
      </row>
      <row>
         <t>1429863900</t>
         <v0>5.6088333333e+00</v0>
         <v1>4.2072387378e+05</v1>
         <v2>4.2072948261e+05</v2>
      </row>
      <row>
         <t>1429864200</t>
         <v0>2.0383366480e+01</v0>
         <v1>2.5505514117e+05</v1>
         <v2>2.5507552453e+05</v2>
      </row>
      <row>
         <t>1429864500</t>
         <v0>1.2132332724e+03</v0>
         <v1>2.1026807079e+06</v1>
         <v2>2.1038939412e+06</v2>
      </row>
      <row>
         <t>1429864800</t>
         <v0>2.3604750000e+01</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429865100</t>
         <v0>6.3642958611e+03</v0>
         <v1>1.1198971143e+07</v1>
         <v2>1.1205335438e+07</v2>
      </row>
      <row>
         <t>1429865400</t>
         <v0>1.5586544194e+04</v0>
         <v1>8.5607161284e+06</v1>
         <v2>8.5763026726e+06</v2>
      </row>
      <row>
         <t>1429865700</t>
         <v0>2.4014277778e+01</v0>
         <v1>3.3303833329e+06</v1>
         <v2>3.3304073472e+06</v2>
      </row>
      ...
      <row>
         <t>1429892100</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429892400</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429892700</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429893000</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429893300</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429893600</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429893900</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429894200</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429894500</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429894800</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>
      <row>
         <t>1429895100</t>
         <v0>NaN</v0>
         <v1>NaN</v1>
         <v2>NaN</v2>
      </row>    </data> </xport>

Thanks for your help!

Simon Lischka
  • 155
  • 12

1 Answers1

0

Firstly, the invalid <end> tag in the XML output is a bug in RRDTool. You do not say which version you are using, but if you are not using the latest, please upgrade. If you ARE using the latest, please report a bug :)

The output time points are slightly off from your requested window because of fenceposting. You're specifying the data points, and are exporting the RRA containing them (which will end 1 step later). This is a bit counterintuitive but I think it is by design.

You are defining your variable DEFs from your RRD DSs thus:

DEF:out_bytes=localhost_2.rrd:ds0:AVERAGE
DEF:in_bytes=localhost_2.rrd:ds1:AVERAGE

An RRD file generated by MRTG will always have exactly two DSs -- called ds0 and ds1. Although RRDTool can support many more DSs with all sorts of names, you cannot change the names in an MRTG-generated RRD file, not can you add or remove a DS, without breaking MRTG. If you want to have more DSs, the only way to do it is to add a new MRTG Target -- which will create a new RRD file, with DSs 'ds0' and 'ds1' -- and then add this to your Xport request as an addiitonal two DEF lines.

The NaNs are where the underlying RRA does not have valid data. This is likely because there simply has not been (enough) data collected for that time window, or the collected data were invalid. The corresponding MRTG graphs will likely show nothing as well. Another possibility is that the wrong RRA is being selected, but this is unlikely as your time window is only 9hr which fits fine into the default 1-day high-granularity RRA generated by MRTG.

If your values are faulty, then verify that they are not faulty in the RRD already - xport only outputs what is in the database. Are you expecting an output in Bits and not Bytes (in which case multiply by 8)? Are you values around 140Mbps (IE 18MBps) but you are querying via SNMPv1 in which case MRTG is unable to poll the data? In this case, use SNMPv2 with MRTG to fetch the correct data. Unfortunately you have not given any details how the data are 'faulty' so I can only speculate.

Steve Shipway
  • 3,754
  • 3
  • 22
  • 39
  • Thanks for the reply! I'm going to check out if there's any update available and if not report the bug. Very good to know about fenceposting, I guess then the output time range is within the normal. Is the mapping of ds0 and ds1 documented somewhere? Can I safely assume its ds0 for out traffic and ds1 for in traffic? Faulty values: I tried a 1GB upl but didn't find any peaks in the out values. Generally upload seems to be unreasonably low, even considering network limitations. Will dig into SNMPv2 and see if it changes anything. – Simon Lischka May 04 '15 at 09:10
  • For an MRTG-generated RRD file, ds0 will always be the 'in' or first OID in the Target definition; ds1 will always be the 'out' or second OID in the Target. – Steve Shipway May 05 '15 at 03:44
  • Okay, thanks for the clarifications, was of great help! – Simon Lischka May 07 '15 at 18:07