Monitoring mit SNMP: Kein Ende in Sicht

Im Blogpost „Netzwerk-Monitoring mit SNMP: Stories from hell“ haben wir einige Probleme beim SNMP-Monitoring vorgestellt, die häufig das Resultat einer schlechten Implementierung des Protokolls durch die Hersteller sind. Darüber hinaus haben wir eine ausführliche Anleitung für das Debugging bei SNMP-Problemen gegeben. In diesem Post wollen wir nun einen Blick in die Glaskugel werfen: Schließlich ist SNMP als De-facto-Standard für das Monitoring von Netzwerkkomponenten bereits seit über 30 Jahren im Einsatz – mit all seinen Vor- und Nachteilen.

Obwohl SNMP aus verschiedenen Gründen als nicht-performant und unsicher gilt und auch beim Thema Skalierbarkeit an seine Grenzen stößt, hat es in der ganzen Zeit keinen erfolgreichen Versuch gegeben, das Protokoll als solches abzulösen. Mit SNMP v2c und v3 gibt es lediglich Erweiterungen. Zwar bieten verschiedene Hersteller proprietäre Schnittstellen für den Fernzugriff auf ihre Netzwerkgeräte an, einen einheitlichen Ansatz, wie es ihn seit 2015 mit Redfish im Server-Monitoring gibt, fehlt bei der Netzwerküberwachung jedoch noch.

Redfish ist eine Spezifikation zur Fernwartung von Server-Systemen über eine REST-API, die über kurz oder lang das Intelligent Platform Management Interface (IPMI)-Protokoll ersetzten soll. Es bietet zudem eine standardisierte Programmierschnittstelle für die Server-Fernwartung, liefert eine schemabasierte Ausgabe, die auch für den Menschen lesbar ist, und lässt sich zudem für Client-Anwendungen als auch für Browser-basierte GUIs verwenden. Die Übertragung der im JSON-Format vorliegenden Daten erfolgt mittels HTTPS.

Dass es bisher noch keinen breitangelegten Versuch gibt, auch für das Monitoring der Netzwerkkomponenten einen neuen einheitlichen Standard einzuführen, ist verwunderlich. Schließlich erhalten auch beim Thema Netzwerk Trends wie Software Defined Networking (SDN) oderMaschine Learning (ML) immer mehr Einzug in die Strategien der Hersteller. Intent-based Networking (IBN) soll beispielsweise manuelle Routineaufgaben, etwa Konfigurationen, mittels KI (künstliche Intelligenz) automatisieren und Probleme im Netzwerk automatisch erkennen und beheben können. Zudem bieten die Hersteller eines solchen IBN-Ansatzes einen Echtzeiteinblick in die Netzwerkaktivitäten. Doch auch hier zeigt sich, dass jeder Hersteller seine eigene Definition von IBN verfolgt – eine „Monokultur“ in Unternehmensnetzwerken entspricht jedoch eher nicht der Regel.

Viele Hersteller bieten auch proprietäre Protokolle für ihre Netzwerkkomponenten an. Für die Einbindung einer solchen Schnittstelle ist jedoch Entwicklungsaufwand erforderlich – Checkmk bietet bereits zahlreiche solcher sogenannten Special Agents an.

Alternative lässt auf sich warten

Eine wirkliche Alternative zu SNMP lässt also noch auf sich warten. Dennoch ist davon auszugehen, dass es mittelfristig zu einer Ablösung kommen wird. Schon jetzt gelangt SNMP an seine Grenzen, wenn es in Richtung Echtzeit-Monitoring geht. Dies hat mit der Funktionsweise des Protokolls zu tun. Wie in früheren Teilen der Blogreihe bereits dargelegt, gibt es mit SNMP-Polling und SNMP-Traps zwei Spielarten beim Monitoring.

Beim Polling fragt die Monitoring-Instanz in einem bestimmten Zeitintervall den Status der Netzwerkkomponenten ab. Gibt es zwischen zwei Abfragen einen Zwischenfall auf dem Gerät, etwa eine kurzzeitige Statusänderung eines Interfaces, erfährt der Administrator davon nichts. Um in die Nähe von Echtzeit-Abfragen zu kommen, müsste der Administrator die Zeitintervalle zwischen den Polls über die gesamte Monitoring-Umgebung deutlich verkürzen und würde die Last auf den Netzwerkkomponenten somit spürbar erhöhen.

Bei SNMP-Traps hingegen übermitteln die Netzwerkgeräte eine Benachrichtigung an die Monitoring-Instanz, sollte ein Event auftreten. Vorteil ist, dass der Administrator keine regelmäßigen Abfragen initiieren muss und eine Benachrichtigung erhält, sollte ein Zwischenfall auftreten. Nachteil ist, dass SNMP-Traps die Daten als UDP-Paket verschicken und es keine Empfangsbestätigung gibt. Es lässt sich also nicht nachvollziehen, ob das Paket überhaupt angekommen ist. Auch kann es vorkommen, dass der Empfänger, also die Monitoring-Instanz, bei einem Ausfall einer zentralen Komponente mit Benachrichtigungen überflutet wird.

Eine Kombination aus Status- und eventbasiertem Monitoring ist daher zwar sinnvoll, löst aber nicht das Problem der fehlenden Skalierbarkeit beziehungsweise der blinden Flecken im Netzwerk, sollten durch Traps versendete UDP-Pakete verloren gehen. Mit Streaming Telemetry gibt es beispielsweise einen neuen Ansatz im Netzwerk-Monitoring, der bei vielen Unternehmen mit großen Infrastrukturen Interesse hervorruft und auch unter den Netzwerkherstellern eine wachsende Unterstützung findet. So arbeiten bereits Arista, Cisco, Juniper Networks oder Nokia etc. mit Streaming Telemetry und betreiben mit Pipeline (Cisco), OpenNTI (Juniper) und GoArista (Arista) bereits Open-Source-Projekte zu der Technologie.

Streaming Telemetry

Im Gegensatz zum SNMP-Monitoring streamen die Netzwerkkomponenten, etwa ein Router oder ein Switch, kontinuierlich Daten an die Monitoring-Instanz, wobei sie ein Push-Modell nutzen. Es ist außerdem möglich, dass Betreiber und Applikationen spezifische Datenelemente abonnieren können. Der Administrator kann festlegen, welche Informationen er in welcher Frequenz benötigt und wohin das Netzwerkgerät das Datenpaket übermitteln soll. Auf diese Weise soll Streaming Telemetry in Echtzeit Zugang zu Daten liefern können, die zudem noch für ML- oder Analyse-Zwecke entsprechend aufbereitet sind. Dadurch kann die Technologie helfen, Themen wie Automatisierung, Troubleshooting oder auch Traffic-Optimierung in großen Netzwerkumgebungen voranzutreiben.

Zu beachten ist allerdings, dass Streaming Telemetry noch nicht standardisiert ist. Es gibt verschiedene Möglichkeiten und Variablen, die jeder Hersteller derzeit noch anders interpretiert. So stehen eine Vielzahl an Transportoptionen zur Verfügung, etwa TCP, UDP oder gRPC. Auch bei den vorherrschenden Dateiformaten gibt es mehrere Optionen.

Es bleibt also noch abzuwarten, ob es zu einer Standardisierung kommt oder welcher Anwendungsfall sich möglicherweise durchsetzen wird. Auf jeden Fall hat es den Anschein, dass Streaming Telemetry eine Option für große Netzwerkumgebungen wird. Je nachdem wie sich die Technologie weiterentwickelt und an Relevanz gewinnt, setzen wir uns auch mit solchen Themen auseinander und überprüfen eine mögliche Integration in Checkmk.

Unabhängig davon ist also davon auszugehen, dass auch weiterhin kein Ende von SNMP in Sicht ist. Trotz seiner Unzulänglichkeiten hat sich in über 30 Jahren kein Nachfolger herauskristallisiert. Zwar gibt es mit Streaming Telemetry einen möglichen Konkurrenten. Jedoch ist es noch zu früh zu sagen, ob sich dieser im Laufe der Zeit zu einem ernsthaften Nachfolger oder „nur“ zu einer sinnvollen Ergänzung entwickeln wird. Unabhängig davon, ob es sich hierbei um Streaming Telemetry oder um irgendeine andere Technologie handelt: Bis diese so weit fortgeschritten ist, dass sie das Potenzial hat, SNMP vom Thron zu stoßen, wird noch viel Zeit ins Land gehen. Es ist also damit zu rechnen, dass SNMP auch weiterhin das tonangebende Protokoll beim Netzwerk-Monitoring bleibt – und falls es einen Thronfolger gibt, zumindest noch lange parallel zum Einsatz kommt.