PRTG mit Lync

PRTG bringt einige Funktionen mit, um Netzwerke auch bezüglich VoIP zu überwachen. Damit wird PRTG natürlich auch für dem Einsatz mit Lync interessant oder für eine Vorabanalyse. Ich möchte auf dieser Seite die Komponenten von PRTG auflisten, die für Lync interessant sind.

PRTG bietet eine ganze Menge von "Sensoren", angefangen von Möglichkeiten die Funktion von Servern zu überwachen (CPU, Disk, Netzwerk, beliebige Performancecounter und damit auch Lync). Interessanter sind die Sensoren für:

  • ICMP-Latenz
  • QoS-Metering
  • SNMP-Abfragen von Gateways

Einige der Daten kann man als "statistische Werte" regelmäßig erfassen und auslesen. Allerdings sind dies dann immer die "Prüfergebnisse" über einen gewissen Zeitraum und keine Permanentüberwachung oder sogar eine Verkehrssimulation.

PRTG mit Windows Performance Counter

PRTG kann mit Bordmitteln schon Windows Performance Counter auslesen. Sie müssen nur die richtigen Counter "finden", um entsprechende Werte zu überwachen. SCOM ist da natürlich weiter, da im Lync Management Pack schon sehr viele Counter samt Grenzwerte hinterlegt sind. Bei PRTG ist jeder Counter ein eigener Sensor, der gesondert zu lizenzieren ist. Schwerer wiegt meiner Meinung nach aber nicht der Kostenfaktor sondern die ungeschickte Darstellung mehrere Counter über eine Zeitachse. Speziell wenn man einen Lync Pool betreibt, dann wäre es durchaus interessant alle Server im Pool in einer Grafik zu haben. Aber das mit mit PRTG ganz einfach möglich, indem man sich einen eigenen PRTG:Custom Sensor schreibt. Hier am Beispiel eines Skripts, welches von allen Frontend Servern im Pool die Anzahl der registrierten SIP-Endpunkte ermittelt.

Schaut man sich das Bild an, dann sind zwei rote Stellen, die keine Daten anzeigen. Hier war einmal einmal auch das IP-Routing zum Pool unterbrochen, was man auch im Einbruch der SIP-Connections sieht und beim zweiten Mal das Skript nicht fehlerfrei. Im Mittelfeld sieht man aber gut, dass die Server nicht gleichmäßig belastet sind. So hat der blaue "lynfe12" deutlich mehr Connections als der gelbe "LyFE13". Das besserst sich erst im letzten viertel. Ursache war, dass die beiden "wenig" belasteten Server noch nicht überall im DNS bekannt und per Firewall erreichbar waren und daher die Clients sich nicht anmelden konnten.

PRTG Custom Sensor für Lync SIP Connections
prtg-lyncUser.1.0.ps1.txt

Auch wenn der Sensor "trivial" ist, so ist er sehr hilfreich um Probleme in einem Lync-Pool zu ermitteln. Normalerweise sollten die Anwender nämlich ziemlich "gleichverteilt" über die Server im Pool sein und größere unstimmigkeiten in der Anzahl der angemeldeten Benutzer eine Warnung darstellen.

Network Latency per ICMP (Ping)

Dies ist die einfachste Variante, bei der PRTG einfach einen "PING" auf eine Gegenstelle sendet und die Rückantworten einsammelt. So lässt sich die gesamte umlaufzeit müssen. Allerdings ist ICMP natürlich kein VoIP-Paket und QoS-Priorisierung wird es auch nicht geben. Aber die Messung ist einfach und ein erster (einfacher) Baustein. Als Gegenstelle reicht ein beliebiges IP-Gerät, welches ICMP unterstützt:

Windows 2008 Server antworten nur auf ICMP, wenn es freigeschaltet ist oder eine Rolle installiert wurde, welche ICMP nutzt, z.B. Dateidienste oder Domänencontroller. Sie können Aber auch immer selbst ICMP in der Windows Firewall frei schalten.

PRTG und QoS

PRTG enthält auch einen QoS Sensor, den ich auf der eigenen Seite beschreibe. für den Einsatz muss aber neben dem PRTG-Server mindestens eine weitere "RemoteProbe" installiert sein.. Nur so kann ein System an das andere System etwas senden. Dazu reicht aber sogar die Freeware-Version mit 10 Sensoren. Nur die Gesamtzahl der Sensoren zählt.

PRTG mit Gateway

Wenn sie z.B. ein Gateway zur klassischen Telefonwelt einsetzen, dann sind dort die Anzahl der Kanäle interessant. Die meisten Gateways erlauben einfache Abfragen per SNMP, die PRTG sehr einfach mit dem Standard SNMP-Sensor erfassen kann.

  • AC SNMP
  • weitere Links zu anderen Gateway folgen

Weitere Links