Search code examples
rrdtoolrrdmrtg

MRTG: rrdtool xport - Problems with exporting in/out traffic


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:[email protected]:
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!


Solution

  • 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.