--- /dev/null
+# Example configuration file for Munin, generated by 'make build'
+
+# The next three variables specifies where the location of the RRD
+# databases, the HTML output, logs and the lock/pid files. They all
+# must be writable by the user running munin-cron. They are all
+# defaulted to the values you see here.
+#
+# dbdir /var/lib/munin
+# htmldir /var/cache/munin/www
+# logdir /var/log/munin
+# rundir /var/run/munin
+#
+# Where to look for the HTML templates
+# tmpldir /etc/munin/templates
+
+# (Exactly one) directory to include all files from.
+#
+includedir /etc/munin/munin-conf.d
+
+# Make graphs show values per minute instead of per second
+#graph_period minute
+
+# Graphics files are normaly generated by munin-graph, no matter if
+# the graphs are used or not. You can change this to
+# on-demand-graphing by following the instructions in
+# http://munin.projects.linpro.no/wiki/CgiHowto
+#
+#graph_strategy cgi
+
+# munin-cgi-graph is invoked by the web server up to very many times at the
+# same time. This is not optimal since it results in high CPU and memory
+# consumption to the degree that the system can thrash. Again the default is
+# 6. Most likely the optimal number for max_cgi_graph_jobs is the same as
+# max_graph_jobs.
+#
+#munin_cgi_graph_jobs 6
+
+# If the automatic CGI url is wrong for your system override it here:
+#
+#cgiurl_graph /cgi-bin/munin-cgi-graph
+
+# munin-graph runs in parallel, the number of concurrent processes is
+# 6. If you want munin-graph to not be parallel set to 0. If set too
+# high it will slow down munin-graph. Some experiments are needed to
+# determine how many are optimal on your system. On a multi-core
+# system with good SCSI disks the number can probably be quite high.
+#
+#max_graph_jobs 6
+
+# Drop somejuser@fnord.comm and anotheruser@blibb.comm an email everytime
+# something changes (OK -> WARNING, CRITICAL -> OK, etc)
+#contact.someuser.command mail -s "Munin notification" somejuser@fnord.comm
+#contact.anotheruser.command mail -s "Munin notification" anotheruser@blibb.comm
+#
+# For those with Nagios, the following might come in handy. In addition,
+# the services must be defined in the Nagios server as well.
+#contact.nagios.command /usr/bin/send_nsca nagios.host.comm -c /etc/nsca.conf
+
+# a simple host tree
+[localhost.localdomain]
+ address 127.0.0.1
+ use_node_name yes
+
+#
+# A more complex example of a host tree
+#
+## First our "normal" host.
+# [fii.foo.com]
+# address foo
+#
+## Then our other host...
+# [fay.foo.com]
+# address fay
+#
+## Then we want totals...
+# [foo.com;Totals] #Force it into the "foo.com"-domain...
+# update no # Turn off data-fetching for this "host".
+#
+# # The graph "load1". We want to see the loads of both machines...
+# # "fii=fii.foo.com:load.load" means "label=machine:graph.field"
+# load1.graph_title Loads side by side
+# load1.graph_order fii=fii.foo.com:load.load fay=fay.foo.com:load.load
+#
+# # The graph "load2". Now we want them stacked on top of each other.
+# load2.graph_title Loads on top of each other
+# load2.dummy_field.stack fii=fii.foo.com:load.load fay=fay.foo.com:load.load
+# load2.dummy_field.draw AREA # We want area instead the default LINE2.
+# load2.dummy_field.label dummy # This is needed. Silly, really.
+#
+# # The graph "load3". Now we want them summarised into one field
+# load3.graph_title Loads summarised
+# load3.combined_loads.sum fii.foo.com:load.load fay.foo.com:load.load
+# load3.combined_loads.label Combined loads # Must be set, as this is
+# # not a dummy field!
+#
+## ...and on a side note, I want them listen in another order (default is
+## alphabetically)
+#
+# # Since [foo.com] would be interpreted as a host in the domain "com", we
+# # specify that this is a domain by adding a semicolon.
+# [foo.com;]
+# node_order Totals fii.foo.com fay.foo.com
+#
+
projects / matthijs / servers / drsnuggles.git / blobdiff