About MRTG Per Target conf
时间：2006-02-14 来源：mantou
Per target configuration
Each monitoring target must be identified by a unique name. This name must be appended to each parameter belonging to the same target. The name will also be used for naming the generated webpages, logfiles and images for this target.
Target
With the Target keyword you tell mrtg what it should monitor. The Target keyword takes arguments in a wide range of formats:
Basic The most basic format is ``port:community@router'' This will generate a traffic graph for the interface 'port' of the host 'router' (dns name or IP address) and it will use the community 'community' (snmp password) for the snmp query.Example:
Target[myrouter]: 2:[email protected]
If your community contains a ``@'' or a `` '' these characters must be escaped with a ``\''.
Target[bla]: 2:stu\ pi\@d@routerSNMPv2c If you have a fast router you might want to try to poll the ifHC* counters. This feature gets activated by switching to SNMPv2c. Unfortunately not all devices support SNMPv2c yet. If it works, this will prevent your counters from wraping within the 5 minute polling interval, since we now use 64 bit instead of the normal 32 bit.
Example:
Target[myrouter]: 2:public@router1:::::2SNMPv3 As an alternative to SNMPv2c, SNMPv3 provides access to the ifHC* counters, along with encryption. Not all devices support SNMPv3, and you will also need the perl Net::SNMP library in order to use it. It is recommended that cfgmaker be used to generate configurations involving SNMPv3, as it will check if the Net::SNMP library is loadable, and will switch to SNMPv2c if v3 is unavailable.
SNMP v3 requires additional authentication parameters, passed using the SnmpOptions[] per-target keyword.
Example: Target[myrouter]: 2:router1:::::3 SnmpOptions[myrouter]: username=>'user1'
Reversing Sometimes you are sitting on the wrong side of the link, and you would like to have mrtg report Incoming traffic as Outgoing and vice versa. This can be achieved by adding the '-' sign in front of the ``Target'' description. It flips the incoming and outgoing traffic rates.Example:
Target[ezci]: -1:[email protected]Explicit OIDs You can also explicitly define which OID to query by using the following syntax 'OID_1&OID_2:community@router' The following example will retrieve error counts for input and output on interface 1. MRTG needs to graph two variables, so you need to specify two OID's such as temperature and humidity or error input and error output.
Example:
Target[myrouter]: 1.3.6.1.2.1.2.2.1.14.1&1.3.6.1.2.1.2.2.1.20.1:public@myrouterMIB Variables MRTG knows a number of symbolic SNMP variable names. See the file mibhelp.txt for a list of known names. One example are the ifInErrors and ifOutErrors. This means you can specify the above as:
Example:
Target[myrouter]: ifInErrors.1&ifOutErrors.1:public@myrouterSnmpWalk It may be that you want to monitor an snmp object that is only reachable by 'walking'. You can get mrtg to walk by prepending the OID with the string WaLK or if you want a particular entry from the table returned by the walk you can use WaLKx where x is a number starting from 0 (!).
Example:
Target[myrouter]: WaLKstrangeOid.1&WaLKstrangeOid.2:public@myrouter
Target[myrouter]: WaLK3strangeOid.1&WaLK4strangeOid.2:public@myrouterInterface by IP Sometimes SNMP interface index can change, like when new interfaces are added or removed. This can cause all Target entries in your config file to become offset, causing MRTG to graphs wrong instances etc. MRTG supports IP address instead of ifindex in target definition. Then MRTG will query snmp device and try to map IP address to the current ifindex. You can use IP addresses in every type of target definition by adding IP address of the numbered interface after OID and separation char '/'.
Make sure that the given IP address is used on your same target router, especially when graphing two different OIDs and/or interface split by '&' delimiter.
You can tell cfgmaker to generate such references with the option --ifref=ip.
Example:
Target[myrouter]: /1.2.3.4:[email protected] Target[ezci]: -/1.2.3.4:[email protected] Target[myrouter]: 1.3.6.1.2.1.2.2.1.14/1.2.3.4&1.3.6.1.2.1.2.2.1.14/1.2.3.4:public@myrouter Target[myrouter]: ifInErrors/1.2.3.4&ifOutErrors/1.2.3.4:public@myrouterInterface by Description If you can not use IP addresses you might want to use the interface names. This works similar to the IP address aproach except that the prefix to use is a \ instead of a /
You can tell cfgmaker to generate such references with the option --ifref=descr.
Example:
Target[myrouter]: \My-Interface2:[email protected] Target[ezci]: -\My-Interface2:[email protected] Target[myrouter]: 1.3.6.1.2.1.2.2.1.14\My-Interface2&1.3.6.1.2.1.2.2.1.14\My-Interface3:public@myrouter Target[myrouter]: ifInErrors\My-Interface2&ifOutErrors\My-Interface3:public@myrouter
If your description contains a ``&'', a ``:'', a ``@'' or a `` '' you can include them but you must escape with a backlash:
Target[myrouter]: \fun\:\ ney\&ddd:[email protected]Interface by Name This is the only sensible way to reference the interfaces of your switches.
You can tell cfgmaker to generate such references with the option --ifref=name.
Example:
Target[myrouter]: #2/11:[email protected] Target[ezci]: -#2/11:[email protected] Target[myrouter]: 1.3.6.1.2.1.2.2.1.14#3/7&1.3.6.1.2.1.2.2.1.14#3/7:public@myrouter Target[myrouter]: ifInErrors#3/7&ifOutErrors#3/7:public@myrouter
If your description contains a ``&'', a ``:'', a ``@'' or a `` '' you can include them but you must escape with a backlash:
Target[myrouter]: #\:\ fun:[email protected]
Note that the # sign will be interpreted as a comment character if it is the first non white-space character on the line.
Interface by Ethernet Address When the SNMP interface index changes, you can key that interface by its 'Physical Address', sometimes called a 'hard address', which is the SNMP variable 'ifPhysAddress'. Internally, MRTG matches the Physical Address from the *.cfg file to its current index, and then uses that index for the rest of the session.You can use the Physical Address in every type of target definition by adding the Physical Address after the OID and the separation char '!' (analogous to the IP address option). The Physical address is specified as '-' delimited octets, such as ``0a-0-f1-5-23-18'' (omit the double quotes). Note that some routers use the same Hardware Ethernet Address for all of their Interfaces which prevents unique interface identification. Mrtg will notice such problems and alert you.
You can tell cfgmaker to generate configuration files with hardware ethernet address references by using the option --ifref=eth.
Example:
Target[myrouter]: !0a-0b-0c-0d:[email protected] Target[ezci]: -!0-f-bb-05-71-22:[email protected] Target[myrouter]: 1.3.6.1.2.1.2.2.1.14!0a-00-10-23-44-51&!0a-00-10-23-44-51:public@myrouter Target[myrouter]: ifInErrors!0a-00-10-23-44-51&ifOutErrors!0a-00-10-23-44-51:public@myrouterInterface by Type It seems that there are devices that try to defy all monitoring efforts: the interesting interfaces have neither ifName nor a constant ifDescr not to mention a persistant ifIndex. The only way to get a constant mapping is by looking at the interface type, because the interface you are interested in is unique in the device you are looking at ...
You can tell cfgmaker to generate such references with the option --ifref=type.
Example:
Target[myrouter]: %13:[email protected] Target[ezci]: -%13:[email protected] Target[myrouter]: 1.3.6.1.2.1.2.2.1.14%13&1.3.6.1.2.1.2.2.1.14%14:public@myrouter Target[myrouter]: ifInErrors%13&ifOutErrors%14:public@myrouterExtended Host Name Syntax In all places where ``community@router'' is accepted, you can add additional parameters for the SNMP communication using colon-separated suffixes. You can also append a pipe symbol ( | ) and the name of a numeric conversion subroutine as described under the global keyword ``ConversionCode'' above. The full syntax is as follows:
community@router[:[port][:[timeout][:[retries][:[backoff][:[version]][|name]]]]]
where the meaning of each parameter is as follows:
port the UDP port under which to contact the SNMP agent (default: 161) timeout initial timeout for SNMP queries, in seconds (default: 2.0) retries number of times a timed-out request will be retried (default: 5) backoff factor by which the timeout is multiplied on every retry (default: 1.0). version for SNMP version. If you have a fast router you might want to put a '2' here. For authenticated or encrypted SNMP, you can try to put a '3' here. This will make mrtg try to poll the 64 bit counters and thus prevent excessive counter wrapping. Not all routers support this though. SNMP v3 requires additional setup, see SnmpOptions[] for full details.Example:
3:public@router1:::::2name the name of the subroutine that MRTG will call to convert the input and output values to integers. See the complete example under the global keyword ``ConversionCode'' above.
Example:
1.3.6.1.4.1.999.1&1.3.6.1.4.1.999.2:public@mydevice:161::::2|Length2Int
This would retrieve values from the OID 1.3.6.1.4.1.999.1 for input and .2 for output on mydevice using UDP port 161 and SNMP version 2, and would execute the user-defined numeric conversion subroutine Length2Int to convert those values to integers.
A value that equals the default value can be omitted. Trailing colons can be omitted, too. The pipe symbol followed by the name parameter, if present, must come at the end. There must be no spaces around the colons or pipe symbol.
Example:
Target[ezci]: 1:[email protected]:9161::4
This would refer to the input/output octet counters for the interface with ifIndex 1 on ezci-ether.ethz.ch, as known by the SNMP agent listening on UDP port 9161. The standard initial timeout (2.0 seconds) is used, but the number of retries is set to four. The backoff value is the default.
Numeric IPv6 addresses If IPv6 is enabled you may also specify a target using its IPv6 address. To avoid ambiguity with the port number, numeric IPv6 addresses must be placed in square brackets.Example:
Target[IPv6test]: 2:public@[2001:760:4::]:6161::4External Monitoring Scripts If you want to monitor something which does not provide data via snmp you can use some external program to do the data gathering.
The external command must return 4 lines of output:
Line 1 current state of the first variable, normally 'incoming bytes count' Line 2 current state of the second variable, normally 'outgoing bytes count' Line 3 string (in any human readable format), telling the uptime of the target. Line 4 string, telling the name of the target.Depending on the type of data your script returns you might want to use the 'gauge' or 'absolute' arguments for the Options keyword.
Example:
Target[myrouter]: `/usr/local/bin/df2mrtg /dev/dsk/c0t2d0s0`
Note the use of the backticks (`), not apostrophes (') around the command.
If you want to use a backtick in the command name this can be done but you must escape it with a backslash ...
If your script does not have any data to return but does not want mrtg to complain about invalid data, it can return 'UNKNOWN' instead of a number. Note though that only rrdtool is realy equipped to handle unknown data well.
Multi Target Syntax You can also combine several target definitions in a mathematical expression. Any syntactically correct expression that the Perl interpreter can evaluate to will work. An expression could be used, for example, to aggregate both B channels in an ISDN connection or to calculate the percentage hard disk utilization of a server from the absolute used space and total capacity.Examples:
Target[myrouter]: 2:public@wellfleetA + 1:public@wellfleetA
Target[myrouter]: 1.3.6.1.4.1.999.1&1.3.6.1.4.1.999.2:public@mydevice / 1.3.6.1.4.1.999.3&1.3.6.1.4.1.999.4:public@mydevice * 100
Note that whitespace must surround each target definition in the expression. Target definitions themselves must not contain whitespace, except in interface descriptions and interface names, where each whitespace character is escaped by a backslash.
MRTG automatically rounds the result of the expression to an integer unless RRDTool logging is in use and the gauge option is in effect for the target. Internally MRTG uses Perl's Math::BigFloat package to calculate the result of the expression with 40 digits of precision. Even in extreme cases, where, for example, you take the difference of two 64-bit integers, the result of the expression should be accurate.
SNMP Request Optimization MRTG is designed to economize on its SNMP requests. Where a target definition appears more than once in the configuration file, MRTG requests the data from the device only once per round of data collection and uses the collected data for each instance of a particular target. Recognition of two target definitions as being identical is based on a simple string match rather than any kind of deeper semantic analysis.Example:
Target[Targ1]: 1:public@CiscoA Target[Targ2]: 2:public@CiscoA Target[Targ3]: 1:public@CiscoA + 2:public@CiscoA Target[Targ4]: 1:public@CISCOA
This results in a total of three SNMP requests. Data for 1:public@CiscoA and 2:public@CiscoA are requested only once each, and used for Targ1, Targ2, and Targ3. Targ4 causes another SNMP request for 1:public@CISCOA, which is not recognized as being identical to 1:public@CiscoA.
相关阅读 更多 +
