Neue Munin Nodes werden nicht erkannt

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
cirox
Beiträge: 70
Registriert: 23.06.2006 20:37:57

Neue Munin Nodes werden nicht erkannt

Beitrag von cirox » 08.04.2011 16:56:13

Hallo,

ich hab vor ein paar Tagen angefangen mit Munin zu arbeiten. Soweit klapt es ja eigenlich auch ganz gut, da die Installation unter Ubuntu eigentlich idiotensicher ist.
Allerdings habe ich jetzt Probleme mit den Munin-Nodes der anderen Server.

Ich hab ca. 5 Server hinzugefügt. Local geht ohne Probleme, Srv1 wird auch noch angezeigt, alle weiteren Server werden allerdings nicht mehr angezeigt.
Wenn ich die Server wieder aus der Conf lösche, dauert es ewig bis Munin das aktualisiert bzw. übernimmt es manchmal überhaupt nicht. Obwohl ich auch die Cronjobs von Munin alle auf max. 1min. gesetzt habe.
Gibt es beim erstellen/hinzufügen der Nodes irgendetwas zu beachten ?

Im mom habe ich wieder die Standardconfig mit zwei Beispiel Nodes. Diese werden komischerweise nicht mal in der Übersicht angezeigt.
{{{#!code bash
# 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

[webserver.beispiel]
address 192.168.0.10

[sqlserver.beispiel]
address 192.168.0.11

# 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
#
}}}
im munin-html.log steht folgender Fehler:
2011/04/08 16:25:02 Opened log file
2011/04/08 16:25:02 [INFO] Starting munin-html, getting lock /var/run/munin/munin-html.lock
2011/04/08 16:25:02 [FATAL] There is nothing to do here, since there are no nodes with any plugins. Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs at /usr/share/munin/munin-html line 38
2011/04/08 16:29:02 Opened log file
2011/04/08 16:29:02 [INFO] Starting munin-html, getting lock /var/run/munin/munin-html.lock
2011/04/08 16:29:02 [INFO] Process 9415 is dead, stealing lock, removing file
2011/04/08 16:29:02 [FATAL] There is nothing to do here, since there are no nodes with any plugins. Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs at /usr/share/munin/munin-html line 38
Munin-node-configure.log zeigt folgendes an:
Apr 06 17:04:00 - Starting munin-node-configure --shell
ln -s '/usr/share/munin/plugins/cpu' '/etc/munin/plugins/cpu'
ln -s '/usr/share/munin/plugins/df' '/etc/munin/plugins/df'
ln -s '/usr/share/munin/plugins/df_inode' '/etc/munin/plugins/df_inode'
ln -s '/usr/share/munin/plugins/diskstats' '/etc/munin/plugins/diskstats'
ln -s '/usr/share/munin/plugins/entropy' '/etc/munin/plugins/entropy'
ln -s '/usr/share/munin/plugins/forks' '/etc/munin/plugins/forks'
ln -s '/usr/share/munin/plugins/fw_packets' '/etc/munin/plugins/fw_packets'
ln -s '/usr/share/munin/plugins/if_' '/etc/munin/plugins/if_eth0'
ln -s '/usr/share/munin/plugins/if_err_' '/etc/munin/plugins/if_err_eth0'
ln -s '/usr/share/munin/plugins/interrupts' '/etc/munin/plugins/interrupts'
ln -s '/usr/share/munin/plugins/iostat' '/etc/munin/plugins/iostat'
ln -s '/usr/share/munin/plugins/iostat_ios' '/etc/munin/plugins/iostat_ios'
ln -s '/usr/share/munin/plugins/irqstats' '/etc/munin/plugins/irqstats'
ln -s '/usr/share/munin/plugins/load' '/etc/munin/plugins/load'
ln -s '/usr/share/munin/plugins/memory' '/etc/munin/plugins/memory'
ln -s '/usr/share/munin/plugins/munin_stats' '/etc/munin/plugins/munin_stats'
ln -s '/usr/share/munin/plugins/open_files' '/etc/munin/plugins/open_files'
ln -s '/usr/share/munin/plugins/open_inodes' '/etc/munin/plugins/open_inodes'
ln -s '/usr/share/munin/plugins/proc_pri' '/etc/munin/plugins/proc_pri'
ln -s '/usr/share/munin/plugins/processes' '/etc/munin/plugins/processes'
ln -s '/usr/share/munin/plugins/swap' '/etc/munin/plugins/swap'
ln -s '/usr/share/munin/plugins/threads' '/etc/munin/plugins/threads'
ln -s '/usr/share/munin/plugins/uptime' '/etc/munin/plugins/uptime'
ln -s '/usr/share/munin/plugins/users' '/etc/munin/plugins/users'
ln -s '/usr/share/munin/plugins/vmstat' '/etc/munin/plugins/vmstat'
The following errors were reported by munin-node-configure --shell
# The following plugins caused errors:
# ip_:
# Nothing printed to stdout
# No valid suggestions
# mysql_:
# Non-zero exit during autoconf (2)
# postfix_mailqueue:
# Non-zero exit during autoconf (255)
# postgres_bgwriter:
# Non-zero exit during autoconf (255)
# postgres_cache_:
# Non-zero exit during autoconf (255)
# postgres_checkpoints:
# Non-zero exit during autoconf (255)
# postgres_connections_:
# Non-zero exit during autoconf (255)
# postgres_connections_db:
# Non-zero exit during autoconf (255)
# postgres_locks_:
# Non-zero exit during autoconf (255)
# postgres_querylength_:
# Non-zero exit during autoconf (255)
# postgres_scans_:
# Non-zero exit during autoconf (255)
# postgres_size_:
# Non-zero exit during autoconf (255)
# postgres_transactions_:
# Non-zero exit during autoconf (255)
# postgres_tuples_:
# Non-zero exit during autoconf (255)
# postgres_users:
# Non-zero exit during autoconf (255)
# postgres_xlog:
# Non-zero exit during autoconf (255)
# tomcat_:
# Non-zero exit during autoconf (127)

syssi
Beiträge: 2951
Registriert: 24.12.2010 16:50:59
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Rheinland

Re: Neue Munin Nodes werden nicht erkannt

Beitrag von syssi » 12.04.2011 08:50:53

Hi,
cirox hat geschrieben: Gibt es beim erstellen/hinzufügen der Nodes irgendetwas zu beachten ?
auf jeder Node findest du eine /etc/munin/munin-node.conf . Dort gibt es eine Zeile, die im Default so aussieht:

Code: Alles auswählen

allow ^127\.0\.0\.1$                                                                                                                                                                      
Schreib darunter eine weitere mit der IP deiner Master-Node:

Code: Alles auswählen

allow ^xxx\.xxx\.xxx\.xxx$ 
Anschließend ist ein Restart der Node notwendig: /etc/init.d/munin-node restart. Zum Test kannst du dich auf deinem Server einloggen, wo die Master-Node laeuft und per Telnet die Verbindung testen:

Code: Alles auswählen

telnet muninnode1 4949
Mit "list" erhaeltst du eine Liste der aktivierten Plugins. Mit "fetch plugin_name" die aktuellen Daten. Mit "config plugin_name" die aktuelle Konfiguration des Plugins.

Gruß syssi

cirox
Beiträge: 70
Registriert: 23.06.2006 20:37:57

Re: Neue Munin Nodes werden nicht erkannt

Beitrag von cirox » 12.04.2011 09:23:30

danke für deine Hinweise. Hat jetzt auch soweit geklappt. Schuld war der nicht freigegebene Port in iptabels.

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

Re: Neue Munin Nodes werden nicht erkannt

Beitrag von ThorstenS » 12.04.2011 09:49:13

Dann ersetz mal dein DROP durch ein REJECT - ist IMHO eh viel ehrlicher.

cirox
Beiträge: 70
Registriert: 23.06.2006 20:37:57

Re: Neue Munin Nodes werden nicht erkannt

Beitrag von cirox » 12.04.2011 09:55:20

ok

Quix0r
Beiträge: 23
Registriert: 05.04.2011 18:48:10
Wohnort: Krefeld, Germany
Kontaktdaten:

Re: Neue Munin Nodes werden nicht erkannt

Beitrag von Quix0r » 25.04.2011 10:05:22

Das mit Ehrlichkeit ist aber auch eine Ehrlichkeit gegenueber Angreifer. DROP "verschluckt" das Paket, hingegen REJECT lehnt es ab. Fausregel: Und da wo abgelehnt wird, ist auch eine Firewall; da wo ein Paket nicht zurueckkommt (timeout) ist vielleicht was nicht mehr da. :) Einige Billig-Firewalls (hautpsaechlich "Personal Firewalls") sagen dazu auch "Stealth-Modus".

Oder anders gesagt: REJECT ist unsicherer, DROP ist sicherer.

Antworten