1 RRDCREATE(1) rrdtool RRDCREATE(1)
6 rrdcreate - Set up a new Round Robin Database
9 r\brr\brd\bdt\bto\boo\bol\bl c\bcr\bre\bea\bat\bte\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be [-\b--\b-s\bst\bta\bar\brt\bt|-\b-b\bb _\bs_\bt_\ba_\br_\bt _\bt_\bi_\bm_\be] [-\b--\b-s\bst\bte\bep\bp|-\b-s\bs _\bs_\bt_\be_\bp]
10 [D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bD_\bS_\bT:\b:_\bd_\bs_\bt _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs] [R\bRR\bRA\bA:\b:_\bC_\bF:\b:_\bc_\bf _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs]
13 The create function of RRDtool lets you set up new Round Robin Database
20 name.
23 Specifies the time in seconds since 1970-01-01 UTC when the
25 any data timed before or at the time specified.
28 documentation for other ways to specify time.
31 Specifies the base interval in seconds with which data will be
34 D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bD_\bS_\bT:\b:_\bd_\bs_\bt _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
36 for example incoming and outgoing traffic on a specific commu-
38 some basic properties of each data source you want to store in
43 long in the characters [a-zA-Z0-9_].
46 data source entry depend on the data source type. For GAUGE,
47 COUNTER, DERIVE, and ABSOLUTE the format for a data source
48 entry is:
50 D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bG_\bA_\bU_\bG_\bE _\b| _\bC_\bO_\bU_\bN_\bT_\bE_\bR _\b| _\bD_\bE_\bR_\bI_\bV_\bE _\b| _\bA_\bB_\bS_\bO_\bL_\bU_\bT_\bE:\b:_\bh_\be_\ba_\br_\bt_\b-
53 For COMPUTE data sources, the format is:
55 D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bC_\bO_\bM_\bP_\bU_\bT_\bE:\b:_\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn
57 In order to decide which data source type to use, review the
58 definitions that follow. Also consult the section on "HOW TO
59 MEASURE" for further insight.
62 is for things like temperatures or number of people in a
63 room or the value of a RedHat share.
66 is for continuous incrementing counters like the ifInOctets
68 the counter never decreases, except when a counter over-
69 flows. The update function takes the overflow into
70 account. The counter is stored as a per-second rate. When
71 the counter overflows, RRDtool checks if the overflow hap-
72 pened at the 32bit or 64bit border and acts accordingly by
73 adding an appropriate value to the result.
76 will store the derivative of the line going from the last
77 to the current value of the data source. This can be useful
78 for gauges, for example, to measure the rate of people
79 entering or leaving a room. Internally, derive works
80 exactly like COUNTER but without overflow checks. So if
81 your counter does not reset at 32 or 64 bit you might want
82 to use DERIVE and combine it with a MIN value of 0.
84 NOTE on COUNTER vs DERIVE
85 by Don Baarda <don.baarda@baesystems.com>
87 If you cannot tolerate ever mistaking the occasional
88 counter reset for a legitimate counter wrap, and would
89 prefer "Unknowns" for all legitimate counter wraps and
90 resets, always use DERIVE with min=0. Otherwise, using
91 COUNTER with a suitable max will return correct values
92 for all legitimate counter wraps, mark some counter
93 resets as "Unknown", but can mistake some counter
94 resets for a legitimate counter wrap.
96 For a 5 minute step and 32-bit counter, the probability
97 of mistaking a counter reset for a legitimate wrap is
98 arguably about 0.8% per 1Mbps of maximum bandwidth.
99 Note that this equates to 80% for 100Mbps interfaces,
100 so for high bandwidth interfaces and a 32bit counter,
101 DERIVE with min=0 is probably preferable. If you are
102 using a 64bit counter, just about any max setting will
103 eliminate the possibility of mistaking a reset for a
104 counter wrap.
107 is for counters which get reset upon reading. This is used
108 for fast counters which tend to overflow. So instead of
109 reading them normally you reset them after every read to
110 make sure you have a maximum time available before the next
111 overflow. Another usage is for things you count like number
112 of messages since the last update.
115 is for storing the result of a formula applied to other
117 value on update, but rather its Primary Data Points (PDPs)
118 are computed from the PDPs of the data sources according to
119 the rpn-expression that defines the formula. Consolidation
120 functions are then applied normally to the PDPs of the COM-
121 PUTE data source (that is the rpn-expression is only
122 applied to generate PDPs). In database software, such data
123 sets are referred to as "virtual" or "computed" columns.
126 between two updates of this data source before the value of the
132 or care about min and max, set them to U for unknown. Note that
133 min and max always refer to the processed values of the DS. For
135 data-rate expected from the device.
137 _\bI_\bf _\bi_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn _\bo_\bn _\bm_\bi_\bn_\bi_\bm_\ba_\bl_\b/_\bm_\ba_\bx_\bi_\bm_\ba_\bl _\be_\bx_\bp_\be_\bc_\bt_\be_\bd _\bv_\ba_\bl_\bu_\be_\bs _\bi_\bs _\ba_\bv_\ba_\bi_\bl_\ba_\bb_\bl_\be_\b,
138 _\ba_\bl_\bw_\ba_\by_\bs _\bs_\be_\bt _\bt_\bh_\be _\bm_\bi_\bn _\ba_\bn_\bd_\b/_\bo_\br _\bm_\ba_\bx _\bp_\br_\bo_\bp_\be_\br_\bt_\bi_\be_\bs_\b. _\bT_\bh_\bi_\bs _\bw_\bi_\bl_\bl _\bh_\be_\bl_\bp _\bR_\bR_\bD_\b-
139 _\bt_\bo_\bo_\bl _\bi_\bn _\bd_\bo_\bi_\bn_\bg _\ba _\bs_\bi_\bm_\bp_\bl_\be _\bs_\ba_\bn_\bi_\bt_\by _\bc_\bh_\be_\bc_\bk _\bo_\bn _\bt_\bh_\be _\bd_\ba_\bt_\ba _\bs_\bu_\bp_\bp_\bl_\bi_\be_\bd _\bw_\bh_\be_\bn
142 _\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn defines the formula used to compute the PDPs of
143 a COMPUTE data source from other data sources in the same
145 command. Please refer to that manual page for a list and
146 description of RPN operations supported. For COMPUTE data
147 sources, the following RPN operations are not supported: COUNT,
148 PREV, TIME, and LTIME. In addition, in defining the RPN expres-
149 sion, the COMPUTE data source may only refer to the names of
150 data source listed previously in the create command. This is
165 of the archive. There are several consolidation functions that
166 consolidate primary data points via an aggregate function:
169 AVERAGE
170 the average of the data points is stored.
172 MIN the smallest of the data points is stored.
174 MAX the largest of the data points is stored.
176 LAST
177 the last data points is used.
179 Note that data aggregation inevitably leads to loss of preci-
180 sion and information. The trick is to pick the aggregate func-
182 across the aggregation process.
186 R\bRR\bRA\bA:\b:_\bA_\bV_\bE_\bR_\bA_\bG_\bE _\b| _\bM_\bI_\bN _\b| _\bM_\bA_\bX _\b| _\bL_\bA_\bS_\bT:\b:_\bx_\bf_\bf:\b:_\bs_\bt_\be_\bp_\bs:\b:_\br_\bo_\bw_\bs
190 dated value is still regarded as known. It is given as the
192 interval. Thus, it ranges from 0 to 1 (exclusive).
194 _\bs_\bt_\be_\bp_\bs defines how many of these _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt_\bs are used to
195 build a _\bc_\bo_\bn_\bs_\bo_\bl_\bi_\bd_\ba_\bt_\be_\bd _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt which then goes into the
196 archive.
201 A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\bwi\bit\bth\bh H\bHo\bol\blt\bt-\b-W\bWi\bin\bnt\bte\ber\brs\bs F\bFo\bor\bre\bec\bca\bas\bst\bti\bin\bng\bg
202 In addition to the aggregate functions, there are a set of specialized
204 Winters forecasting algorithm), confidence bands, and the flagging
205 aberrant behavior in the data source time series:
207 · R\bRR\bRA\bA:\b:_\bH_\bW_\bP_\bR_\bE_\bD_\bI_\bC_\bT:\b:_\br_\bo_\bw_\bs:\b:_\ba_\bl_\bp_\bh_\ba:\b:_\bb_\be_\bt_\ba:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd[:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm]
209 · R\bRR\bRA\bA:\b:_\bM_\bH_\bW_\bP_\bR_\bE_\bD_\bI_\bC_\bT:\b:_\br_\bo_\bw_\bs:\b:_\ba_\bl_\bp_\bh_\ba:\b:_\bb_\be_\bt_\ba:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd[:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm]
211 · R\bRR\bRA\bA:\b:_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bnd\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\b-
214 · R\bRR\bRA\bA:\b:_\bD_\bE_\bV_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bn-\b-
217 · R\bRR\bRA\bA:\b:_\bD_\bE_\bV_\bP_\bR_\bE_\bD_\bI_\bC_\bT:\b:_\br_\bo_\bw_\bs:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm
219 · R\bRR\bRA\bA:\b:_\bF_\bA_\bI_\bL_\bU_\bR_\bE_\bS:\b:_\br_\bo_\bw_\bs:\b:_\bt_\bh_\br_\be_\bs_\bh_\bo_\bl_\bd:\b:_\bw_\bi_\bn_\bd_\bo_\bw _\bl_\be_\bn_\bg_\bt_\bh:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm
224 confidence bounds, a matched set of SEASONAL, DEVSEASONAL, DEVPREDICT,
225 and either HWPREDICT or MHWPREDICT must exist. Generating smoothed val-
228 URES, DEVSEASONAL, SEASONAL, and either HWPREDICT or MHWPREDICT.
230 The predicted, or smoothed, values are stored in the HWPREDICT or MHW-
232 the Holt-Winters method. They are interchangeable. Both attempt to
233 decompose data into three components: a baseline, a trend, and a sea-
234 sonal coefficient. HWPREDICT adds its seasonal coefficient to the
235 baseline to form a prediction, whereas MHWPREDICT multiplies its sea-
236 sonal coefficient by the baseline to form a prediction. The difference
237 is noticeable when the baseline changes significantly in the course of
238 a season; HWPREDICT will predict the seasonality to stay constant as
239 the baseline changes, but MHWPREDICT will predict the seasonality to
240 grow or shrink in proportion to the baseline. The proper choice of
241 method depends on the thing being modeled. For simplicity, the rest of
242 this discussion will refer to HWPREDICT, but MHWPREDICT may be substi-
243 tuted in its place.
245 The predicted deviations are stored in DEVPREDICT (think a standard
246 deviation which can be scaled to yield a confidence band). The FAILURES
248 failure; that is, the number of confidence bounds violations in the
249 preceding window of observations met or exceeded a specified threshold.
251 appears in rrdgraph.
254 the Holt-Winters forecasting algorithm and the seasonal deviations,
255 respectively. There is one entry per observation time point in the
256 seasonal cycle. For example, if primary data points are generated every
257 five minutes and the seasonal cycle is 1 day, both SEASONAL and DEVSEA-
258 SONAL will have 288 rows.
260 In order to simplify the creation for the novice user, in addition to
261 supporting explicit creation of the HWPREDICT, SEASONAL, DEVPREDICT,
262 DEVSEASONAL, and FAILURES R\bRR\bRA\bAs\bs, the R\bRR\bRD\bDt\bto\boo\bol\bl create command supports
263 implicit creation of the other four when HWPREDICT is specified alone
267 that there is a one-to-one correspondence between primary data points
269 than the _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd. If the DEVPREDICT R\bRR\bRA\bA is implicitly created,
271 If the FAILURES R\bRR\bRA\bA is implicitly created, _\br_\bo_\bw_\bs will be set to the _\bs_\be_\ba_\b-
272 _\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd argument of the HWPREDICT R\bRR\bRA\bA. Of course, the R\bRR\bRD\bDt\bto\boo\bol\bl
274 the creator wishes to avoid explicit creations of the other specialized
277 _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd specifies the number of primary data points in a sea-
278 sonal cycle. If SEASONAL and DEVSEASONAL are implicitly created, this
280 HWPREDICT. If they are explicitly created, the creator should verify
284 cient in the Holt-Winters forecasting algorithm. See rrdtool for a
286 closer to 1 means that more recent observations carry greater weight in
287 predicting the baseline component of the forecast. A value closer to 0
288 means that past history carries greater weight in predicting the base-
289 line component.
294 linear trend.
297 Holt-Winters forecasting algorithm (HWPREDICT) or the adaption parame-
298 ter in the exponential smoothing update of the seasonal deviations. It
302 there is one seasonal coefficient (or deviation) for each time point
303 during the seasonal cycle, the adaptation rate is much slower than the
304 baseline. Each seasonal coefficient is only updated (or adapts) when
305 the observed value occurs at the offset in the seasonal cycle corre-
306 sponding to that coefficient.
308 If SEASONAL and DEVSEASONAL R\bRR\bRA\bAs\bs are created explicitly, _\bg_\ba_\bm_\bm_\ba need not
309 be the same for both. Note that _\bg_\ba_\bm_\bm_\ba can also be changed via the R\bRR\bRD\bD-\b-
312 _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw specifies the fraction of a season that should be
313 averaged around each point. By default, the value of _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw
314 is 0.05, which means each value in SEASONAL and DEVSEASONAL will be
315 occasionally replaced by averaging it with its (_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd*0.05)
316 nearest neighbors. Setting _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw to zero will disable the
317 running-average smoother altogether.
319 _\br_\br_\ba_\b-_\bn_\bu_\bm provides the links between related R\bRR\bRA\bAs\bs. If HWPREDICT is speci-
324 The _\br_\br_\ba_\b-_\bn_\bu_\bm argument is the 1-based index in the order of R\bRR\bRA\bA creation
326 R\bRR\bRA\bA for each R\bRR\bRA\bA requiring the _\br_\br_\ba_\b-_\bn_\bu_\bm argument is listed here:
338 _\bt_\bh_\br_\be_\bs_\bh_\bo_\bl_\bd is the minimum number of violations (observed values outside
339 the confidence bounds) within a window that constitutes a failure. If
342 _\bw_\bi_\bn_\bd_\bo_\bw _\bl_\be_\bn_\bg_\bt_\bh is the number of time points in the window. Specify an
343 integer greater than or equal to the threshold and less than or equal
344 to 28. The time interval this window represents depends on the inter-
346 ated, the default value is 9.
349 Here is an explanation by Don Baarda on the inner workings of RRDtool.
350 It may help you to sort out why all this *UNKNOWN* data is popping up
351 in your databases:
353 RRDtool gets fed samples/updates at arbitrary times. From these it
354 builds Primary Data Points (PDPs) on every "step" interval. The PDPs
355 are then accumulated into the RRAs.
357 The "heartbeat" defines the maximum acceptable interval between sam-
358 ples/updates. If the interval between samples is less than "heartbeat",
359 then an average rate is calculated and applied for that interval. If
360 the interval between samples is longer than "heartbeat", then that
361 entire interval is considered "unknown". Note that there are other
362 things that can make a sample interval "unknown", such as the rate
363 exceeding limits, or a sample that was explicitly marked as unknown.
365 The known rates during a PDP's "step" interval are used to calculate an
366 average rate for that PDP. If the total "unknown" time accounts for
368 means that a mixture of known and "unknown" sample times in a single
369 PDP "step" may or may not add up to enough "known" time to warrent for
370 a known PDP.
372 The "heartbeat" can be short (unusual) or long (typical) relative to
373 the "step" interval between PDPs. A short "heartbeat" means you require
374 multiple samples per PDP, and if you don't get them mark the PDP
375 unknown. A long heartbeat can span multiple "steps", which means it is
376 acceptable to have multiple PDPs calculated from a single sample. An
377 extreme example of this might be a "step" of 5 minutes and a "heart-
378 beat" of one day, in which case a single sample every day will result
379 in all the PDPs for that entire day period being set to the same aver-
380 age rate. _\b-_\b- _\bD_\bo_\bn _\bB_\ba_\ba_\br_\bd_\ba _\b<_\bd_\bo_\bn_\b._\bb_\ba_\ba_\br_\bd_\ba_\b@_\bb_\ba_\be_\bs_\by_\bs_\bt_\be_\bm_\bs_\b._\bc_\bo_\bm_\b>
382 time|
383 axis|
384 begin__|00|
385 |01|
386 u|02|----* sample1, restart "hb"-timer
387 u|03| /
388 u|04| /
389 u|05| /
390 u|06|/ "hbt" expired
391 u|07|
392 |08|----* sample2, restart "hb"
393 |09| /
394 |10| /
395 u|11|----* sample3, restart "hb"
396 u|12| /
397 u|13| /
398 step1_u|14| /
399 u|15|/ "swt" expired
400 u|16|
401 |17|----* sample4, restart "hb", create "pdp" for step1 =
402 |18| / = unknown due to 10 "u" labled secs > 0.5 * step
403 |19| /
404 |20| /
405 |21|----* sample5, restart "hb"
406 |22| /
407 |23| /
408 |24|----* sample6, restart "hb"
409 |25| /
410 |26| /
411 |27|----* sample7, restart "hb"
412 step2__|28| /
413 |22| /
414 |23|----* sample8, restart "hb", create "pdp" for step1, create "cdp"
415 |24| /
416 |25| /
418 graphics by _\bv_\bl_\ba_\bd_\bi_\bm_\bi_\br_\b._\bl_\ba_\bv_\br_\bo_\bv_\b@_\bd_\be_\bs_\by_\b._\bd_\be.
421 Here are a few hints on how to measure:
423 Temperature
424 Usually you have some type of meter you can read to get the temper-
425 ature. The temperature is not really connected with a time. The
426 only connection is that the temperature reading happened at a cer-
428 will then record your reading together with the time.
430 Mail Messages
431 Assume you have a method to count the number of messages trans-
432 ported by your mailserver in a certain amount of time, giving you
433 data like '5 messages in the last 65 seconds'. If you look at the
435 with the number 5 and the end time of your monitoring period. RRD-
436 tool will then record the number of messages per second. If at some
437 later stage you want to know the number of messages transported in
438 a day, you can get the average messages per second from RRDtool for
439 the day in question and multiply this number with the number of
440 seconds in a day. Because all math is run with Doubles, the preci-
441 sion should be acceptable.
443 It's always a Rate
444 RRDtool stores rates in amount/second for COUNTER, DERIVE and ABSO-
445 LUTE data. When you plot the data, you will get on the y axis
446 amount/second which you might be tempted to convert to an absolute
447 amount by multiplying by the delta-time between the points. RRDtool
448 plots continuous data, and as such is not appropriate for plotting
449 absolute amounts as for example "total bytes" sent and received in
450 a router. What you probably want is plot rates that you can scale
451 to bytes/hour, for example, or plot absolute amounts with another
452 tool that draws bar-plots, where the delta-time is clear on the
453 plot for each point (such that when you read the graph you see for
454 example GB on the y axis, days on the x axis and one bar for each
455 day).
458 rrdtool create temperature.rrd --step 300 \
459 DS:temp:GAUGE:600:-273:5000 \
460 RRA:AVERAGE:0.5:1:1200 \
461 RRA:MIN:0.5:12:2400 \
462 RRA:MAX:0.5:12:2400 \
463 RRA:AVERAGE:0.5:12:2400
465 This sets up an R\bRR\bRD\bD called _\bt_\be_\bm_\bp_\be_\br_\ba_\bt_\bu_\br_\be_\b._\br_\br_\bd which accepts one tempera-
466 ture value every 300 seconds. If no new data is supplied for more than
467 600 seconds, the temperature becomes _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. The minimum acceptable
468 value is -273 and the maximum is 5'000.
470 A few archive areas are also defined. The first stores the temperatures
471 supplied for 100 hours (1'200 * 300 seconds = 100 hours). The second
472 RRA stores the minimum temperature recorded over every hour (12 * 300
473 seconds = 1 hour), for 100 days (2'400 hours). The third and the fourth
474 RRA's do the same for the maximum and average temperature, respec-
475 tively.
478 rrdtool create monitor.rrd --step 300 \
479 DS:ifOutOctets:COUNTER:1800:0:4294967295 \
480 RRA:AVERAGE:0.5:1:2016 \
481 RRA:HWPREDICT:1440:0.1:0.0035:288
485 functions R\bRR\bRA\bAs\bs for aberrant behavior detection. Note that the _\br_\br_\ba_\b-_\bn_\bu_\bm
487 created with default parameter values. In this example, the forecasting
488 algorithm baseline adapts quickly; in fact the most recent one hour of
489 observations (each at 5 minute intervals) accounts for 75% of the base-
490 line prediction. The linear trend forecast adapts much more slowly.
491 Observations made during the last day (at 288 observations per day)
492 account for only 65% of the predicted linear trend. Note: these compu-
493 tations rely on an exponential smoothing formula described in the LISA
494 2000 paper.
496 The seasonal cycle is one day (288 data points at 300 second inter-
497 vals), and the seasonal adaption parameter will be set to 0.1. The RRD
498 file will store 5 days (1'440 data points) of forecasts and deviation
499 predictions before wrap around. The file will store 1 day (a seasonal
505 rrdtool create monitor.rrd --step 300 \
506 DS:ifOutOctets:COUNTER:1800:0:4294967295 \
507 RRA:AVERAGE:0.5:1:2016 \
508 RRA:HWPREDICT:1440:0.1:0.0035:288:3 \
509 RRA:SEASONAL:288:0.1:2 \
510 RRA:DEVPREDICT:1440:5 \
511 RRA:DEVSEASONAL:288:0.1:2 \
512 RRA:FAILURES:288:7:9:5
514 Of course, explicit creation need not replicate implicit create, a num-
515 ber of arguments could be changed.
518 rrdtool create proxy.rrd --step 300 \
519 DS:Total:DERIVE:1800:0:U \
520 DS:Duration:DERIVE:1800:0:U \
521 DS:AvgReqDur:COMPUTE:Duration,Requests,0,EQ,1,Requests,IF,/ \
522 RRA:AVERAGE:0.5:1:2016
524 This example is monitoring the average request duration during each 300
525 sec interval for requests processed by a web proxy during the interval.
526 In this case, the proxy exposes two counters, the number of requests
527 processed since boot and the total cumulative duration of all processed
528 requests. Clearly these counters both have some rollover point, but
529 using the DERIVE data source also handles the reset that occurs when
530 the web proxy is stopped and restarted.
533 during the interval. The second data source stores the total duration
534 of all requests processed during the interval divided by 300. The COM-
535 PUTE data source divides each PDP of the AccumDuration by the corre-
536 sponding PDP of TotalRequests and stores the average request duration.
537 The remainder of the RPN expression handles the divide by zero case.
540 Tobias Oetiker <tobi@oetiker.ch>
544 1.3rc4 2008-05-12 RRDCREATE(1)