RRDtool databases are primarily used for monitoring purposes and hence are very simple in structure.
After this time the archive will “wrap around”: the next insertion will overwrite the oldest entry. This behavior is sometimes referred to as “round-robin” and is the reason for the program's name.
To cover several timespans and/or use several consolidation functions, an RRD file may contain multiple RRAs. The data retrieval function of RRDtool automatically selects the archive with the highest resolution that still covers the requested timespan. This mechanism is also used by RRDtool's graphing subsystem.
step A time-variable data in intervals of a certain length.
primary data point (PDP) The value for a specific step, that has been interpolated
consolidation function (CF) Used to conolidate multiple primary data points (PDPs). Typical consolidation functions are average, minimum, maximum.
consolidated data point (CDP) The result of multiple primary data points (PDPs) after having a consolidation function (CF) applied to them.
round-robin archive (RRA) Stores a fixed amount of CDPs and specifies how many PDPs should be consolidated in to one CDP and which CF to use.
round-robin database (RRD) A database that contains multiple RRAs.
"NaN" stands for "Not A Number"
"U" or "UNKN" - UNKNOWN
rrdtool create target.rrd \
--start 1023654125 \
--step 300 \
Target.rrd - database name (file)
1'023'654'125 - Starttime is a total number of seconds since epoch (time in seconds since 01-01-1970).
While updating the database, the update time is also specified.
This update time MUST be large (later) then start time and MUST be in seconds since epoch.
Step of 300 seconds - indicates that database expects new values every 300 seconds.
The wrapper script should be scheduled to run every step seconds so that it updates the database every step seconds.
DS (Data Source) is the actual variable which relates to the parameter on the device that is monitored.
There can be as many DSs in a database as needed.
After every step interval, a new value of DS is supplied to update the database.
DS syntax is:
DS:variable_name:DST:heartbeat:min:maxDST (Data Source Type) defines the type of the DS.
It can be COUNTER, DERIVE, ABSOLUTE, GAUGE.
COUNTER - the value is always increasing (Traffic counters on a router),
DERIVE - is the same as COUNTER, but it allows negative values as well (change in free disk space on your server)
ABSOLUTE - also saves the rate of change, but it assumes that the previous value is set to 0.
GAUGE [geid3](мера, масштаб, размер, калибр) - does not save the rate of change.
It saves the actual value itself. (Memory consumption in a server)
Heartbeat (600 seconds) - If the database does not get a new value within 300 seconds, it will wait for another 300 seconds (total 600 seconds).
If it doesn't receive any new value within 600 seconds, it will save an UNKNOWN value into the database.
This UNKNOWN value is a special feature of RRDtool - it is much better than to assume a missing value was 0 (zero)
or any other number which might also be a valid data value.
The next two parameters are the minimum and maximum value, respectively.
If the variable to be stored has predictable maximum and minimum values, this should be specified here.
Any update value falling out of this range will be stored as UNKNOWN.
RRA (round robin archive)
In the same database (RRD) it is possible to keep more round robin archives (RRAs).
RRA will hold rows CDP (consolidated data point, which is CFed (averaged, maximum/minimum value or last value) from step number of new values).
The syntax for declaring an RRA is
RRA_Name:CF:X-Files_Factor:Steps:Rows(:Timespan)CF (consolidation function) - how data is to be entered in RRA's. Can be AVERAGE, MINIMUM, MAXIMUM and LAST.
X-Files Factor - The amount of UNKNOWN data that can still be regarded as known.
Steps - How many data points are needed to put data into the RRA.
Rows - How many generations data is kept in the RRA.
Timespan - How many seconds to display in graph for this RRA.
1) "Daily" stats as is (no averages)
1 sample "averaged" stays 1 period of 5 minutes
600 samples of 5 minutes (2 days and 2 hours)
6 samples averaged become one average on 30 minutes
700 samples of 30 minutes (2 days and 2 hours, plus 12.5 days)
24 samples averaged become one average on 2 hours
775 samples of 2 hours (above + 50 days)
288 samples averaged become one average on 1 day
797 samples of 1 day (above + 732 days, rounded up to 797)
12 (steps) PDPs (DS variables) are AVERAGEed (CF) to form one CDP.
24 (rows) of theses CDPs are archived. Each PDP occurs at 300 seconds. 12 PDPs represent 12 times 300 seconds which is 1 hour. It means 1 CDP (which is equal to 12 PDPs) represents data worth 1 hour. 24 such CDPs represent 1 day (1 hour times 24 CDPs). This means, this RRA is an archive for one day. After 24 CDPs, CDP number 25 will replace the 1st CDP. The second RRA saves 31 CDPs; each CPD represents an AVERAGE value for a day (288 PDPs, each covering 300 seconds = 24 hours). Therefore this RRA is an archive for one month. A single database can have many RRAs. If there are multiple DSs, each individual RRA will save data for all the DSs in the database. For example, if a database has 3 DSs and daily, weekly, monthly, and yearly RRAs are declared, then each RRA will hold data from all 3 data sources.
SNMP Related Counters
Assume we have a device that transfers bytes to and from the Internet. This device keeps a counter that starts at zero when it is turned on, increasing with every byte that is transferred. This counter will probably have a maximum value. If this value is reached and an extra byte is counted, the counter starts over at zero. This is the same as many counters in the world such as the mileage counter in a car.
Assume a byte is eight bits and start to think in bits not bytes.
The counter, however, still counts bytes!
In the SNMP world most of the counters are 32 bits.
That means they are counting from 0 to 4294967295.
- 32 bits: (4294967295 + 1) = 4294967296 - 64 bits: (18446744073709551615 + 1)= 18446744069414584320
We will use these values in the examples. The device, when asked, returns the current value of the counter. We know the time that has passes since we last asked so we now know how many bytes have been transferred ***on average*** per second.
bps = (counter_now - counter_before) / (time_now - time_before) * 8
SNMP Data Collect Tool
snmpget device password OID snmpget -v[version] -c[password] device OID
OID means "object identifier".
When you start to learn about SNMP it looks very confusing. It isn't all that difficult when you look at the Management Information Base ("MIB"). It is an upside-down tree that describes data, with a single node as the root and from there a number of branches. These branches end up in another node, they branch out, etc. All the branches have a name and they form the path that we follow all the way down. The branches that we follow are named: iso, org, dod, internet, mgmt and mib-2. These names can also be written down as numbers and are 1 3 6 1 2 1.
iso.org.dod.internet.mgmt.mib-2 (126.96.36.199.2.1)There is a lot of confusion about the leading dot that some programs use. There is *no* leading dot in an OID. However, some programs can use the above part of OIDs as a default. To indicate the difference between abbreviated OIDs and full OIDs they need a leading dot when you specify the complete OID. Often those programs will leave out the default portion when returning the data to you. To make things worse, they have several default prefixes ...
snmpget -v2c -c public 188.8.131.52 system.sysDescr.0 # snmpget -v2c -c public cisco 184.108.40.206.4 220.127.116.11.4 interfaces.ifTable.ifEntry.ifInOctets.4 = 2290729126 interfaces.ifTable.ifEntry.ifOutOctets.4 = 1256486519