[rrd-users] What is the best strategy to count the events
Alex van den Bogaerdt
alex at vandenbogaerdt.nl
Tue Mar 29 11:52:01 CEST 2016
> I want to define an rrd to count the virus detected in my email.
> Every 5 minutes I update the rrd, usng an exact timestamp and the number
> of viruses detected in the last 300 seconds period.
This can be seen as a counter which resets itself after reading it.
The proper DS type for this is: ABSOLUTE.
See the documentation at
http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html and find "Another
usage is for things you count like number of messages since the last
You will end up with the amount of virus detected per second, during
the interval between two successive updates. If for example you have
detected only one in that 5-minute period, the resulting rate will be
0.0033333 (I rounded here from 1/300)
> What should I do for the periods with no virus? Do an update with the
> value 0 or do nothing?
Suppose in 24 hours you do not receive a virus except in the very last
interval. What do you want to log?
a) 287 intervals of 300 seconds with a rate of 0, followed by 1x 0.00333...
b) 288 intervals of 300 seconds with a rate of 0.0000116 (I rounded here
The way you describe your project, my guess is that you want (a). Thus
you will have to update even when no virus was received.
If you want (b) instead, make sure your heartbeat setting is sufficiently
large to accept such an update.
If you expect many updates of 0 virus received, you could combine these
updates and write 0 one time only (again: your heartbeat setting needs to
be large enough for that to work), followed by the update signalling one
virus. But why would you? If you count every 5 minutes, you can update
every 5 minutes also.
> And how to define the DS and the RRA so I can have the total number of
> viruses found by 2 hours slots, byfor weekly, monthly, yearly graphs?
A yearly graph using 2 hour slots will result in a graph width of 4380 or
4392 pixels. I doubt that this is what you mean and therefore interpret
your question a bit more relaxed.
To convert a rate to a total number per x seconds, multiply by x.
You have to know how much time is covered by each unit in the graph (e.g.
per pixel column) and multiply by that number. A CDEF will do that for
e.g. for 2 hours = 7200 seconds:
and then graph new instead of old.
168 columns covering exactly 604800 seconds (a week) results in 3600
seconds (one hour) per column. You would need to multiply by 3600 to show
virus per hour during the week.
Or you show 336 columns and 30 minutes per column. Or 672 times virus per
15 minutes. The multiplication number would be 1800 or 900.
30 days showing 2-hour periods per column results in 360 columns. Multiply
the rate by 7200 and you will be showing virus per 2 hours during the past
Your RRA slots should match what you want to graph. Ideally they cover the
same amount of time per unit (e.g. the 2 hours) but as long as a whole
number of RRA-intervals cover one graph time period, RRDtool should do
Notice how slots of 300 seconds will also cover 7200 seconds exactly, so
if you do not mind a bit of CPU time used at graph time, you could just
have one RRA with stepsize 300 and plenty of slots to cover one or more
years. 210528 of such slots is enough for 2 years worth of data.
If you have more than one RRA, RRDtool will still use CPU time but it will
be spread out over time, during "rrdtool update" instead of "rrdtool
graph". Do this if you generate pictures often and/or if the cpu is so
slow that generating images really take too long a time.
No matter if you consolidate at update time or at graph time, the
consolidated time intervals will always start and end a whole number times
the amount of time. Days start and end at midnight UTC, not your local
time. Also, the meaning of day in this remark is exactly 86400 seconds,
not affected by starting or ending daylight saving time. There is no such
thing as "a month", but you could display 28, 29, 30 or 31 days, in the
appropriate number of columns times 7200 seconds.
Displaying 2-hour intervals you can start and/or end your graph at a more
appropriate time, e.g. march 1 at midnight local time. But in Europe the
number of hours this month will be an odd number because of the change in
daylight saving. Options are: display one hour more, display one hour
less, display using intervals of one hour. Pick one.
More information about the rrd-users