Viele Dinge sind via SNMP gar nicht zugänglich. Man denke nur an Dateisystemoperationen (Existenz, Timestamp etc. einer Datei), Monitoring auf Netzwerkebene (HTTP-Errors, Latenz, Packet Loss etc.) oder Datenbankabfragen.
Außerdem kann bei Weitem nicht jedes Endgerät SNMP.
Ja, das ist leider eine Krux! Es gibt jede Menge Monitoring Tools: Ganglia, Leamon, Zabbix, NMon+RRD, etc. Wäre es nicht einmal sinnvoll SNMP, oder meinet wegen etwas ähnliches, einheitlich zu verwenden. Statt dessen bastelt jeder seinen eigenen Monitoring Client zusammen und versucht den für soviele Platformen wie möglich zu portieren. Leute, daran sind in den 90ern schon etliche Firmen gestorben!
... und ich wollt bist zur Hälfte deines Satzes noch prahlen, dass ich eh meine selbstgeschriebene Monitoringsoftwaer verwende /: SNMP ist soweit ich das verstanden habe aber ja nur Rohhardware-basierend - man kann aller höchstens die Aktivität des Netzwerkcontrollers kontrollieren, aber nicht von laufender Software, anderer verbauter Hardware oder sonstigen Dingen. Wofür also SNMP? Da reicht dann im Prinzip auch ein Dauerping...
Von M wie Meikel am Mo, 11. August 2008 um 10:10 #
> Viele Dinge sind via SNMP gar nicht zugänglich. Man denke nur an Dateisystemoperationen (Existenz, Timestamp etc. einer Datei), Monitoring auf Netzwerkebene (HTTP-Errors, Latenz, Packet Loss etc.) oder Datenbankabfragen.
Natürlich läßt sich das per SNMP abbilden. Das Protokoll ist ähnlich simpel aufgebaut wie HTTP, aber das reicht ja auch für große, dynamisch generierte Websites, SOAP oder AJAX.
> Außerdem kann bei Weitem nicht jedes Endgerät SNMP.
Naja, wahrscheinlich gibt es ein paar mehr Endgeräte, die SNMP verstehen, als solche, die Zabbix beherrschen. ;-)
Außerdem geht es hier ja nicht um irgendwelche Router, sondern um Monitoring-Agenten, die man z.B. auf einem ganz normalen Linux laufen läßt. Und bevor man das Rad zum x-ten Mal neu erfindet und wieder ein neues Protokoll bastelt, wäre es doch sinnvoll, zum Kommunikation einen bereits existierenden Standard zu nutzen.
Von M wie Meikel am Mo, 11. August 2008 um 10:04 #
Warum Webbrowser? Gibts dafür nicht http? ;-)
SNMP ist erstmal nur das Protokoll, mit dem der Agent angesprochen wird, da kann eine simple, statische MIB hinter stecken aber auch wesentlich mehr Funktionalität.
So is es... Zabbix beherrscht natuerlich auch SNMP, nur bietet ws aben auch das gewisse "Etwas" mehr an Funktionen. Während SNMP "nur" ein Protokoll ist, ist Zabbix ein System. Der Vergleich hinkt also...
Wenn es darum geht Netzwerkdienste und Anwendungen zu überwachen, würde ich eher Nagios empfehlen. Vor allem gibt es eine sehr aktive deutsche Nutzergemeinschaft und für nahezu jede Aufgabe ein passendes Plugin.
Für eine reine SNMP/Netzwerküberwachung sind dagegen openNMS oder Zabbix die bessere Wahl.
Tja, wäre dieser Artikel vielleicht vor 3 Monaten erschienen, hätte ich mir zabbix vielleicht näher angeschaut. Stattdessen habe ich mich selbst durch zahlreiche Tools durchgekämpft und meinen persönlichen Favoriten gefunden. Vielleicht wäre als Vorspann zu diesem Artikel auch eine Übersicht über die bekanntesten Vertreter der Network Monitoring Systeme (NMS) und deren Aufgaben bzw. Funktionen interessant gewesen. Sowas ist natürlich entweder mit viel Vorwissen oder Recherche verbunden - bei mir war es eher Letzteres.
Die Vorstellung von Zabbix hier im Artikel hat in sofern ihren Reiz, als dass Nagios das bekannteste Werkzeug ist und auch so genügend Dokumentation vorhanden ist. Andere Werkzeuge haben durchaus ihre Daseinsberechtigung und bringen ab und zu auch neue Ideen ein. Leider muss sich dann jeder selbst entscheiden, ob er ein neues innovatives Werkzeug verwenden will oder auf Langbewährtes zurück greift.
Ich habe mich persönlich für Nagios 3 als Basis und Centreon 2 (Beta) entschieden. Dadurch kann ich auf viel vorhandener Dokumentation, Erfahrungen und fertigen Plugins bzw. Agenten auf der einen Seite aufbauen und auf der anderen Seite bietet Centreon ein komfortables Frontend für die Konfiguration, Überwachung und Berichterstellung mit Nagios. Diese Kombination würde ich auch weiter empfehlen.
Von "stabil" bei einer Webanwendung ist schwer zu sprechen - aber die internen Strukturen sind weitgehendst fest und seit Beta4 gibt es auch update-Skript zur automatischen Anpassung der Datenbestände. In der aktuellen Fassung kann man centreon schon (sehr) gut benutzen, auch wenn sich hier und da noch kleine Bugs befinden oder Erweiterungen wünschenswert wären. Aus meiner Hobby-Enwticklersicht würde ich jedoch eine RC-Version erst in einem besser dokumentiertem und getestetem Zustand veröffentlichen. Ich glaube die entwickelnde Firma steht unter Zeitdruck und "pusht" die finale 2.0 Version um mit dem Produkt Geld zu verdienen.
Als größtes Hindernis könnte sich jedoch die stark französisch-sprachige community erweisen, weswegen google Sprachtools ein sehr hilfreiches Werkzeug bei der Kommunikation und bei der Dokumentationssuche sind... Das deutsch-sprachige Nagios-Portal (www.nagios-portal.de) hat auch ein aktives Centreon-Forum.
Zitat aus dem Artikel: "Dank der automatischen Erkennung der Netzwerktopologie kann Zabbix sowohl für große Unternehmen als auch für Heimadministratoren interessant sein,"
Zitat aus der Zabbix 1.4 Doku ( http://www.zabbix.com/downloads/ZABBIX%20Manual%20v1.4.pdf ) "It does NOT provide: Discovery of network topology"
Und das war auch mein Wissensstand bei meiner letzten Testinstallation. Was stimmt denn nun? Auto-Discovery meint nicht eine automatische Erkennung der Topologie. Es ist lediglich ein Abscannen von IP Bereichen. Dabei werden z. B. prüfbare Ports festgehalten. Nicht aber verschiedene Netzsegmente sowie Router und Switche erkannt. Jedenfalls nicht so wie sie im Netz eingebunden sind.
Von Manfred Tremmel am Mo, 11. August 2008 um 12:17 #
Immer wieder bei derartigen Anleitung stolpere ich über das "make install". Wieso installieren so viele Admins Software an der Paketverwaltung vorbei? Beim nächsten Update rächt sich das für gewöhnlich (keine Abhängigkeitsprüfung, eventuell höher priorisierte lib in /usr/local, mit denen Distributionsprogramme dann nicht mehr laufen, ...). Nehmt doch einfach checkinstall, wenn schon kein "sauberes" RPM oder DEB gebaut wird, damit ist die Sache in der Paketverwaltung und wenn ein Update zu Inkompatiblitäten führt, kriegt man das in der Regel mit, bevor es zu spät ist.
grüsse, harald
Außerdem kann bei Weitem nicht jedes Endgerät SNMP.
SNMP ist soweit ich das verstanden habe aber ja nur Rohhardware-basierend - man kann aller höchstens die Aktivität des Netzwerkcontrollers kontrollieren, aber nicht von laufender Software, anderer verbauter Hardware oder sonstigen Dingen. Wofür also SNMP? Da reicht dann im Prinzip auch ein Dauerping...
http://forums.cacti.net/about12742.html
Natürlich läßt sich das per SNMP abbilden. Das Protokoll ist ähnlich simpel aufgebaut wie HTTP, aber das reicht ja auch für große, dynamisch generierte Websites, SOAP oder AJAX.
> Außerdem kann bei Weitem nicht jedes Endgerät SNMP.
Naja, wahrscheinlich gibt es ein paar mehr Endgeräte, die SNMP verstehen, als solche, die Zabbix beherrschen. ;-)
Außerdem geht es hier ja nicht um irgendwelche Router, sondern um Monitoring-Agenten, die man z.B. auf einem ganz normalen Linux laufen läßt. Und bevor man das Rad zum x-ten Mal neu erfindet und wieder ein neues Protokoll bastelt, wäre es doch sinnvoll, zum Kommunikation einen bereits existierenden Standard zu nutzen.
SNMP ist erstmal nur das Protokoll, mit dem der Agent angesprochen wird, da kann eine simple, statische MIB hinter stecken aber auch wesentlich mehr Funktionalität.
Vor allem gibt es eine sehr aktive deutsche Nutzergemeinschaft und für nahezu jede Aufgabe ein passendes Plugin.
Für eine reine SNMP/Netzwerküberwachung sind dagegen openNMS oder Zabbix die bessere Wahl.
Vielleicht wäre als Vorspann zu diesem Artikel auch eine Übersicht über die bekanntesten Vertreter der Network Monitoring Systeme (NMS) und deren Aufgaben bzw. Funktionen interessant gewesen. Sowas ist natürlich entweder mit viel Vorwissen oder Recherche verbunden - bei mir war es eher Letzteres.
Die Vorstellung von Zabbix hier im Artikel hat in sofern ihren Reiz, als dass Nagios das bekannteste Werkzeug ist und auch so genügend Dokumentation vorhanden ist. Andere Werkzeuge haben durchaus ihre Daseinsberechtigung und bringen ab und zu auch neue Ideen ein. Leider muss sich dann jeder selbst entscheiden, ob er ein neues innovatives Werkzeug verwenden will oder auf Langbewährtes zurück greift.
Ich habe mich persönlich für Nagios 3 als Basis und Centreon 2 (Beta) entschieden. Dadurch kann ich auf viel vorhandener Dokumentation, Erfahrungen und fertigen Plugins bzw. Agenten auf der einen Seite aufbauen und auf der anderen Seite bietet Centreon ein komfortables Frontend für die Konfiguration, Überwachung und Berichterstellung mit Nagios. Diese Kombination würde ich auch weiter empfehlen.
wie sind Deine bisherigen Erfahrungen mit Centreon?
Läuft der aktuelle 2.0 RC schon stabil?
Gruß
oSu
Als größtes Hindernis könnte sich jedoch die stark französisch-sprachige community erweisen, weswegen google Sprachtools ein sehr hilfreiches Werkzeug bei der Kommunikation und bei der Dokumentationssuche sind... Das deutsch-sprachige Nagios-Portal (www.nagios-portal.de) hat auch ein aktives Centreon-Forum.
Niko
Zitat aus der Zabbix 1.4 Doku ( http://www.zabbix.com/downloads/ZABBIX%20Manual%20v1.4.pdf )
"It does NOT provide:
Discovery of network topology"
Und das war auch mein Wissensstand bei meiner letzten Testinstallation. Was stimmt denn nun? Auto-Discovery meint nicht eine automatische Erkennung der Topologie. Es ist lediglich ein Abscannen von IP Bereichen. Dabei werden z. B. prüfbare Ports festgehalten. Nicht aber verschiedene Netzsegmente sowie Router und Switche erkannt. Jedenfalls nicht so wie sie im Netz eingebunden sind.
Gruß,
demon
Nehmt doch einfach checkinstall, wenn schon kein "sauberes" RPM oder DEB gebaut wird, damit ist die Sache in der Paketverwaltung und wenn ein Update zu Inkompatiblitäten führt, kriegt man das in der Regel mit, bevor es zu spät ist.