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".
- Key Health Indicators
http://technet.microsoft.com/de-de/library/dn593599.aspx - Key Health Indicators: The
Foundation für Maintaining
Healthy Lync Servers
http://www.microsoft.com/en-us/download/details.aspx?id=41697 - Grundlegendes zur
Warnungskorrelation
http://technet.microsoft.com/de-de/library/ee758053(v=exchg.140).aspx
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 |
|
Memory usage |
|
CPU |
|
|
|
Downtime |
|
|
|
Threads |
|
|
<keine> |
Sonstiges |
<keine> |
|
<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.
- PRTG Manual: Create Device
Template
http://www.paessler.com/manuals/prtg/create_device_template - How to delete device templates
http://kb.paessler.com/en/topic/16073-how-to-delete-device-templates
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 |
|
|
AD |
|
|
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.
|
|
Lync |
Auch Lync kennt einige interessante Counter, die eine schnelle Überwachung erlauben
Microsoft hat dazu eine passende Liste sogar veröffentlicht
|
|
IIS |
|
|
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 |
|
Exchange CAS |
|
Exchange DAG |
|
Lync: PoolBasis |
|
Lync: Konferenzen |
|
Lync: Telefonie |
|
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.
- Introducing the PRTG Network
Monitor API
http://www.paessler.com/blog/2008/08/19/prtg-7/introducing-the-prtg-network-monitor-api - Trigger a "Check Now" using
a Notification
http://www.paessler.com/knowledgebase/en/topic/12903-how-can-syslog-events-or-snmp-traps-trigger-check-now-on-a-specific-sensor
Weitere Links
- E2013:Heathcheck
- PRTG
- Measuring Processor utilization and Queuing Delays in
Windows application
http://blogs.msdn.com/b/ddperf/archive/2010/04/04/measuring-processor-utilization-and-queuing-delays-in-windows-applications.aspx - What is the most reliable indicator of CPU contention?
http://demandtech.pmhclients.com/index.php?pg=kb.page&id=38