PRTG KHI

Als Key Health Indikatoren bezeichnet Microsoft die Schlüsselkomponenten um einen stabilen Betrieb zu erkennen. Mit ein paar Skripten kann man in PRTG ähnliches umsetzen und die Qualität des Monitoring einfach verbessern. Diese Seite beschreibt die eingebauten "Sammelsensoren" und eine mögliche Grupperung eigener Sensoren.

Diese Sensoren sind alle noch in der Planung bzw. Optimierung und nicht "fertig".

Eingebaute Sensoren

Klassisch erstellen Sie in PRTG einen Sensor, der genau eine Funktion überwacht. Das ist ideal um z.B. einen numerischen Messwert zu erfassen und später auch in Grafiken schön darzustellen. Das können aber pro Server sehr schnell eine unübersichtliche Menge an Sensoren werden, unter der die Übersichtlichkeit leidet. Der Nutzen eines Sammelsensors können Sie aber schon an den vordefinierten Sensoren von PRTG gut erkennen. Hier gibt es drei Sensoren, die eine gewisse Menge an numerischen Werten zusammenfassen..

Probename Core Health Probe Health System Health

Memory

  • Commited Memory
  • Physical Memory
  • Virtual Memory
  • Pagefile usage

Memory usage

  • Available Memory
  • Available Memory %

CPU

  • CPU Load 
  • CPU Load 
  • CPU Load 

Downtime

  • Downtime
  • Downtime
  • Downtime

Threads

  • Handles
  • Threads
  • Handles
  • Threads

<keine>

Sonstiges

<keine>

  • WMI Delay
  • SNMP Delay
  • Lost Flow Pakets
  • Message Queue
  • Open Requests

<keine>

Dies sind also schon Beispiele für gruppierte Sensoren, die lizenztechnisch als "ein Sensor" gezählt werden.  Aber in dieser Zwickmühle steht jeder Hersteller eine Software. Es gibt immer Fälle wo ein Lizenzmodell (z.B. pro Sensor) gegenüber anderen Modellen (pro Host, pro Datenbankgröße, Pauschal etc.) Vorteile oder Nachteile hat. Ziel sollte immer die beste Lösung sein, denn eine Lizenzeinsparung ist nur ein einmaliger kurzsichtiger Aspekt. Daher sollten Sie die folgenden Sensorbeispiele nicht aus der Sicht sehen, möglichst umfangreich mit möglichst wenig Sensoren auszukommen um Lizenzkosten zu sparen.

PRTG Templates

Ehe Sie nun aber loslegen und mit einem Custom Sensor alle Werte eines Servers in einen Sensor pressen, sollten Sie das Konzept der "Templates" von PRTG können. Es ist ja nicht so, dass PRTG von Hause aus keine Unterstützung für die effektive Konfiguration von Serversensoren anhand von Templates hat. Wenn Sie ein Gerät addieren, können Sie nur nur PRTG "proben" lassen, sondern auch anhand von Templates schon vorgefertigte Sensoren anwenden.

Die Templates liefen per Default in C:\Program Files (x86)\PRTG Network Monitor\devicetemplates mit der Endung ODT, was aber kein OpenOffice ist. Es sind XML-Dateien mit der Konfiguration für dieses Template. Ein Template können Sie einfach erzeugen, indem Sie auf einem Gerät mit den gewünschten Sensoren als Quelle für ein neues Template nutzen.

Bei der Einrichtung per Template werden auf dem Gerät dann die hinterlegten Sensoren angelegt.

Das ist schon mal ein Startpunkt um ein neues Device basierend auf Basis einer Vorlage gleich mit einer Gruppe von Sensoren zu versehen. Ich erspare mir so die manuelle Anlage der einzelnen Sensoren und zudem vergesse ich keinen. Aber es sind natürlich noch immer sehr viele Sensoren, die dann z.B. für einen Exchange Server notwendig sind mit sehr vielen Werten. Wenn ich dann noch eigene Sensoren addiere, die alle z.B. per "Remote PowerShell" einige Exchange Commandlets aufrufen, dann leidet doch die Performance darunter. dann ist es doch wieder besser mit einem Sensor einmal die PowerShell zu starten und alle Daten zu sammeln und an PRTG zu übergeben. Wenn ich tatsächlich die Werde eines Sammelsensors getrennt aufzeigen will, kann ich das über die Sensor Fabric machen oder ich speichere Die vom ersten Sensor erhobenen Daten in einer Datei, die von den weiteren Sensoren ausgelesen wird. Siehe dazu auch PRTG:Sensorplanung. Das gilt um so mehr, wenn ein Sensor Daten erfasst, die mehrere Server betreffen.

Basis für Performance Sensoren pro Server

Meine Überlegung beruht darauf eine gewisse Funktionsfähigkeit eines Dienstes in einem Sensor zusammen zu fassen, damit nicht jeder Admin "seine" Sensoren individuell zusammen bauen muss. Das kann natürlich nicht die Perfektion eines SCOM Management Packs erreichen, der selbst ermittelt, welche Produkte installiert sind und automatisch die entsprechenden Tests und Regeln aktiviert. Und es gibt natürlich schon mal gar kein Eventlog-Management. Aber das ist auch gar nicht das Ziel von PRTG. für den "Durchschnitt" kann es ausreichen, eine "Baseline" für das jeweilige Produkt zu erreichen.

Die Tatsche, dass Sie die einzelnen Skripte hier noch nicht herunter laden können, liegt daran, dass ich diese in den nächsten Monaten mit meinen Kollegen noch optimieren muss. Nur weil ein Script in einer TestUmgebung läuft, ist das noch keine Garantie für einen Dauereinsatz in unterschiedlichen Umgebungen. Zudem möchte ich die Skripte dann natürlich auch mit etwas Dokumentation bereitstellen und Beispieldaten über mehrere Monate beisteuern. Bitte haben Sie noch Geduld. Wenn Sie den RSS-Feed abonnieren oder mit per Twitter/Facebook folgen, dann bekommen Sie Updates zeitnah mit.

Beim Entwurf von solchen Sensoren muss man immer den Fokus im Auge behalten. Ein Sensor soll die Funktionsfähigkeit eines Systems zuverlässig überprüfen und kein "Datensammler" für umfangreiche statistische Auswertungen sein. Wichtig ist eine minimal Belastung des Systems und eine schnelle Laufzeit.

Produkt Erfasste Werte Skript
Windows
  • CPU-Last, Prozesscount
    Hier interessiert vielleicht nicht nur die reine utilization, sondern auch Queue-Length und CPU Wait Time
  • Disk-Status
    Sicher ist die freie Kapazität ein Kriterium aber auch die IO-Last, Queues und die Disklatenzzeit nicht zu vergessen.
  • Speicherkennzahlen/Pagefile
    Freier Speicher gibt es unter Windows fast nicht, da der dem Cache zugeschlagen wird, Aber dennoch gibt es Werte die frühzeitig einen Engpass oder intensive umlagervorgänge (Paging) anzeigen
  • WindowsUpdate-Count / Last Patch Age / LastReboot
    Ein guter Indikator um zu sehen, wie aktuell der Server ist
  • Eventlog Error/Warning-Count
    PRTG hat kein ausgefeiltes Eventlog Management. Aber wer seine Server gut konfiguriert hat, sollte eine überschaubare Anzahl von Warnungen und Fehlern pro Zeiteinheit hat. Eine Zunahme ist aber kein guter Indikator
  • Dienststatus
    Ein Skript kann relativ einfach ermitteln, welche Dienste auf "Automatisch" stehen und vielleicht nicht gestartet sind

AD
  • DC/GC per LDAP erreichbar
    Eine einfache LDAP-Abfrage oder Suche und das Auswerten der Anzahl der Ergebnisse sind ein qualitativer Sensor, der besser ist als ein einfacher LDAP-TCP-Test
  • DNS-Einträge vorhanden und korrekt
    Auch die für einen DC relevanten DNS-Einträge können vom PRTG-Server überprüft werden. Wobei man hier schon wieder den Fokus auf das AD selbst und nicht den einzelnen Server legen könnte und dann mehrere DNS-Server befragt. Die Grenzen sind also fließend
  • Replikationsstatus,
  • Alter eines Replikationselements
    Ein einfacher Test zur Funktion des AD besteht darin, dass der DC z.B. in der Beschreibung seines Computerelements einen Zeitstempel ablegt und bei den anderen DCs diesen Stempel ausliest und so die Latenzzeit ermittelt.
  • AD-Eventlog Error Count
    Auch das Windows AD hat ein eignes Eventlog, welches bezüglich Warnungen und Fehler zumindest numerisch erfasst werden kann.

Exchange

Für Exchange gibt es natürlich eine ganze Menge von Countern, die pro Server interessant sind. Dabei muss man aber aufpassen nicht in die Statistik zu rutschen.

  • Mailboxrolle
    • Größe der Postfächer
    • Datenbank Transaktionprotokolle (ExDBLog)
    • Replikationsstatus, Mount-Status, Indexstatus
  • CAS-Rolle
  • Transport-Rolle
    • Übertragene Mails pro Zeit (ExTracking)
    • Länge der Warteschlangen und älteste Mail in Warteschlangen
  • Allgemein

Lync

Auch Lync kennt einige interessante Counter, die eine schnelle Überwachung erlauben 

  • SIP-Logons
  • Eventlog Errorcount
  • SIP-Messagerate
  • Zertifikate

Microsoft hat dazu eine passende Liste sogar veröffentlicht

IIS
  • Sessions
  • Request
  • IISlog Errors
  • IIS InvalidURLs
  • Zertifikate

Sonstige

Zu definieren

Die Erfassung pro Server ist in der Regel der einfache Ansatz, um auch beim späteren Betrieb FunktionsEinschränkungen schnell zu erkennen.

Basis für Health Sensoren pro Service

Aber genauso kann man sich Sensoren vorstellen, die nicht auf einen Server fokussiert sind, sondern die einen Dienst über mehrere Server übergreifend erfassen. Das kann sich z.B. auf ein Exchange CAS-Array, einen Lync-Pool, eine Exchange-DAG oder einen Cluster beziehen. Also "Geräte" die als solches gar nicht einem physikalischen Device zugeordnet sein müssen. Beispiele hierzu sind z.B.

Produkt erfasste Werte
Exchange Hub/Transport
  • Übertragene Mails pro Zeiteinheit
    ggfls. weiter aufgeschlüsselt nach Anzahl der Empfänger und Größenverteilung pro Mail
  • Erreichbarkeit Port 25
  • TLS Zertifikat
  • Mail Roundtrip Test
Exchange CAS
  • Aktive Clientverbindungen auf Exchange (z.B. Outlook, OWA, ActiveSync)
  • Test-MAPI-Connectivity
  • POP3/IMAP4 Test
Exchange DAG
  • Replikation: Aktualität/Latenz
  • Replikation: Bandbreite zwischen Servern
  • Logfile Platz
Lync: PoolBasis
  • Aktive Anmeldungen (SIP-Endpunkte pro Server auf allen Servern eines Pools)
  • Aktive Konferenzen
  • WebServices über LB
  • CMS Replikation
  • Datenbank Mirroring Status
Lync: Konferenzen
  • Aktiven Konferenzen auf allen Servern eines Pools
Lync: Telefonie
  • Testcalls über Gateways oder zu Federation Partner

Es gibt durchaus eine Menge von interessanten Werten, die erst im Zusammenhang über mehrere Server hinweg aufschlussreiche Aussagen zulassen. Allerdings muss man auch hier wieder abwägen, welche Datenerfassung noch zum Monitoring gehört und ab wann die Datenerhebung Richtung Datawarehouse geht, d.h. Betriebsdatenerfassung, Abrechnung etc.

Basis für Statistik und Reporting

Natürlich kann so ein Sensor auch numerische Werte überwachen und erfassen, die für statistische Ausgaben interessant sind, z.B. die Größen von Postfächern, das Alter von ActiveSync-Partnerschaften etc. Solche Werte sagen aber in der Regel nichts über die aktuelle Verfügbarkeit eines Dienstes aus. Solche werde müssen also nicht im Rahmen eines Sensors erfasst werden, der jede Minute ausgeführt wird, sondern können mit weniger "Genauigkeit" seltener ausgeführt werden.

Dazu kann natürlich PRTG auch genutzt werden und auf den folgenden Seiten habe ich auch ein paar Beispiele veröffentlicht.

  • ExMetric
    Sammelt verschiedene Metriken ein, z.B.

Vergessen Sie aber dabei nicht, dass diese Auswertungen "sehr lange" dauern und damit einen Einfluss auf die sonstigen lebenswichtigen Sensoren haben können.

Master triggert Slave

Es gibt verschiedene Abfragen und Checks, die sehr "teuer" sind, weil sie z.B. eine Exchange Remote PowerShell starten, eine Liste der Mailboxen generieren etc. Und mehrere Sensoren die gleichen temporären Daten benötigen um die gewünschten Ergebnisse zu liefern. Da ist es sinnvoller, die Daten nur einmal zu sammeln und als Zwischenspeicher abzulegen. Besonders "teuer" sind z.B. Anfragen, die wirklich in die Daten hinein gehen, z.B. Messagetracking, Postfachgrößen (für Quotas), ActiveSync-Statistiken, Empfängerlisten (in größeren Umgebungen) etc. Wenn diese Daten in mehreren Sensoren verwendet werden sollen, dann könnten diese z.B. per geplantem Task (Was auch ein Sensor sein kann) generiert und abgelegt werden, so dass die anderen Sensoren darauf zugreifen können.

Weitere Links