PRTG: Wieviele Sensoren brauche ich?
Eine der ersten Fragen bei den Überlegungen zum Thema Netzwerk-Überwachung mit PRTG ist sicherlich die Frage nach den Sensoren. Letztlich bestimmt die Anzahl an Sensoren den Preis für die Software.
PRTG ist derzeit als Freeware mit 100 Sensoren komplett kostenlos. Und wie wir noch sehen werden, ist dies eine ganze Menge und für ein typisches Audio- bzw. Dante-Netzwerke in einem Theater oder ähnlicher Festinstallation mehr als genug.
Was ist ein Sensor?
Die einfachste Art, sich einen Sensor vorzustellen, ist ein einzelner Wert bzw. Parameter an einem Gerät. Du willst wissen, wie warm dein Switch ist? Dafür brauchst du einen Sensor. Du willst die Datenrate eines Uplink-Ports protokollieren lassen? Dazu brauchst du einen weiteren Sensor.
Je mehr Parameter du abfragen willst, desto mehr Sensoren musst du anlegen. Die Anzahl der Geräte ist hierbei nebensächlich. Denn wenn du an 10 Geräten die Temperatur überwachst, oder an einem einzigen Gerät 10 verschiedene Parameter (beispielsweise Temperatur, Traffic von 8 Ports, IGMP-Snooping an/aus), dann sind das in beiden Fällen 10 Sensoren. Das Anlegen von Geräten dient also eher der Hierarchie und der Bekanntgabe der IP-Adresse, über die ein Sensor seinen Wert abfragen kann.
Die Summe an Sensoren insgesamt bestimmt sich also aus der Anzahl der Geräte multipliziert mit den Sensoren pro Gerät.
Ein paar Beispiele hatte ich im letzten Blog-Artikel über PRTG bereits gezeigt. Hier nochmal eine Geräte-Liste aus einem Theater mit annähernd 100 Sensoren, das bislang noch mit der PRTG Free-Version auskommt:
Jeder der derzeit 12 Netgear Switche wird in seinen Grund-Einstellungen mit etwa je 5 Sensoren überwacht. Dies sind also etwa 60 Sensoren.
Hinzu kommen noch Traffic-Ports für wichtige Geräte wie das Mischpult sowie die DSP, verschiedene Shure Mikrofon-Empfänger, Verstärker für die Lautsprecher etc. Mit 100 Sensoren lässt sich zwar nicht jeder Port an allen Switchen überwachen, aber durchaus die wichtigsten Geräte.
Welche Arten von Sensoren gibt es?
Der Umfang an verschiedenartigen Sensoren von PRTG ist immens. Um ehrlich zu sein ist er so groß, dass ich bislang nur einen Bruchteil davon überhaupt eingesetzt habe.
Wir werden uns überwiegend mit Ping und SNMP-Sensoren befassen bei der Überwachung von Netzwerken bzw. Switchen. Nichtdestotrotz möchte ich natürlich ein paar Stichworte erwähnen, die dich vielleicht auf Ideen bringen - wenn du solche Protokolle bzw. Geräte in deinem Netzwerk verwendest:
Ping
SNMP
SMTP/POP3/IMAP
HTTP/FTP
MySQL
NetFlow/sFlow
Radius
RDP (Remote Desktop)
SNTP
WMI
SNMP-Sensoren
SNMP (Simple Network Monitoring Protocol) ist ein sehr verbreitetes Protokoll. Die meisten Geräte, die eine Netzwerk-Schnittstelle bieten, lassen sich mehr oder weniger über SNMP abfragen. Der Funktionsumfang unterscheidet sich teilweise erheblich. Während einige Geräte sich nahezu vollständig über SNMP nicht nur abfragen sondern auch steuern lassen, bieten andere Geräte nur die allerwichtigsten Funktionen. Für andere Funktionen muss man entsprechend die Geräte-eigene Webseite oder Einstellmöglichkeiten direkt am Gerät selbst nutzen.
Einen Überblick über den SNMP-Funktionsumfang von gängigen Switchen bzw. den Unterschied zwischen verschiedenen Herstellern (Cisco, HP, Netgear, Luminex) kannst du in diesem Blog-Artikel nachlesen.
Datenverkehr
Dieser Sensor überwacht den Traffic für einen Port an einem Switch. Beim Anlegen zeigt PRTG alle verfügbaren Ports des Switches an. Er ist somit leicht anzulegen ohne große Kenntnisse.
Es lässt sich zum einen angeben, ob der Sensor eine Fehlermeldung produzieren soll, wenn er down ist, d.h. wenn das angeschlossene Gerät ausgeschaltet ist. Zum anderen lassen sich Schwellwerte einstellen, die eine Warnung oder eine Fehlermeldung ausgeben lassen, wenn der Traffic (die Datenrate) einen gewissen Wert ober- oder unterschreitet.
In der Regel wird man zumindest die Uplink-Ports aller Switche überwachen. Denn die beste Redundanz über zusätzliche LWL-Verbindungen bringt nichts, wenn man nicht merkt, dass irgendwo eine Verbindung ausgefallen ist.
Benutzerdefiniert (1fach)
Alle anderen Parameter werden mittels OID (Object Identifier) abgefragt. Diesen Wert muss man manuell in PRTG für jeden Sensor eintragen. Es ist somit etwas Recherche notwendig, um die OID beispielsweise für die Temperatur an einem Switch ausfindig zu machen.
Grundsätzlich kann PRTG alles von einem Gerät abfragen, was vom Hersteller mittels OID abrufbar ist.
Da die meisten Parameter numerisch ausgegeben werden, muss man sich neben der OID auch mit einer Übersetzungstabelle befassen. Diese könnte beispielsweise lauten: 1=enable, 2=disable. Ohne die genauen Kenntnisse der Werte nützt die beste Überwachung natürlich nichts. Viele Hersteller geben deshalb sogenannte MIB-Dateien aus, die nicht nur die OIDs auslisten, sondern auch gleich zu jedem Parameter die Bedeutung mitliefern.
Benutzerdefiniert Erweitert (10fach)
Da es nicht viel Ressourcen braucht, um einmal pro Minute einen Wert abzufragen und zu speichern, hat PRTG noch einen erweiterten SNMP-Sensor hinzugefügt. Er kann bis zu 10 OIDs abfragen. Der große Vorteil ist, dass er trotzdem nur als ein einziger Sensor im Sinne der Paketgrenzen zählt (100 Sensoren bei der Free-Version). Es macht also durchaus Sinn, den 10fach-Sensor einzusetzen, wann immer es möglich ist.
In beiden Fällen werden OIDs von einem Gerät abgefragt und überwacht. Und in beiden Fällen sind nur numerische Werte möglich. Technisch ergibt sich somit erstmal keine Hürde zum Einsatz des erweiterten Sensors.
Die Frage nach 1fach oder 10fach ist eher eine organisatorische. Jeder Sensor kann den Zustand ok, Warnung, Fehler oder Pause annehmen. Je nach Parameter ist es einfach praktischer, wenn man nicht alles in einen Sensor packt, sondern Gruppierungen vornimmt. Temperatur-Sensoren nutze ich meist einzeln und nicht mit anderen Parametern vermischt. Denn bei überhöhter Temperatur müssen in der Regel andere Kollegen bzw. Abteilungen tätig werden als bei einer fehlerhaften IGMP-Einstellung.
Über Sensoren lassen sich Benachrichtigungen senden. Und hierzu lassen sich unterschiedliche User bzw. User-Gruppen anlegen, die nur bei bestimmten Sensor-Fehlern benachrichtigt werden. Im Rahmen einer Benachrichtigung wird außerdem der Sensor genannt, der den Fehler ausgelöst hat. Es macht mitunter einen großen Unterschied, ob der Sensor nur “Switch 17” heißt (und alle 10 Parameter umfasst, die überhaupt abgefragt werden), oder ob der Sensor “Switch 17 - Spanning Tree” meldet und direkt der passende Kollege informiert wird.
Spätestens wenn man eine Map anlegt und die Werte der Sensoren darstellen möchte, kommt der 10fach-Sensor an seine Grenze. Es lässt sich nur ein einziger aus den 10 OIDs als Haupt-Kanal eines Sensors bestimmen und auf einer Map anzeigen.
Wann immer also pro Port bzw. pro Uplink Informationen in einer Map angezeigt werden sollen, müssen diese einzeln als Sensor angelegt werden bzw. nur mit solchen Parametern kombiniert werden, die nicht angezeigt werden sollen.
Gut nutzbar ist der 10fach Sensor allerdings für gewisse Grundparameter, die sich eigentlich nie ändern, aber die einfach stimmen müssen. Beispielsweise die Grundeinstellungen zu EEE, SmartPort oder IGMP-Snooping müssen einfach nur bei allen Switchen identisch sein. Es ist nicht unbedingt notwendig, die Details auf einer Map anzuzeigen. Es reicht, wenn eine Fehlermeldung erscheint, sollte sich irgendeiner der 10 Parameter eines Tages aus Versehen ändern.
Zeichenfolge / String
Wann immer ein Geräte zu einer OID die Daten als String (also nicht als numerischen Wert) liefert, kommt man um den Zeichenfolge-Sensor nicht herum. Diesen gibt es leider nur als einfachen, nicht als 10fachen Sensor.
Der Vorteil dieses Sensors ist, dass Text in lesbarer Form angezeigt wird. Man kann also beispielsweise den Switch-Namen, die Firmware-Version oder die MAC-Adresse nicht nur auslesen, sondern auch überwachen und bei Abweichungen vom gewohnten Zustand eine Warnung abschicken.
Beispiel-Rechnung
PRTG ist grundsätzlich natürlich ein sehr universelles Tool, welches alle nur erdenklichen Geräte und Parameter überwachen kann. Entsprechend meines üblichen Tätigkeitsfeldes beschränke ich mich bei der Beispiel-Kalkulation auf ein Audio-Netzwerk eines mittelgroßen Theaters, d.h. in erster Linie um IT Switche und die daran angeschlossenen (Audio-)Geräte.
Um deinen ungefähren Bedarf an Sensoren hochzurechnen, würde ich zwei Gruppen unterscheiden: zum einen diejenigen Parameter, die auf allen Switchen gleichermaßen überwacht werden sollen. Und zum anderen Parameter bzw. Ports, die nur auf einzelnen Switchen relevant sind.
Globale Switch-Parameter
Die Anzahl an Parametern und somit die Anzahl der benötigten Sensoren pro Switch schwankt natürlich in Abhängigkeit vom Grund-Setup. Je mehr VLANs, desto mehr Parameter sind relevant. Und falls MSTP verwendet wird (Multiple Spanning Tree) sind nochmal Parameter relevant pro angelegter Instanz.
Die folgende Tabelle ist somit nur als Idee für deine eigene Kalkulation heranzuziehen.
| Numerisch 1x | Numerisch 10x | String | Traffic | |
| Information | ||||
| Switch Name | evtl. | |||
| Switch Typ | evtl. | |||
| Switch Firmware | evtl. | |||
| Switch MAC Adresse | evtl. | |||
| Basics | ||||
| EEE An/Aus | 1 | |||
| SmartPort / AutoTrunk An/Aus | ||||
| QoS Global Mode | ||||
| QoS Global An/Aus | ||||
| QoS Basic Trust | ||||
| Multicast Enable | ||||
| IGMP Snooping Global An/Aus | ||||
| IGMP Querier Global An/Aus | ||||
| Ports | ||||
| Traffic Uplink-Port | 1 | |||
| Mode (Trunk/Access), up to 10 Ports | 1 | |||
| PVID (Access Untagged VLAN), up to 10 Ports | 1 | |||
| Temperatur | ||||
| Temperatur | 1 | |||
| Spanning Tree | ||||
| STP An/Aus | 1 | |||
| Modus (RSTP/MSTP) | ||||
| Priority (3 Instances) | ||||
| IGMP Snooping | ||||
| IGMP An/Aus pro VLAN (3 VLANs) | 1 | |||
| IGMP Querier An/Aus pro VLAN (3 VLANs) | ||||
| IGMP Querier Election An/Aus pro VLAN (3 VLANs) | ||||
| Sensoren pro Switch | 7 | |||
Port- bzw. Geräte-Überwachung
Neben den grundsätzlichen Parametern, die alle Switche betreffen, sind anschließend noch die individuellen Parameter - sprich die Anzahl der zu überwachenden Ports zu ermitteln. Hier gilt es natürlich einen Kompromiss zu finden. Nicht jeder Port ist gleich wichtig für den Ablauf, und entsprechend muss nicht zwangsläufig jeder Port und jedes Gerät überwacht werden.
Eine Tabelle könnte letztlich wie folgt aussehen:
| Numerisch 1x | Numerisch 10x | String | Traffic | |
| Mischpulte / DSPs | ||||
| Dante Primary | 2 | |||
| Dante Secondary | 2 | |||
| Steuerung | 2 | |||
| Funkmikrofon Empfänger | ||||
| Dante Primary | 6 | |||
| Dante Secondary | 6 | |||
| Steuerung | evtl. | |||
| Verstärker / Lautsprecher | ||||
| Dante Primary | 4 | |||
| Dante Secondary | 4 | |||
| Steuerung | evtl. | |||
| PCs / NAS | ||||
| Dante Primary | 0 | |||
| Dante Secondary | 0 | |||
| Steuerung | 3 | |||
| Summe an Ports | 29 | |||
Summe an Sensoren
Die Summe an benötigten Sensoren ergibt sich nun aus der Anzahl an Switchen multipliziert mit der Anzahl an Sensoren pro Switch aus der ersten Tabelle. Beispielsweise 8 Switche x 7 Sensoren = 56 Sensoren für die Grund-Parameter.
Hinzu kommt die Summe an individuellen Sensoren aus der zweiten Tabelle, also beispielsweise 29. 56 + 29 ergibt 85 Sensoren, die für unsere Beispiel-Kalkulation anzulegen sind. Die 100 Sensoren, die PRTG als Freeware liefert, wären hier also ausreichend.
| Anzahl Switche | Sensoren pro Switch | Ports (Traffic-Sensoren) | Summe | |
| Allgemeine Parameter auf allen Switchen | 8 | 7 | 56 | |
| Zu überwachende Ports / Geräte | 29 | 29 | ||
| Summe an Sensoren | 85 | |||
Ein Netzwerk mit bis zu 10 Switchen lässt sich in der Regel recht gut mit mit der Freeversion überwachen. Sobald es mehr Switche werden bzw. wenn mehr einzelne Geräte überwacht werden sollen, kommt man irgendwann über die Grenze von 100 hinaus. PRTG lässt sich dann in der ersten Stufe mit 500 Sensoren lizensieren für rund 1899$. Dies dürfte selbst für größere Netzwerke, d.h. beispielsweise ein Theater mit mehreren Spielstätten bzw. Bühnen etc. genügend Reserven lassen für wirklich jeden erdenklichen Parameter bzw. Port.
Näheres zu den PRTG-Paketen findest du beim Hersteller (Paessler).
Ich hoffe, ich konnte dir anhand der Beispiel-Tabellen einen ungefähren Einblick geben, wie sich die Anzahl der erforderlichen Sensoren für dein Netzwerk ermitteln lassen. Viel Spaß bei der eigenen Kalkulation!
Weitere Artikel zum Thema Netzwerk, Dante und PRTG:
PRTG: Welche Switche sprechen SNMP?
PRTG Netzwerk-Überwachung: Vorteile und Beispiele
Dante: Typische Netzwerk-Topologien