mrtg.cfg

mrtg 监控,请认真阅读您的文件包然后写出其具体功能

######################################################################
# Multi Router Traffic Grapher -- Example Configuration File
######################################################################
#
# * copy this file to ../run and call it mrtg.cfg
# * consider using ../run/cfgmaker to build your initial mrtg.cfg file
#
# This file is for use with mrtg-2.x
#
# Note:
#
# * Keywords must start at the begin of a line.
#
# * Lines which follow a keyword line which do start 
#   with a blank are appended to the keyword line
#
# * Empty Lines are ignored
#
# * Lines starting with a # sign are comments.


# ####################
# Global Configuration 
# ####################

# Where should the logfiles, and webpages be created?

WorkDir: /usr/tardis/pub/www/stats/mrtg
Options[_]: growright,bits

# --------------------------
# Optional Global Parameters
# --------------------------

# How many seconds apart should the browser (Netscape) be 
# instructed to reload the page? If this is not defined, the 
# default is 300 seconds (5 minutes).

# Refresh: 600

# How often do you call mrtg? The default is 5 minutes. If
# you call it less often, you should specify it here. This
# does two things:

# a) the generated HTML page does contain the right
#    information about the calling interval ...

# b) a META header in the generated HTML page will instruct
#    caches about the time to live of this page .....

# In this example we tell mrtg that we will be calling it
# every 10 minutes. If you are calling mrtg every 5
# minutes, you can leave this line commented out.

# Interval: 10

# With this switch mrtg will generate .meta files for CERN
# and Apache servers which contain Expiration tags for the
# html and gif files. The *.meta files will be created in
# the same directory as the other files, so you might have
# to set "MetaDir ." in your srm.conf file for this to work
#
# NOTE: If you are running Apache-1.2 you can use the mod_expire
# to achieve the same effect ... see the file htaccess-dist

#WriteExpires: Yes


# If you want to keep the mrtg icons in some place other than the 
# working directory, use the IconDir varibale to give its url.

# IconDir: /mrtgicons/


# #################################################
# Configuration for each Target you want to monitor
# #################################################

# The configuration keywords "Target" must be followed by a
# unique name. This will also be the name used for the
# webpages, logfiles and gifs created for that target.

# Note that the "Target" sections can be auto-generated with
# the cfgmaker tool. Check readme.html for instructions.
#     ========

##
## Target ----------------------------------------
## 

# With the "Target" keyword you tell mrtg what it should
# monitor. The "Target" keyword takes arguments in a wide
# range of formats:

# * The most basic format is "port:community@router"
#   This will generate a traffic graph for port 'port'
#   of the router 'router' and it will use the community
#   'community' for the snmp query.
 
# Target[ezwf]: 2:[e-mail]

# * Sometimes you are sitting on the wrong side of the
#   link. And you would like to have mrtg report Incoming
#   traffic as outgoing and visa versa. This can be achieved
#   by adding the '-' sign in front of the "Target"
#   description. It flips the in and outgoing traffic rates.

# Target[ezci]: -1:[e-mail]

# * You can also explicitly define the OID to query by using the
#   following syntax 'OID_1&OID_2:community@router'
#   The following example will retrieve error input and output
#   octets/sec on interface 1.  MRTG needs to graph two values, so
#   you need to specify two OID's such as temperature and humidity
#   or error input and error output.

# Target[ezwf]: 1.3.6.1.2.1.2.2.1.14.1&1.3.6.1.2.1.2.2.1.20.1:public@myrouter

# * mrtg knows a number of symbolical SNMP variable
#   names. See the file mibhelp.txt for a list of known
#   names. One example are the ifInErrors and and ifOutErrors
#   names. This means you can specify the above as:

# Target[ezwf]: ifInErrors.1&ifOutErrors.1:public@myrouter

# * 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 'incoming bytes counter'
#     Line 2 : current state of the 'outgoing bytes counter'
#     Line 3 : string, 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.

# Target[ezwf]: `/usr/local/bin/df2mrtg /dev/dsk/c0t2d0s0`

# * You can also use several statements in a mathematical 
#   expression.  This could be used to aggregate both B channels
#   in an ISDN connection or multiple T1's that are aggregated
#   into a single channel for greater bandwidth.
#   Note the whitespace arround the target definitions.

# Target[ezwf]: 2:public@wellfleetA + 1:public@wellfleetA
#              * 4:public@ciscoF

##
## RouterUptime ---------------------------------------
##
#
# In cases where you calculate the used bandwidth from
# several interfaces you normaly don't get the routeruptime
# and routername displayed on the web page.
# If this interface are on the same router and the uptime and
# name should be displayed nevertheless you have to specify
# its community and address again with the RouterUptime keyword.

# Target[kacisco]: 1:public@194.64.66.250 + 2:public@194.64.66.250
# RouterUptime[kacisco]: public@194.64.66.250

##
## RouterName -----------------------------------------
##
#

# If the default name of the router is incorrect/uninformative,
# you can use RouterName to specify a different OID on either the
# same or a different host.

# Use 1.3.6.1.4.1.4779.1.1.3.0 on the same host:
# RouterName[kacisco]: 1.3.6.1.4.1.4779.1.1.3.0

# Use 1.3.6.1.4.1.4779.1.1.3.0 on a differnet host (194.64.66.251):
# RouterName[kacisco]: 1.3.6.1.4.1.4779.1.1.3.0:public@194.64.66.251


##
## MaxBytes -------------------------------------------
##

# How many bytes per second can this port carry. Since most
# links are rated in bits per second, you need to divide
# their maximum bandwidth (in bits) by eight (8) in order to get
# bytes per second.  This is very important to make your
# unscaled graphs display realistic information.  
# T1 = 193000, 56K = 7000, Ethernet = 1250000. The "MaxBytes"
# value will be used by mrtg to decide whether it got a
# valid response from the router. If a number higher than
# "MaxBytes" is returned, it is ignored. Also read the section
# on AbsMax for further info.

# MaxBytes[ezwf]: 1250000

##
## Title -----------------------------------------------
##

# Title for the HTML page which gets generated for the graph.

# Title[ezwf]: Traffic Analysis for ETZ C 95.1

##
## PageTop ---------------------------------------------
##

# Things to add to the top of the generated HTML page.  Note
# that you can have several lines of text as long as the
# first column is empty.
# Note that the continuation lines will all end up on the same
# line in the html page. If you want linebreaks in the generated 
# html use the '\n' sequence.

# PageTop[ezwf]: <H1>Traffic Analysis for ETZ C95.1</H1>
#  Our Campus Backbone runs over an FDDI line\n
#  with a maximum transfer rate of 12.5 Mega Bytes per
#  Second.

##
## PageFoot ---------------------------------------------
##

# Things to add at the very end of the mrtg generated html page

# PageFoot[ezwf]: <HR size=2 noshade>This page is managed by Blubber

# --------------------------------------------------
# Optional Target Configuration Tags
# --------------------------------------------------

##
## AddHead -----------------------------------------
##

# Use this tag like the PageTop header, but its contents
# will be added between </TITLE> and </HEAD>.

# AddHead[ezwf]: <!-- Just a comment for fun -->

##
## AbsMax ------------------------------------------
##

# If you are monitoring a link which can handle more traffic
# than the MaxBytes value. Eg, a line which uses compression
# or some frame relay link, you can use the AbsMax keyword
# to give the absolute maximum value ever to be reached. We
# need to know this in order to sort out unrealistic values
# returned by the routers. If you do not set absmax, rateup
# will ignore values higher then MaxBytes.

# AbsMax[ezwf]: 2500000

##
## Unscaled ------------------------------------------
##

# By default each graph is scaled vertically to make the
# actual data visible even when it is much lower than
# MaxBytes.  With the "Unscaled" variable you can suppress
# this.  It's argument is a string, containing one letter
# for each graph you don't want to be scaled: d=day w=week
# m=month y=year.  In the example I suppress scaling for the
# yearly and the monthly graph.

# Unscaled[ezwf]: ym

##
## WithPeak ------------------------------------------
##

# By default the graphs only contain the average transfer
# rates for incoming and outgoing traffic. The
# following option instructs mrtg to display the peak
# 5 minute transfer rates in the [w]eekly, [m]onthly and
# [y]early graph. In the example we define the monthly
# and the yearly graph to contain peak as well as average
# values.

# WithPeak[ezwf]: ym

##
## Supress ------------------------------------------
##

# By Default mrtg produces 4 graphs. With this option you
# can suppress the generation of selected graphs.  The format
# is analog to the above option. In this example we suppress