9
Zukunft von SNMP Monitoring
Hallo zusammen,
Zum Hintergrund:
bei mir läuft demnächst die Wartung meiner PRTG-Lizenz aus (und will verlängert werden). Seit einer Weile habe ich auch mit den nicht kostenpflichtigem Icinga rumgespielt. Mein Fazit bisher - geht auch schön, aber die Einrichtung dauert deutlich länger, wenn man keinen kostenpflichtigen Support nimmt. Die Frage ist grundsätzlich: bei PRTG bleiben oder komplett auf Icinga umsatteln. Dabei ist die Frage des Betriebssystems nachrangig. Für Windows gibt es kein gescheites Syslog-Monitoring da habe ich sowieso Elasticstack laufen, so dass ein weiterer Linux-basierter Dienst hier nicht das Problem wäre.
Allerdings:
PRTG setzt fast ausschließlich auf SNMP (und - bei Windows WMI). Icinga verwendet lokal dagegen für etliche Monitoringvorgänge eigene Agenten. Gefühlt
habe ich bei SNMP auch immer wieder Probleme (Versionsdurcheinander 1-2-3 der Hersteller, Probleme bei der Installation der SNMP-Provider etc. ). Und die Implementationen von SNMP auch bei neuen Geräten wirken manchmal etwas halbherzig. Die Sicherheitsprobleme von SNMPv1/2 mal gar nicht beachtet.
Meine Frage ist, ob es so eine gute Idee ist, auf SNMP als Monitoringprotokoll zu setzen. Und ob die Hardware-Hersteller (bei uns releveant HPE, Cisco) auf SNMP setzten, oder das tendentiell durch andere Mechanismen ersetzen. SNMPv3 ist immerhin von 2002. Überspitzt gesagt, wenn das eh ausläuft, kann man doch gleich umsteigen.
Grüße
lcer
Zum Hintergrund:
bei mir läuft demnächst die Wartung meiner PRTG-Lizenz aus (und will verlängert werden). Seit einer Weile habe ich auch mit den nicht kostenpflichtigem Icinga rumgespielt. Mein Fazit bisher - geht auch schön, aber die Einrichtung dauert deutlich länger, wenn man keinen kostenpflichtigen Support nimmt. Die Frage ist grundsätzlich: bei PRTG bleiben oder komplett auf Icinga umsatteln. Dabei ist die Frage des Betriebssystems nachrangig. Für Windows gibt es kein gescheites Syslog-Monitoring da habe ich sowieso Elasticstack laufen, so dass ein weiterer Linux-basierter Dienst hier nicht das Problem wäre.
Allerdings:
PRTG setzt fast ausschließlich auf SNMP (und - bei Windows WMI). Icinga verwendet lokal dagegen für etliche Monitoringvorgänge eigene Agenten. Gefühlt
habe ich bei SNMP auch immer wieder Probleme (Versionsdurcheinander 1-2-3 der Hersteller, Probleme bei der Installation der SNMP-Provider etc. ). Und die Implementationen von SNMP auch bei neuen Geräten wirken manchmal etwas halbherzig. Die Sicherheitsprobleme von SNMPv1/2 mal gar nicht beachtet.Meine Frage ist, ob es so eine gute Idee ist, auf SNMP als Monitoringprotokoll zu setzen. Und ob die Hardware-Hersteller (bei uns releveant HPE, Cisco) auf SNMP setzten, oder das tendentiell durch andere Mechanismen ersetzen. SNMPv3 ist immerhin von 2002. Überspitzt gesagt, wenn das eh ausläuft, kann man doch gleich umsteigen.
Grüße
lcer
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 464791
Url: https://administrator.de/forum/zukunft-von-snmp-monitoring-464791.html
Ausgedruckt am: 04.04.2025 um 11:04 Uhr
9 Kommentare
Neuester Kommentar
Moin,
bei uns läuft schon seit langem Nagios als Monitoring. Zum Einen ist PRTG für uns finanziell nicht interessant und zum anderen kann ich mit Nagios alles "selber bauen", was ich monitoren will.
Von daher kann ich dich nur in Deiner Meinung unterstützen ganz auf Icinga zu setzen
Gruß
Looser
bei uns läuft schon seit langem Nagios als Monitoring. Zum Einen ist PRTG für uns finanziell nicht interessant und zum anderen kann ich mit Nagios alles "selber bauen", was ich monitoren will.
Von daher kann ich dich nur in Deiner Meinung unterstützen ganz auf Icinga zu setzen
Gruß
Looser
Morgen
ich kann dir auch Zabbix ans Herz legen. Ist super einfach aufzusetzen und einzurichten, unterstützt SNMP , JMX, IPMI und hat einen eigenen Agent für Linux und Windows.
EDIT:
Die eigentliche Frage nach SNMP: Ja, das macht sinn und ist oftmals auch die einzige Möglichkeit um was zu monitoren.
Im Grunde alles was Netzwerk ist, wird fast nur per SNMP abfragbar sein
ich kann dir auch Zabbix ans Herz legen. Ist super einfach aufzusetzen und einzurichten, unterstützt SNMP , JMX, IPMI und hat einen eigenen Agent für Linux und Windows.
EDIT:
Die eigentliche Frage nach SNMP: Ja, das macht sinn und ist oftmals auch die einzige Möglichkeit um was zu monitoren.
Im Grunde alles was Netzwerk ist, wird fast nur per SNMP abfragbar sein
Moin,
ich habe bei meinen alten AG Zabbix als Monitoring-Lösung genutzt und war hellauf begeistert.
Bei meinem jetzigen Arbeitgeber wird PTRG und SCOM genutzt. Ich habe hier ebenfalls Zabbix vor einigen Wochen ins Gespräch gebracht, da die Lizenzen für PTRG demnächst auslaufen. Unsere Netzwerker hat sich dann Zabbix mal genau angesehen. Er war als alter Linuxer von den Möglichkeiten schlichtweg begeistert.
Fazit: Inzwischen löst Zabbix PTRG bei uns ab!
Gruß
Dirk
ich habe bei meinen alten AG Zabbix als Monitoring-Lösung genutzt und war hellauf begeistert.
Bei meinem jetzigen Arbeitgeber wird PTRG und SCOM genutzt. Ich habe hier ebenfalls Zabbix vor einigen Wochen ins Gespräch gebracht, da die Lizenzen für PTRG demnächst auslaufen. Unsere Netzwerker hat sich dann Zabbix mal genau angesehen. Er war als alter Linuxer von den Möglichkeiten schlichtweg begeistert.
Fazit: Inzwischen löst Zabbix PTRG bei uns ab!
Gruß
Dirk
Wer oder was sind denn "SNMP Provider" ??
SNMP ist immer noch die Lingua franca des Monitoring und bei den Versionen herrscht auch Klarheit. v1 ist tot. v2 ist Standard aber eben offen und ungesichert. Wer in gesicherten Umgebungen arbeitet nimmt immer v3.
SNMP ist immer noch die Lingua franca des Monitoring und bei den Versionen herrscht auch Klarheit. v1 ist tot. v2 ist Standard aber eben offen und ungesichert. Wer in gesicherten Umgebungen arbeitet nimmt immer v3.
Hallo aqui,
Sorry, Wortfindungsstörungen. Meinte "SNMP-Subagent" und hatte das mit WMI-Provider wortmäßig vermurkselt.
Lingua franca klingt gut. Genau das wollte ich auch wissen.
Dann läuft das wohl auf weiter SNMP aber mit Icinga2 hinaus....
Grüße
lcer
Sorry, Wortfindungsstörungen. Meinte "SNMP-Subagent" und hatte das mit WMI-Provider wortmäßig vermurkselt.
Lingua franca klingt gut. Genau das wollte ich auch wissen.
Dann läuft das wohl auf weiter SNMP aber mit Icinga2 hinaus....
Grüße
lcer
Ich kann Zabbix auch nur empfehlen!
Monitore u.a. sämtliche Switche über SNMP.
Ansonsten kann man die Performance Counter von Windows bequem anzapfen.
Usw usw usw..
Monitore u.a. sämtliche Switche über SNMP.
Ansonsten kann man die Performance Counter von Windows bequem anzapfen.
Usw usw usw..
Moin,
Die Ereignisanzeigen können mit PRTG genauso überwacht/ausgewertet werden.
Gruß,
Dani
Für Windows gibt es kein gescheites Syslog-Monitoring da habe ich sowieso Elasticstack laufen, so dass ein weiterer
Linux-basierter Dienst hier nicht das Problem wäre.Die Ereignisanzeigen können mit PRTG genauso überwacht/ausgewertet werden.
Mein Fazit bisher - geht auch schön, aber die Einrichtung dauert deutlich länger, wenn man keinen kostenpflichtigen Support nimmt.
Die Zeit ist wie immer der entscheidene Faktor. Zudem spielen die eingesetzten Komponenten und Anzahl ebenfalls eine Rolle. Kommt es durch ein Firmware/Softwareupdate auf den Komponenten zu einem Fehlverhalten des Checks, bist du auf die Mithilfe der Entwickler angewiesen. D.h. in größeren, komplexen Umgebungen würde ich auch Icinga nicht ohne Support betreiben. Ob es sich unter dem Strich noch lohnt, kann ich nicht beurteilen.Die Sicherheitsprobleme von SNMPv1/2 mal gar nicht beachtet.
Solange du "nur" abfragen erlaubst, passiert erst einmal nichts.SNMPv3 ist immerhin von 2002. Überspitzt gesagt, wenn das eh ausläuft, kann man doch gleich umsteigen.
Das mag an der recht komplizierten Konfiguration liegen als auch der höheren Leistungsaufwand auf seitens Monitoringsystem im Vergleich zu SNMPv2. Kommen ein paar 100 oder 1000 Abfragen zu kommen, macht sich das definitiv bemerkbar.Gruß,
Dani
Hallo Dani,
War so gemeint, dass ich derzeit die syslogs meiner router, switches und Linux-Server auf einen Elasticsearch-Server zentral speichere und mit kibana visualisiere.
Der vorhandene Syslog-Empfänger-Sensor von PRTG bietet zwar Filtermöglichkeiten für Fehlerereignisse, ist aber bezüglich Darstellung und Durchsuchbarkeit des logs mäßig hilfreich.
Grüße
lcer
Zitat von @Dani:
Moin,
Moin,
Für Windows gibt es kein gescheites Syslog-Monitoring da habe ich sowieso Elasticstack laufen, so dass ein weiterer
Linux-basierter Dienst hier nicht das Problem wäre.
Die Ereignisanzeigen können mit PRTG genauso überwacht/ausgewertet werden.Linux-basierter Dienst hier nicht das Problem wäre.
War so gemeint, dass ich derzeit die syslogs meiner router, switches und Linux-Server auf einen Elasticsearch-Server zentral speichere und mit kibana visualisiere.
Der vorhandene Syslog-Empfänger-Sensor von PRTG bietet zwar Filtermöglichkeiten für Fehlerereignisse, ist aber bezüglich Darstellung und Durchsuchbarkeit des logs mäßig hilfreich.
Grüße
lcer
Hi
PRTG schaffst es nicht die Syslog eines Fileserver mit aktiviertem "Datei & Zugriffsaudit" zu valideren geschweige denn durchsuchbar zu machen.
Wir setzen alleine fürs Syslog einen Elasticsearch-Cluster mit 6 Servern (je 4 x 2.4Ghz und 24GB RAM) und der schafft es in einer akzeptablen Geschwindigkeit die Logs durchsuchbar zu machen, bei rund 50GB Zuwachs am Tag an Indizies.
Für das SNMP Monitoring setzen wir auch PRTG und SNMPv2 ein, wir haben es mal Testweise bei allen Switchen auf v3 umgestellt, aber wie bereits Dani schrieb, kannst dann "ohne Ende Cores" nachstecken damit das noch halbwegs performant läuft. Einrichtung und Verwaltungstechnisch ist PRTG schon weit vorne, wir überwachen damit z.T. die Grafikkarten der Workstation und auch die Möglichkeiten bei Fehlern individuelle Skripte laufen zu lassen (z.B. Dienst neustart wenn CPU Load für >5Min auf >80% verursacht durch den Dienst).
Wenn du bei dem Großteil der Endgeräte auf SNMPv3 verzichten möchtest, solltest du eine vollständiges Management Netzwerk haben und den allgemeinen Zugriff darauf reglementieren, wir haben eine pfSense zwischen "Produktivnetz" und dem Management Netzwerk, womit wir dann steuern wer alles ins Netz darf und wer nicht.
Ich würde mir die Migration "weg" von PRTG gut überlegen, das ist ein nicht zu verachtender "Rattenschwanz" der da folgt und Support musst ja nicht zwingend haben, die neuen "fertigen" Sensoren kannst im Regelfall auch nachbauen, dafür braucht man nicht zwingend eine Wartung.
Gruß
@clSchak
PRTG schaffst es nicht die Syslog eines Fileserver mit aktiviertem "Datei & Zugriffsaudit" zu valideren geschweige denn durchsuchbar zu machen.
Wir setzen alleine fürs Syslog einen Elasticsearch-Cluster mit 6 Servern (je 4 x 2.4Ghz und 24GB RAM) und der schafft es in einer akzeptablen Geschwindigkeit die Logs durchsuchbar zu machen, bei rund 50GB Zuwachs am Tag an Indizies.
Für das SNMP Monitoring setzen wir auch PRTG und SNMPv2 ein, wir haben es mal Testweise bei allen Switchen auf v3 umgestellt, aber wie bereits Dani schrieb, kannst dann "ohne Ende Cores" nachstecken damit das noch halbwegs performant läuft. Einrichtung und Verwaltungstechnisch ist PRTG schon weit vorne, wir überwachen damit z.T. die Grafikkarten der Workstation und auch die Möglichkeiten bei Fehlern individuelle Skripte laufen zu lassen (z.B. Dienst neustart wenn CPU Load für >5Min auf >80% verursacht durch den Dienst).
Wenn du bei dem Großteil der Endgeräte auf SNMPv3 verzichten möchtest, solltest du eine vollständiges Management Netzwerk haben und den allgemeinen Zugriff darauf reglementieren, wir haben eine pfSense zwischen "Produktivnetz" und dem Management Netzwerk, womit wir dann steuern wer alles ins Netz darf und wer nicht.
Ich würde mir die Migration "weg" von PRTG gut überlegen, das ist ein nicht zu verachtender "Rattenschwanz" der da folgt und Support musst ja nicht zwingend haben, die neuen "fertigen" Sensoren kannst im Regelfall auch nachbauen, dafür braucht man nicht zwingend eine Wartung
.Gruß
@clSchak
1
