Mein Vortrag zu SNMP auf der FrOSCon ist vorbei, die Folien stelle ich per slideshare zur Verfügung.
Sehr interessant waren die Anmerkunden einiger erfahrener SNMP-Anwender aus dem Publikum.
Eine Anmerkung bezog sich darauf, dass für den Versand von SNMP Traps UDP zum Einsatz kommt und man damit keine Garantie hat, dass die Traps tatsächlich ankommen. Das muss man natürlich beachten, es gibt aber durchaus Möglichkeiten, damit umzugehen.
Eine Möglichkeit ist, die Trap wie folgt zu versenden:
snmptrap -v 2c -c public -Ci 172.16.166.129 "" NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification netSnmpExampleHeartbeatRate i 123456
Die Angabe von -Ci bewirkt, dass snmptrap eine Bestätigung vom Trap-Empfänger erwartet und die Trap wiederholt, falls diese ausbleibt. Das kann dann dazu führen, dass die Trap mehrfach versendet wird, was aber im Austausch für die gewonnene Sicherheit durchaus zu verschmerzen ist.
Eine andere Möglichkeit besteht darin, bei Net-SNMP und Net::SNMP in Perl, die Trap über TCP zu versenden.
Dazu ist folgende Änderung an der snmptrapd.conf notwendig:
# Traps für die community public annehmen
authCommunity log,execute,net public
# Traps über TCP Port 162 annehmen
snmpTrapdAddr TCP:162
# Traps über UDP Port 162 annehmen
snmpTrapdAddr UDP:162
# Traps mit SNMPTT weiter verarbeiten
traphandle default /usr/sbin/snmptthandler
snmptrapd nimmt jetzt Traps sowohl via UDP als auch via TCP an.
Der Aufruf von snmptrap ändert sich dann wie folgt:
snmptrap -v 2c -c public TCP:172.16.166.129:162 "" NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification netSnmpExampleHeartbeatRate i 123456
Und die empfangene Trap wird im Log so aussehen:
2012-08-25 17:59:06 <UNKNOWN> [TCP: [172.16.166.1]:51457->[0.0.0.0]:0]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (24312703) 2 days, 19:32:07.03 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatRate = INTEGER: 1234569
Wie man die Traps TCP-basiert mit Perl versenden kann, ist in der Dokumentation zu Net::SNMP im Abschnitt zu Transport Domain Arguments beschrieben.
Allgemein möchte ich zum Thema Monitoring empfehlen, immer ein separates, privates Netz zu verwenden, mit unabhängiger Verkabelung und eigenen Switches (das gleiche mache ich in Produktionsumgebungen immer auch noch einmal für Backups). Damit hat man eine bessere Kontrolle darüber, was in diesem Monitoring-Netz passiert und ist im Monitoring nicht durch hohe Belastung auf dem Produktions-Netz eingeschränkt.
Was man ebenfalls beachten sollte ist, dass der Versand von Monitoring-Benachrichtigungen über E-Mails auch seine Tücken hat. Oftmals wird nicht beachtet, dass eine sofortige Zustellung von E-Mails nicht garantiert ist. Die Standard-Einstellung von Postfix, was die Queue-Lifetime einer E-Mail angeht, ist 5 Tage (siehe postconf(5)) und bei Qmail vergehen sogar 7 Tage, bevor man sicher sein kann, dass die E-Mail zugestellt wurde – oder nicht.
Bei SMS kann man immerhin Zustellberichte anfordern, aber die müssen auch erstmal wieder verarbeitet werden…
Fakt ist: möchte man SNMP Traps über UDP versenden, sollte man wissen, was man tut.
Für das Feedback im Vortrag und die angeregte Diskussion möchte ich mich bei meinen Zuhörern bedanken.
