Thursday, May 23rd 2013, 8:10pm UTC+2

You are not logged in.

  • Login
  • Register

net-snmp - Option skipNFSInHostResources - Mountpoint Problem

Dear visitor, welcome to Monitoring-Portal.
Although this is a german monitoring forum, please don't hesitate to post in English. Nearly everybody here understands you and will answer in English as well.
If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form to register here or read more information about the registration process. If you are already registered, please login here.

terratectom

Trainee

Posts: 83

Gender: male

Number of monitoring servers: x

Nagios Version: keine

Icinga Version: 1.8.3

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 600

Number of services: 6500

OS: SuSE SLES Linux

Plugin Version: 1.4.x

NagVis Version: 1.6.x

IDO-Version: 1.8.3

Other Addons: SNMPTT, PNP 0.6.x, Nagvis, Business Process AddOn, EventDB, mod_gearman

1

Wednesday, July 18th 2012, 4:36pm

net-snmp - Option skipNFSInHostResources - Mountpoint Problem

Hallo,

im Zusammenspiel von NFS oder CIFS Mounts und einer SNMP Überwachung eines Servers
kann es zu Störungen der SNMP Überwachung kommen. Dieser Fall tritt ein wenn der NFS
oder CIFS Mount gestört ist, so können die Daten per SNMP nicht mehr ausgelesen werden.

Dieses Problem ist bekannt und ab der net-snmp Version 5.4 gibt es die Option "skipNFSInHostResources true"
mit der NFS oder CIFS Mounts aus der SNMP Überwachung ausgeschlossen werden können.

Soweit ich bisher Recherchiert habe ist dies die einzige Lösung die ich finden konnte.

Nun sind bei uns auch SLES 10, Solaris und MacOS X zuüberwachen, wo diese net-snmp Version
noch nicht vorhanden ist.

Gibt es hier alternative Lösungen über SNMP einen Server ohne den Mountproblem zu überwachen?

Eine Umstellung auf andere Lösungen z.B. nrpe oder check_mk ist nicht gewünscht.


Grüße Tom

bern

Master

Posts: 2,940

Number of monitoring servers: 2-5

Nagios Version: 3.x

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 80-200

Number of services: 1400-2000

OS: Linux

Plugin Version: Whatever I can download, patch, or cobble together myself :-)

Other Addons: n2rrd, PNP, livestatus

2

Wednesday, July 18th 2012, 6:41pm

Wenn der NFS Server nicht mehr mitmacht, bleiben Zugriffe auf dem Client im Kernel Mode stecken (Status D = "Uninterruptible sleep"). Wenn das der (einzige) snmpd-Prozeß ist, dann ist SNMP auf der Maschine anschließend in Mors - meines Wissens bis zum Reboot (da der Prozeß den UDP Port blockiert hält und anders nicht wegzubekommen ist). Ohne die Zugriffe irgendwie zu vermeiden, ob jetzt (wie durch besagte Option) im snmpd oder per Config-/Plugin-Änderung auf Nagios-Seite, ist also kein Blumentopf zu gewinnen. Im zweiten Fall können natürlich auch immer noch andere SNMP Clients den snmpd in diese Falle jagen.

Wenn man den Tod des snmpd irgendwie verhindern kann, kann man sich darum kümmern, wie Nagios die äquivalente Information von ihm abfragen kann, ohne daß der snmpd selbst dabei stirbt. Da kämen dann wohl in erster Linie die Agent Extension Mechanismen des Net-SNMP snmpd in Frage, wobei ich nur bei der AgentX-Variante einen Timeout in der Config-Syntax sehe, mit dem sich der snmpd eventuell selbst von leichenstarren externen Prozessen losschneiden kann. In allen anderen Fällen müßte die zu bauende Extension wohl selbst dafür sorgen, daß trotz totem Mount noch ein Resultat an den snmpd geht.

Die blockierten Prozesse stapeln sich und sie sind keine Zombies, insbesondere belegen sie auch weiter vMem der Maschine. Wo ich bisher (allerdings ohne SNMP) NFS Mounts auf Funktion überwacht habe, war es deshalb das wichtigste Feature, daß nach einem "Verdacht auf Tod" nur noch in großen Abständen ein wirklicher Test ausgeführt (und bis dahin nur der gecachete Error zurückgegeben) wurde.

Similar threads