diff --git a/doc/rrdcreate.txt b/doc/rrdcreate.txt
index 197959d5335442217aa8d2cc56ec6582bbc41ff0..0a82202f8b90692bf854440a7060c4d20af65456 100644 (file)
--- a/doc/rrdcreate.txt
+++ b/doc/rrdcreate.txt
(R\bRR\bRD\bD) files. The file is created at its final, full size and filled
with _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data.
- _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be
- The name of the R\bRR\bRD\bD you want to create. R\bRR\bRD\bD files should end
- with the extension _\b._\br_\br_\bd. However, R\bRR\bRD\bDt\bto\boo\bol\bl will accept any file-
- name.
-
- -\b--\b-s\bst\bta\bar\brt\bt|-\b-b\bb _\bs_\bt_\ba_\br_\bt _\bt_\bi_\bm_\be (default: now - 10s)
- Specifies the time in seconds since 1970-01-01 UTC when the
- first value should be added to the R\bRR\bRD\bD. R\bRR\bRD\bDt\bto\boo\bol\bl will not accept
- any data timed before or at the time specified.
-
- See also AT-STYLE TIME SPECIFICATION section in the _\br_\br_\bd_\bf_\be_\bt_\bc_\bh
- documentation for other ways to specify time.
-
- -\b--\b-s\bst\bte\bep\bp|-\b-s\bs _\bs_\bt_\be_\bp (default: 300 seconds)
- Specifies the base interval in seconds with which data will be
- fed into the R\bRR\bRD\bD.
-
- 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
- A single R\bRR\bRD\bD can accept input from several data sources (D\bDS\bS),
- for example incoming and outgoing traffic on a specific commu-
- nication line. With the D\bDS\bS configuration option you must define
- some basic properties of each data source you want to store in
- the R\bRR\bRD\bD.
-
- _\bd_\bs_\b-_\bn_\ba_\bm_\be is the name you will use to reference this particular
- data source from an R\bRR\bRD\bD. A _\bd_\bs_\b-_\bn_\ba_\bm_\be must be 1 to 19 characters
- long in the characters [a-zA-Z0-9_].
-
- _\bD_\bS_\bT defines the Data Source Type. The remaining arguments of a
- data source entry depend on the data source type. For GAUGE,
- COUNTER, DERIVE, and ABSOLUTE the format for a data source
- entry is:
-
- 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-
- _\bb_\be_\ba_\bt:\b:_\bm_\bi_\bn:\b:_\bm_\ba_\bx
-
- For COMPUTE data sources, the format is:
-
- 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
-
- In order to decide which data source type to use, review the
- definitions that follow. Also consult the section on "HOW TO
- MEASURE" for further insight.
-
- G\bGA\bAU\bUG\bGE\bE
- is for things like temperatures or number of people in a
- room or the value of a RedHat share.
-
- C\bCO\bOU\bUN\bNT\bTE\bER\bR
- is for continuous incrementing counters like the ifInOctets
- counter in a router. The C\bCO\bOU\bUN\bNT\bTE\bER\bR data source assumes that
- the counter never decreases, except when a counter over-
- flows. The update function takes the overflow into
- account. The counter is stored as a per-second rate. When
- the counter overflows, RRDtool checks if the overflow hap-
- pened at the 32bit or 64bit border and acts accordingly by
- adding an appropriate value to the result.
-
- D\bDE\bER\bRI\bIV\bVE\bE
- will store the derivative of the line going from the last
- to the current value of the data source. This can be useful
- for gauges, for example, to measure the rate of people
- entering or leaving a room. Internally, derive works
- exactly like COUNTER but without overflow checks. So if
- your counter does not reset at 32 or 64 bit you might want
- to use DERIVE and combine it with a MIN value of 0.
-
- NOTE on COUNTER vs DERIVE
- by Don Baarda <don.baarda@baesystems.com>
-
- If you cannot tolerate ever mistaking the occasional
- counter reset for a legitimate counter wrap, and would
- prefer "Unknowns" for all legitimate counter wraps and
- resets, always use DERIVE with min=0. Otherwise, using
- COUNTER with a suitable max will return correct values
- for all legitimate counter wraps, mark some counter
- resets as "Unknown", but can mistake some counter
- resets for a legitimate counter wrap.
-
- For a 5 minute step and 32-bit counter, the probability
- of mistaking a counter reset for a legitimate wrap is
- arguably about 0.8% per 1Mbps of maximum bandwidth.
- Note that this equates to 80% for 100Mbps interfaces,
- so for high bandwidth interfaces and a 32bit counter,
- DERIVE with min=0 is probably preferable. If you are
- using a 64bit counter, just about any max setting will
- eliminate the possibility of mistaking a reset for a
- counter wrap.
-
- A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE
- is for counters which get reset upon reading. This is used
- for fast counters which tend to overflow. So instead of
- reading them normally you reset them after every read to
- make sure you have a maximum time available before the next
- overflow. Another usage is for things you count like number
- of messages since the last update.
-
- C\bCO\bOM\bMP\bPU\bUT\bTE\bE
- is for storing the result of a formula applied to other
- data sources in the R\bRR\bRD\bD. This data source is not supplied a
- value on update, but rather its Primary Data Points (PDPs)
- are computed from the PDPs of the data sources according to
- the rpn-expression that defines the formula. Consolidation
- functions are then applied normally to the PDPs of the COM-
- PUTE data source (that is the rpn-expression is only
- applied to generate PDPs). In database software, such data
- sets are referred to as "virtual" or "computed" columns.
-
- _\bh_\be_\ba_\br_\bt_\bb_\be_\ba_\bt defines the maximum number of seconds that may pass
- between two updates of this data source before the value of the
- data source is assumed to be _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.
-
- _\bm_\bi_\bn and _\bm_\ba_\bx define the expected range values for data supplied
- by a data source. If _\bm_\bi_\bn and/or _\bm_\ba_\bx any value outside the
- defined range will be regarded as _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. If you do not know
- or care about min and max, set them to U for unknown. Note that
- min and max always refer to the processed values of the DS. For
- a traffic-C\bCO\bOU\bUN\bNT\bTE\bER\bR type DS this would be the maximum and minimum
- data-rate expected from the device.
-
- _\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,
- _\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-
- _\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
- _\br_\bu_\bn_\bn_\bi_\bn_\bg _\bu_\bp_\bd_\ba_\bt_\be_\b.
-
- _\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn defines the formula used to compute the PDPs of
- a COMPUTE data source from other data sources in the same
- <RRD>. It is similar to defining a C\bCD\bDE\bEF\bF argument for the graph
- command. Please refer to that manual page for a list and
- description of RPN operations supported. For COMPUTE data
- sources, the following RPN operations are not supported: COUNT,
- PREV, TIME, and LTIME. In addition, in defining the RPN expres-
- sion, the COMPUTE data source may only refer to the names of
- data source listed previously in the create command. This is
- similar to the restriction that C\bCD\bDE\bEF\bFs must refer only to D\bDE\bEF\bFs
- and C\bCD\bDE\bEF\bFs previously defined in the same graph command.
-
- R\bRR\bRA\bA:\b:_\bC_\bF:\b:_\bc_\bf _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
- The purpose of an R\bRR\bRD\bD is to store data in the round robin
- archives (R\bRR\bRA\bA). An archive consists of a number of data values
- or statistics for each of the defined data-sources (D\bDS\bS) and is
- defined with an R\bRR\bRA\bA line.
-
- When data is entered into an R\bRR\bRD\bD, it is first fit into time
- slots of the length defined with the -\b-s\bs option, thus becoming a
- _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt.
-
- The data is also processed with the consolidation function (_\bC_\bF)
- of the archive. There are several consolidation functions that
- consolidate primary data points via an aggregate function:
- A\bAV\bVE\bER\bRA\bAG\bGE\bE, M\bMI\bIN\bN, M\bMA\bAX\bX, L\bLA\bAS\bST\bT.
-
- AVERAGE
- the average of the data points is stored.
-
- MIN the smallest of the data points is stored.
-
- MAX the largest of the data points is stored.
-
- LAST
- the last data points is used.
-
- Note that data aggregation inevitably leads to loss of preci-
- sion and information. The trick is to pick the aggregate func-
- tion such that the _\bi_\bn_\bt_\be_\br_\be_\bs_\bt_\bi_\bn_\bg properties of your data is kept
- across the aggregation process.
-
- The format of R\bRR\bRA\bA line for these consolidation functions is:
-
- 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
-
- _\bx_\bf_\bf The xfiles factor defines what part of a consolidation
- interval may be made up from _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data while the consoli-
- dated value is still regarded as known. It is given as the
- ratio of allowed _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* PDPs to the number of PDPs in the
- interval. Thus, it ranges from 0 to 1 (exclusive).
-
- _\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
- 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
- archive.
-
- _\br_\bo_\bw_\bs defines how many generations of data values are kept in an
- R\bRR\bRA\bA.
+ _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be
+ The name of the R\bRR\bRD\bD you want to create. R\bRR\bRD\bD files should end with the
+ extension _\b._\br_\br_\bd. However, R\bRR\bRD\bDt\bto\boo\bol\bl will accept any filename.
+
+ -\b--\b-s\bst\bta\bar\brt\bt|\b|-\b-b\bb _\bs_\bt_\ba_\br_\bt _\bt_\bi_\bm_\be (\b(d\bde\bef\bfa\bau\bul\blt\bt:\b: n\bno\bow\bw -\b- 1\b10\b0s\bs)\b)
+ Specifies the time in seconds since 1970-01-01 UTC when the first value
+ should be added to the R\bRR\bRD\bD. R\bRR\bRD\bDt\bto\boo\bol\bl will not accept any data timed
+ before or at the time specified.
+
+ See also AT-STYLE TIME SPECIFICATION section in the _\br_\br_\bd_\bf_\be_\bt_\bc_\bh
+ documentation for other ways to specify time.
+
+ -\b--\b-s\bst\bte\bep\bp|\b|-\b-s\bs _\bs_\bt_\be_\bp (\b(d\bde\bef\bfa\bau\bul\blt\bt:\b: 3\b30\b00\b0 s\bse\bec\bco\bon\bnd\bds\bs)\b)
+ Specifies the base interval in seconds with which data will be fed into
+ the R\bRR\bRD\bD.
+
+ 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
+ A single R\bRR\bRD\bD can accept input from several data sources (D\bDS\bS), for
+ example incoming and outgoing traffic on a specific communication line.
+ With the D\bDS\bS configuration option you must define some basic properties
+ of each data source you want to store in the R\bRR\bRD\bD.
+
+ _\bd_\bs_\b-_\bn_\ba_\bm_\be is the name you will use to reference this particular data
+ source from an R\bRR\bRD\bD. A _\bd_\bs_\b-_\bn_\ba_\bm_\be must be 1 to 19 characters long in the
+ characters [a-zA-Z0-9_].
+
+ _\bD_\bS_\bT defines the Data Source Type. The remaining arguments of a data
+ source entry depend on the data source type. For GAUGE, COUNTER,
+ DERIVE, and ABSOLUTE the format for a data source entry is:
+
+ 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_\bb_\be_\ba_\bt:\b:_\bm_\bi_\bn:\b:_\bm_\ba_\bx
+
+ For COMPUTE data sources, the format is:
+
+ 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
+
+ In order to decide which data source type to use, review the
+ definitions that follow. Also consult the section on "HOW TO MEASURE"
+ for further insight.
+
+ G\bGA\bAU\bUG\bGE\bE
+ is for things like temperatures or number of people in a room or
+ the value of a RedHat share.
+
+ C\bCO\bOU\bUN\bNT\bTE\bER\bR
+ is for continuous incrementing counters like the ifInOctets counter
+ in a router. The C\bCO\bOU\bUN\bNT\bTE\bER\bR data source assumes that the counter never
+ decreases, except when a counter overflows. The update function
+ takes the overflow into account. The counter is stored as a per-
+ second rate. When the counter overflows, RRDtool checks if the
+ overflow happened at the 32bit or 64bit border and acts accordingly
+ by adding an appropriate value to the result.
+
+ D\bDE\bER\bRI\bIV\bVE\bE
+ will store the derivative of the line going from the last to the
+ current value of the data source. This can be useful for gauges,
+ for example, to measure the rate of people entering or leaving a
+ room. Internally, derive works exactly like COUNTER but without
+ overflow checks. So if your counter does not reset at 32 or 64 bit
+ you might want to use DERIVE and combine it with a MIN value of 0.
+
+ N\bNO\bOT\bTE\bE o\bon\bn C\bCO\bOU\bUN\bNT\bTE\bER\bR v\bvs\bs D\bDE\bER\bRI\bIV\bVE\bE
+
+ by Don Baarda <don.baarda@baesystems.com>
+
+ If you cannot tolerate ever mistaking the occasional counter reset
+ for a legitimate counter wrap, and would prefer "Unknowns" for all
+ legitimate counter wraps and resets, always use DERIVE with min=0.
+ Otherwise, using COUNTER with a suitable max will return correct
+ values for all legitimate counter wraps, mark some counter resets
+ as "Unknown", but can mistake some counter resets for a legitimate
+ counter wrap.
+
+ For a 5 minute step and 32-bit counter, the probability of
+ mistaking a counter reset for a legitimate wrap is arguably about
+ 0.8% per 1Mbps of maximum bandwidth. Note that this equates to 80%
+ for 100Mbps interfaces, so for high bandwidth interfaces and a
+ 32bit counter, DERIVE with min=0 is probably preferable. If you are
+ using a 64bit counter, just about any max setting will eliminate
+ the possibility of mistaking a reset for a counter wrap.
+
+ A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE
+ is for counters which get reset upon reading. This is used for fast
+ counters which tend to overflow. So instead of reading them
+ normally you reset them after every read to make sure you have a
+ maximum time available before the next overflow. Another usage is
+ for things you count like number of messages since the last update.
+
+ C\bCO\bOM\bMP\bPU\bUT\bTE\bE
+ is for storing the result of a formula applied to other data
+ sources in the R\bRR\bRD\bD. This data source is not supplied a value on
+ update, but rather its Primary Data Points (PDPs) are computed from
+ the PDPs of the data sources according to the rpn-expression that
+ defines the formula. Consolidation functions are then applied
+ normally to the PDPs of the COMPUTE data source (that is the rpn-
+ expression is only applied to generate PDPs). In database software,
+ such data sets are referred to as "virtual" or "computed" columns.
+
+ _\bh_\be_\ba_\br_\bt_\bb_\be_\ba_\bt defines the maximum number of seconds that may pass between
+ two updates of this data source before the value of the data source is
+ assumed to be _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.
+
+ _\bm_\bi_\bn and _\bm_\ba_\bx define the expected range values for data supplied by a
+ data source. If _\bm_\bi_\bn and/or _\bm_\ba_\bx any value outside the defined range will
+ be regarded as _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. If you do not know or care about min and max,
+ set them to U for unknown. Note that min and max always refer to the
+ processed values of the DS. For a traffic-C\bCO\bOU\bUN\bNT\bTE\bER\bR type DS this would be
+ the maximum and minimum data-rate expected from the device.
+
+ _\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, _\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_\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 _\br_\bu_\bn_\bn_\bi_\bn_\bg _\bu_\bp_\bd_\ba_\bt_\be_\b.
+
+ _\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn defines the formula used to compute the PDPs of a
+ COMPUTE data source from other data sources in the same <RRD>. It is
+ similar to defining a C\bCD\bDE\bEF\bF argument for the graph command. Please refer
+ to that manual page for a list and description of RPN operations
+ supported. For COMPUTE data sources, the following RPN operations are
+ not supported: COUNT, PREV, TIME, and LTIME. In addition, in defining
+ the RPN expression, the COMPUTE data source may only refer to the names
+ of data source listed previously in the create command. This is similar
+ to the restriction that C\bCD\bDE\bEF\bFs must refer only to D\bDE\bEF\bFs and C\bCD\bDE\bEF\bFs
+ previously defined in the same graph command.
+
+ R\bRR\bRA\bA:\b:_\bC_\bF:\b:_\bc_\bf _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
+ The purpose of an R\bRR\bRD\bD is to store data in the round robin archives
+ (R\bRR\bRA\bA). An archive consists of a number of data values or statistics for
+ each of the defined data-sources (D\bDS\bS) and is defined with an R\bRR\bRA\bA line.
+
+ When data is entered into an R\bRR\bRD\bD, it is first fit into time slots of
+ the length defined with the -\b-s\bs option, thus becoming a _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba
+ _\bp_\bo_\bi_\bn_\bt.
+
+ The data is also processed with the consolidation function (_\bC_\bF) of the
+ archive. There are several consolidation functions that consolidate
+ primary data points via an aggregate function: A\bAV\bVE\bER\bRA\bAG\bGE\bE, M\bMI\bIN\bN, M\bMA\bAX\bX, L\bLA\bAS\bST\bT.
+
+ AVERAGE
+ the average of the data points is stored.
+
+ MIN the smallest of the data points is stored.
+
+ MAX the largest of the data points is stored.
+
+ LAST
+ the last data points is used.
+
+ Note that data aggregation inevitably leads to loss of precision and
+ information. The trick is to pick the aggregate function such that the
+ _\bi_\bn_\bt_\be_\br_\be_\bs_\bt_\bi_\bn_\bg properties of your data is kept across the aggregation
+ process.
+
+ The format of R\bRR\bRA\bA line for these consolidation functions is:
+
+ 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
+
+ _\bx_\bf_\bf The xfiles factor defines what part of a consolidation interval may
+ be made up from _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data while the consolidated value is still
+ regarded as known. It is given as the ratio of allowed _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* PDPs
+ to the number of PDPs in the interval. Thus, it ranges from 0 to 1
+ (exclusive).
+
+ _\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 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 archive.
+
+ _\br_\bo_\bw_\bs defines how many generations of data values are kept in an R\bRR\bRA\bA.
+ Obviously, this has to be greater than zero.
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
In addition to the aggregate functions, there are a set of specialized
@@ -208,11 +192,11 @@ 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\b
ยท 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]
- ยท 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-
- _\bt_\bi_\bo_\bn]
+ ยท 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_\bt_\bi_\bo_\bn]
- ยท 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-
- d\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\bt_\bi_\bo_\bn]
+ ยท 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\bnd\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\bt_\bi_\bo_\bn]
ยท 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
@@ -222,25 +206,25 @@ 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\b
ways. First, each of the R\bRR\bRA\bAs is updated once for every primary data
point. Second, these R\bRR\bRA\bAs\bs are interdependent. To generate real-time
confidence bounds, a matched set of SEASONAL, DEVSEASONAL, DEVPREDICT,
- and either HWPREDICT or MHWPREDICT must exist. Generating smoothed val-
- ues of the primary data points requires a SEASONAL R\bRR\bRA\bA and either an
- HWPREDICT or MHWPREDICT R\bRR\bRA\bA. Aberrant behavior detection requires FAIL-
- URES, DEVSEASONAL, SEASONAL, and either HWPREDICT or MHWPREDICT.
+ and either HWPREDICT or MHWPREDICT must exist. Generating smoothed
+ values of the primary data points requires a SEASONAL R\bRR\bRA\bA and either an
+ HWPREDICT or MHWPREDICT R\bRR\bRA\bA. Aberrant behavior detection requires
+ FAILURES, DEVSEASONAL, SEASONAL, and either HWPREDICT or MHWPREDICT.
- The predicted, or smoothed, values are stored in the HWPREDICT or MHW-
- PREDICT R\bRR\bRA\bA. HWPREDICT and MHWPREDICT are actually two variations on
+ The predicted, or smoothed, values are stored in the HWPREDICT or
+ MHWPREDICT R\bRR\bRA\bA. HWPREDICT and MHWPREDICT are actually two variations on
the Holt-Winters method. They are interchangeable. Both attempt to
- decompose data into three components: a baseline, a trend, and a sea-
- sonal coefficient. HWPREDICT adds its seasonal coefficient to the
- baseline to form a prediction, whereas MHWPREDICT multiplies its sea-
- sonal coefficient by the baseline to form a prediction. The difference
- is noticeable when the baseline changes significantly in the course of
- a season; HWPREDICT will predict the seasonality to stay constant as
- the baseline changes, but MHWPREDICT will predict the seasonality to
- grow or shrink in proportion to the baseline. The proper choice of
- method depends on the thing being modeled. For simplicity, the rest of
- this discussion will refer to HWPREDICT, but MHWPREDICT may be substi-
- tuted in its place.
+ decompose data into three components: a baseline, a trend, and a
+ seasonal coefficient. HWPREDICT adds its seasonal coefficient to the
+ baseline to form a prediction, whereas MHWPREDICT multiplies its
+ seasonal coefficient by the baseline to form a prediction. The
+ difference is noticeable when the baseline changes significantly in the
+ course of a season; HWPREDICT will predict the seasonality to stay
+ constant as the baseline changes, but MHWPREDICT will predict the
+ seasonality to grow or shrink in proportion to the baseline. The proper
+ choice of method depends on the thing being modeled. For simplicity,
+ the rest of this discussion will refer to HWPREDICT, but MHWPREDICT may
+ be substituted in its place.
The predicted deviations are stored in DEVPREDICT (think a standard
deviation which can be scaled to yield a confidence band). The FAILURES
@@ -254,8 +238,8 @@ 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\b
the Holt-Winters forecasting algorithm and the seasonal deviations,
respectively. There is one entry per observation time point in the
seasonal cycle. For example, if primary data points are generated every
- five minutes and the seasonal cycle is 1 day, both SEASONAL and DEVSEA-
- SONAL will have 288 rows.
+ five minutes and the seasonal cycle is 1 day, both SEASONAL and
+ DEVSEASONAL will have 288 rows.
In order to simplify the creation for the novice user, in addition to
supporting explicit creation of the HWPREDICT, SEASONAL, DEVPREDICT,
@@ -268,46 +252,46 @@ 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\b
and entries in these RRAs. For the HWPREDICT CF, _\br_\bo_\bw_\bs should be larger
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,
the default number of rows is the same as the HWPREDICT _\br_\bo_\bw_\bs argument.
- If the FAILURES R\bRR\bRA\bA is implicitly created, _\br_\bo_\bw_\bs will be set to the _\bs_\be_\ba_\b-
- _\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
+ If the FAILURES R\bRR\bRA\bA is implicitly created, _\br_\bo_\bw_\bs will be set to the
+ _\bs_\be_\ba_\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
_\br_\be_\bs_\bi_\bz_\be command is available if these defaults are not sufficient and
the creator wishes to avoid explicit creations of the other specialized
function R\bRR\bRA\bAs\bs.
- _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd specifies the number of primary data points in a sea-
- sonal cycle. If SEASONAL and DEVSEASONAL are implicitly created, this
- argument for those R\bRR\bRA\bAs\bs is set automatically to the value specified by
- HWPREDICT. If they are explicitly created, the creator should verify
- that all three _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd arguments agree.
-
- _\ba_\bl_\bp_\bh_\ba is the adaption parameter of the intercept (or baseline) coeffi-
- cient in the Holt-Winters forecasting algorithm. See rrdtool for a
- description of this algorithm. _\ba_\bl_\bp_\bh_\ba must lie between 0 and 1. A value
- closer to 1 means that more recent observations carry greater weight in
- predicting the baseline component of the forecast. A value closer to 0
- means that past history carries greater weight in predicting the base-
- line component.
-
- _\bb_\be_\bt_\ba is the adaption parameter of the slope (or linear trend) coeffi-
- cient in the Holt-Winters forecasting algorithm. _\bb_\be_\bt_\ba must lie between
- 0 and 1 and plays the same role as _\ba_\bl_\bp_\bh_\ba with respect to the predicted
- linear trend.
+ _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd specifies the number of primary data points in a
+ seasonal cycle. If SEASONAL and DEVSEASONAL are implicitly created,
+ this argument for those R\bRR\bRA\bAs\bs is set automatically to the value
+ specified by HWPREDICT. If they are explicitly created, the creator
+ should verify that all three _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd arguments agree.
+
+ _\ba_\bl_\bp_\bh_\ba is the adaption parameter of the intercept (or baseline)
+ coefficient in the Holt-Winters forecasting algorithm. See rrdtool for
+ a description of this algorithm. _\ba_\bl_\bp_\bh_\ba must lie between 0 and 1. A
+ value closer to 1 means that more recent observations carry greater
+ weight in predicting the baseline component of the forecast. A value
+ closer to 0 means that past history carries greater weight in
+ predicting the baseline component.
+
+ _\bb_\be_\bt_\ba is the adaption parameter of the slope (or linear trend)
+ coefficient in the Holt-Winters forecasting algorithm. _\bb_\be_\bt_\ba must lie
+ between 0 and 1 and plays the same role as _\ba_\bl_\bp_\bh_\ba with respect to the
+ predicted linear trend.
_\bg_\ba_\bm_\bm_\ba is the adaption parameter of the seasonal coefficients in the
- Holt-Winters forecasting algorithm (HWPREDICT) or the adaption parame-
- ter in the exponential smoothing update of the seasonal deviations. It
- must lie between 0 and 1. If the SEASONAL and DEVSEASONAL R\bRR\bRA\bAs\bs are cre-
- ated implicitly, they will both have the same value for _\bg_\ba_\bm_\bm_\ba: the
- value specified for the HWPREDICT _\ba_\bl_\bp_\bh_\ba argument. Note that because
- there is one seasonal coefficient (or deviation) for each time point
- during the seasonal cycle, the adaptation rate is much slower than the
- baseline. Each seasonal coefficient is only updated (or adapts) when
- the observed value occurs at the offset in the seasonal cycle corre-
- sponding to that coefficient.
+ Holt-Winters forecasting algorithm (HWPREDICT) or the adaption
+ parameter in the exponential smoothing update of the seasonal
+ deviations. It must lie between 0 and 1. If the SEASONAL and
+ DEVSEASONAL R\bRR\bRA\bAs\bs are created implicitly, they will both have the same
+ value for _\bg_\ba_\bm_\bm_\ba: the value specified for the HWPREDICT _\ba_\bl_\bp_\bh_\ba argument.
+ Note that because there is one seasonal coefficient (or deviation) for
+ each time point during the seasonal cycle, the adaptation rate is much
+ slower than the baseline. Each seasonal coefficient is only updated (or
+ adapts) when the observed value occurs at the offset in the seasonal
+ cycle corresponding to that coefficient.
If SEASONAL and DEVSEASONAL R\bRR\bRA\bAs\bs are created explicitly, _\bg_\ba_\bm_\bm_\ba need not
- be the same for both. Note that _\bg_\ba_\bm_\bm_\ba can also be changed via the R\bRR\bRD\bD-\b-
- t\bto\boo\bol\bl _\bt_\bu_\bn_\be command.
+ be the same for both. Note that _\bg_\ba_\bm_\bm_\ba can also be changed via the
+ R\bRR\bRD\bDt\bto\boo\bol\bl _\bt_\bu_\bn_\be command.
_\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
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
@@ -316,14 +300,15 @@ 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\b
nearest neighbors. Setting _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw to zero will disable the
running-average smoother altogether.
- _\br_\br_\ba_\b-_\bn_\bu_\bm provides the links between related R\bRR\bRA\bAs\bs. If HWPREDICT is speci-
- fied alone and the other R\bRR\bRA\bAs\bs are created implicitly, then there is no
- need to worry about this argument. If R\bRR\bRA\bAs\bs are created explicitly, then
- carefully pay attention to this argument. For each R\bRR\bRA\bA which includes
- this argument, there is a dependency between that R\bRR\bRA\bA and another R\bRR\bRA\bA.
- The _\br_\br_\ba_\b-_\bn_\bu_\bm argument is the 1-based index in the order of R\bRR\bRA\bA creation
- (that is, the order they appear in the _\bc_\br_\be_\ba_\bt_\be command). The dependent
- R\bRR\bRA\bA for each R\bRR\bRA\bA requiring the _\br_\br_\ba_\b-_\bn_\bu_\bm argument is listed here:
+ _\br_\br_\ba_\b-_\bn_\bu_\bm provides the links between related R\bRR\bRA\bAs\bs. If HWPREDICT is
+ specified alone and the other R\bRR\bRA\bAs\bs are created implicitly, then there
+ is no need to worry about this argument. If R\bRR\bRA\bAs\bs are created
+ explicitly, then carefully pay attention to this argument. For each R\bRR\bRA\bA
+ which includes this argument, there is a dependency between that R\bRR\bRA\bA
+ and another R\bRR\bRA\bA. The _\br_\br_\ba_\b-_\bn_\bu_\bm argument is the 1-based index in the order
+ of R\bRR\bRA\bA creation (that is, the order they appear in the _\bc_\br_\be_\ba_\bt_\be command).
+ The dependent R\bRR\bRA\bA for each R\bRR\bRA\bA requiring the _\br_\br_\ba_\b-_\bn_\bu_\bm argument is listed
+ here:
ยท HWPREDICT _\br_\br_\ba_\b-_\bn_\bu_\bm is the index of the SEASONAL R\bRR\bRA\bA.
@@ -341,9 +326,9 @@ 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\b
_\bw_\bi_\bn_\bd_\bo_\bw _\bl_\be_\bn_\bg_\bt_\bh is the number of time points in the window. Specify an
integer greater than or equal to the threshold and less than or equal
- to 28. The time interval this window represents depends on the inter-
- val between primary data points. If the FAILURES R\bRR\bRA\bA is implicitly cre-
- ated, the default value is 9.
+ to 28. The time interval this window represents depends on the
+ interval between primary data points. If the FAILURES R\bRR\bRA\bA is implicitly
+ created, the default value is 9.
T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
Here is an explanation by Don Baarda on the inner workings of RRDtool.
@@ -354,13 +339,14 @@ T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
builds Primary Data Points (PDPs) on every "step" interval. The PDPs
are then accumulated into the RRAs.
- The "heartbeat" defines the maximum acceptable interval between sam-
- ples/updates. If the interval between samples is less than "heartbeat",
- then an average rate is calculated and applied for that interval. If
- the interval between samples is longer than "heartbeat", then that
- entire interval is considered "unknown". Note that there are other
- things that can make a sample interval "unknown", such as the rate
- exceeding limits, or a sample that was explicitly marked as unknown.
+ The "heartbeat" defines the maximum acceptable interval between
+ samples/updates. If the interval between samples is less than
+ "heartbeat", then an average rate is calculated and applied for that
+ interval. If the interval between samples is longer than "heartbeat",
+ then that entire interval is considered "unknown". Note that there are
+ other things that can make a sample interval "unknown", such as the
+ rate exceeding limits, or a sample that was explicitly marked as
+ unknown.
The known rates during a PDP's "step" interval are used to calculate an
average rate for that PDP. If the total "unknown" time accounts for
@@ -374,10 +360,10 @@ T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
multiple samples per PDP, and if you don't get them mark the PDP
unknown. A long heartbeat can span multiple "steps", which means it is
acceptable to have multiple PDPs calculated from a single sample. An
- extreme example of this might be a "step" of 5 minutes and a "heart-
- beat" of one day, in which case a single sample every day will result
- in all the PDPs for that entire day period being set to the same aver-
- 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>
+ extreme example of this might be a "step" of 5 minutes and a
+ "heartbeat" of one day, in which case a single sample every day will
+ result in all the PDPs for that entire day period being set to the same
+ average 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>
time|
axis|
Here are a few hints on how to measure:
Temperature
- Usually you have some type of meter you can read to get the temper-
- ature. The temperature is not really connected with a time. The
- only connection is that the temperature reading happened at a cer-
- tain time. You can use the G\bGA\bAU\bUG\bGE\bE data source type for this. RRDtool
- will then record your reading together with the time.
+ Usually you have some type of meter you can read to get the
+ temperature. The temperature is not really connected with a time.
+ The only connection is that the temperature reading happened at a
+ certain time. You can use the G\bGA\bAU\bUG\bGE\bE data source type for this.
+ RRDtool will then record your reading together with the time.
Mail Messages
- Assume you have a method to count the number of messages trans-
- ported by your mailserver in a certain amount of time, giving you
- data like '5 messages in the last 65 seconds'. If you look at the
- count of 5 like an A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE data type you can simply update the RRD
- with the number 5 and the end time of your monitoring period. RRD-
- tool will then record the number of messages per second. If at some
- later stage you want to know the number of messages transported in
- a day, you can get the average messages per second from RRDtool for
- the day in question and multiply this number with the number of
- seconds in a day. Because all math is run with Doubles, the preci-
- sion should be acceptable.
+ Assume you have a method to count the number of messages
+ transported by your mailserver in a certain amount of time, giving
+ you data like '5 messages in the last 65 seconds'. If you look at
+ the count of 5 like an A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE data type you can simply update the
+ RRD with the number 5 and the end time of your monitoring period.
+ RRDtool will then record the number of messages per second. If at
+ some later stage you want to know the number of messages
+ transported in a day, you can get the average messages per second
+ from RRDtool for the day in question and multiply this number with
+ the number of seconds in a day. Because all math is run with
+ Doubles, the precision should be acceptable.
It's always a Rate
- RRDtool stores rates in amount/second for COUNTER, DERIVE and ABSO-
- LUTE data. When you plot the data, you will get on the y axis
+ RRDtool stores rates in amount/second for COUNTER, DERIVE and
+ ABSOLUTE data. When you plot the data, you will get on the y axis
amount/second which you might be tempted to convert to an absolute
amount by multiplying by the delta-time between the points. RRDtool
plots continuous data, and as such is not appropriate for plotting
RRA:MAX:0.5:12:2400 \
RRA:AVERAGE:0.5:12:2400
- 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-
- ture value every 300 seconds. If no new data is supplied for more than
- 600 seconds, the temperature becomes _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. The minimum acceptable
- value is -273 and the maximum is 5'000.
+ 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
+ temperature value every 300 seconds. If no new data is supplied for
+ more than 600 seconds, the temperature becomes _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. The minimum
+ acceptable value is -273 and the maximum is 5'000.
A few archive areas are also defined. The first stores the temperatures
supplied for 100 hours (1'200 * 300 seconds = 100 hours). The second
RRA stores the minimum temperature recorded over every hour (12 * 300
seconds = 1 hour), for 100 days (2'400 hours). The third and the fourth
- RRA's do the same for the maximum and average temperature, respec-
- tively.
+ RRA's do the same for the maximum and average temperature,
+ respectively.
E\bEX\bXA\bAM\bMP\bPL\bLE\bE 2\b2
rrdtool create monitor.rrd --step 300 \
argument of HWPREDICT is missing, so the other R\bRR\bRA\bAs\bs will implicitly be
created with default parameter values. In this example, the forecasting
algorithm baseline adapts quickly; in fact the most recent one hour of
- observations (each at 5 minute intervals) accounts for 75% of the base-
- line prediction. The linear trend forecast adapts much more slowly.
+ observations (each at 5 minute intervals) accounts for 75% of the
+ baseline prediction. The linear trend forecast adapts much more slowly.
Observations made during the last day (at 288 observations per day)
- account for only 65% of the predicted linear trend. Note: these compu-
- tations rely on an exponential smoothing formula described in the LISA
- 2000 paper.
+ account for only 65% of the predicted linear trend. Note: these
+ computations rely on an exponential smoothing formula described in the
+ LISA 2000 paper.
- The seasonal cycle is one day (288 data points at 300 second inter-
- vals), and the seasonal adaption parameter will be set to 0.1. The RRD
- file will store 5 days (1'440 data points) of forecasts and deviation
- predictions before wrap around. The file will store 1 day (a seasonal
- cycle) of 0-1 indicators in the FAILURES R\bRR\bRA\bA.
+ The seasonal cycle is one day (288 data points at 300 second
+ intervals), and the seasonal adaption parameter will be set to 0.1. The
+ RRD file will store 5 days (1'440 data points) of forecasts and
+ deviation predictions before wrap around. The file will store 1 day (a
+ seasonal cycle) of 0-1 indicators in the FAILURES R\bRR\bRA\bA.
The same RRD file and R\bRR\bRA\bAs\bs are created with the following command,
which explicitly creates all specialized function R\bRR\bRA\bAs\bs.
RRA:DEVSEASONAL:288:0.1:2 \
RRA:FAILURES:288:7:9:5
- Of course, explicit creation need not replicate implicit create, a num-
- ber of arguments could be changed.
+ Of course, explicit creation need not replicate implicit create, a
+ number of arguments could be changed.
E\bEX\bXA\bAM\bMP\bPL\bLE\bE 3\b3
rrdtool create proxy.rrd --step 300 \
In the R\bRR\bRD\bD, the first data source stores the requests per second rate
during the interval. The second data source stores the total duration
- of all requests processed during the interval divided by 300. The COM-
- PUTE data source divides each PDP of the AccumDuration by the corre-
- sponding PDP of TotalRequests and stores the average request duration.
- The remainder of the RPN expression handles the divide by zero case.
+ of all requests processed during the interval divided by 300. The
+ COMPUTE data source divides each PDP of the AccumDuration by the
+ corresponding PDP of TotalRequests and stores the average request
+ duration. The remainder of the RPN expression handles the divide by
+ zero case.
A\bAU\bUT\bTH\bHO\bOR\bR
Tobias Oetiker <tobi@oetiker.ch>
-1.3rc4 2008-05-12 RRDCREATE(1)
+1.3.8 2008-06-11 RRDCREATE(1)