> Hi, > > 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 update" 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 from 1/86400). 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 you. e.g. for 2 hours = 7200 seconds: CDEF:new=old,7200,* 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 30 days. 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 just fine. 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. HTH Alex _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users