Skip to the main content.

ScriptRunner Blog

So richtest du eine einfache Serverüberwachung über PowerShell ein

Inhaltsverzeichnis

Post Featured Image

Einblicke in deine Infrastruktur sind absolut unverzichtbar, wenn es darum geht, die Leistung zu optimieren und zu verhindern, dass Probleme auftauchen. Echtzeit- und regelmäßige -Überwachung sind leistungsstarke Praktiken. Natürlich gibt es zahlreiche Möglichkeiten, dies zu tun. Gleichermaßen gibt es eine Vielzahl von Tools.

Während die Qual der Wahl das anfängliche Problem zu sein scheint, ist die wahre Herausforderung die individuelle Anpassung. Jedes Team hat andere Vorlieben. Serverarchitekturen und -konfigurationen unterscheiden sich stark. Leider müssen selbst die besten Tools für einige Anwendungsfälle auf Annahmen zurückgreifen – im Guten wie im Schlechten. Solche starren Ansätze können sogar zu erhöhten Ausfallzeiten beitragen, die Leistung beeinträchtigen und die Sicherheit verringern.

 

Unternehmen, die Windows-basierte Server betreiben, haben eine hervorragende Option zur Verfügung: PowerShell. Die leistungsstarke Skriptsprache ist äußerst flexibel. Da PowerShell auf menschenfreundlicher Codierung basiert, ist der Einstieg relativ einfach. Was ist das Beste daran, deinen eigenen Code zu schreiben? Du kannst Lösungen um beliebige Parameter herum entwerfen, die du selbst auswählst. Das soll nicht heißen, dass PowerShell-Skripterstellung keine Lernkurve hat. Das Potenzial für erhebliche Kosteneinsparungen ist jedoch hoch. Außerdem bist du nicht von der Verfügbarkeit des Supports eines Drittanbieters abhängig, falls Probleme auftreten (was immer der Fall ist).

Die Einrichtung einer Überwachung hängt davon ab, dass man seine Prioritäten kennt – und die grundlegenden Mechanismen hinter der Überwachung. Wir werden zuerst auf diese eingehen.

 

Monitoring- und PowerShell-Grundlagen

Bevor du loslegst, musst du zuerst herausfinden, was du überwachen willst. So manches Unternehmen hat das Pferd von hinten aufgezäumt; die daraus resultierenden Überwachungslösungen haben sich als unzureichend erwiesen.

Mehrere Faktoren können dabei um deine Aufmerksamkeit konkurrieren:

  • Leistung
  • Prozessauslastung
  • Speicher- und CPU-Auslastung
  • Netzwerk- und Benutzeraktivität
  • Server-Reaktionszeiten
  • Laufflächenauslastung
  • Bandbreite und Durchsatz

Diese Liste ist nicht erschöpfend, sollte aber ein guter Ausgangspunkt sein. Es ist wichtig, einen Konsens über die Schwerpunkte zu erzielen – selbst bei der Erstellung einfacher Monitore. Nehmen wir an, wir wollen uns von schweren Metriken lösen. Telemetriedaten sind nützlich, könnten aber für deine Zwecke zu detailliert sein.

 

Halte die Dinge einfach!

Wir wissen zum Beispiel, dass ein Server grundsätzlich aktiv oder inaktiv sein kann. Die Durchführung dieser Statusprüfung ist grundlegend für die Aufrechterhaltung deines Ökosystems. Da Serveranfragen über das Internet gestellt werden, werden HTTP-Antworten von bestimmten Quellen erwartet. Eine Überprüfung ist in der Regel dann notwendig, wenn ein Port offline geht.

Du musst auch eine grundlegende Eskalationskette erstellen: Welche Probleme, mit welchem Schweregrad, werden wessen Aufmerksamkeit erregen? PowerShell-Skripte lösen eine vorher festgelegte Aktion aus, die zu einem gewünschten Ergebnis führt. Dies wird oft als Status bezeichnet. Wenn ein schlechter Status entdeckt wird – z. B. eine falsche Antwort – muss jemand benachrichtigt werden.

Dabei kann es sich um jemanden auf der IT-Seite, der DevOps-Seite oder sogar um technische Vorgesetzte handeln. Eine Person könnte ausreichen, um das Problem zu entschärfen. Mehrere Mitarbeiter müssen möglicherweise ein Feuer löschen. Promptes Alerting über PowerShell kann helfen, „Schluckaufe“ schneller zu beheben.

 

Schreib deine PowerShell-Monitore

Deine Monitore werden in einem PowerShell-Skript zusammengefasst – einer umfassenden Datei, die aus mehreren geschriebenen Funktionen besteht. Du definierst Aktionen, gute Status, schlechte Status und Ausgaben innerhalb dieser Funktionen.

Du gibst außerdem die gewünschte Auslösehäufigkeit an. PowerShell-Skripte werden standardmäßig nur einmal ausgeführt. Wir umgehen diesen kleinen Haken, indem wir eine Aufgabe erstellen, die ein Skript aufrufen kann, wann immer der Anwender es wünscht. Dies ist durch die Schleifenfunktionalität von PowerShell möglich. Die organisierte, variablenbasierte Syntax der Sprache gibt uns die Flexibilität, frei zu definieren.

Jede Script-Datei, die du für PowerShell erstellst, wird mit einer Quellcode-Dateiendung gespeichert. Diese erscheint in deinem System z. B. als


C:\ServerMonitors.psl
du kannst sie aber auch nach Belieben benennen.
 

Blöcke Erstellen

Als nächstes solltest du deine Ausdrücke kennen. Die Verwaltung von Diensten kann eine Vielzahl von Funktionen in die Gleichung einbringen. Wir möchten uns jedoch auf einige wichtige Cmdlets konzentrieren:

  • Get
  • Test

Jedes Cmdlet enthält auch einen Modifier, der den Kontext für die Anfrage bereitstellt. Dieser ist durch einen Bindestrich mit dem Cmdlet verbunden, z. B. Get-Service -ComputerName .

Wenn du die Funktionalität deines Servers testen möchtest, kannst du einen Befehl wie Test-HTTP verwenden. Diesen Cmdlets wird die Funktionsschreibweise vorangestellt, sodass die erste Zeile eines Cmdlets wie folgt aussehen kann:


function Test-HTTP {

Funktionen umfassen auch Parameter. Wenn du keine Parameter für deine Server definierst, können deine PowerShell-Skripte nicht zwischen verschiedenen Ausgaben unterscheiden. Diese allgemeinen Funktionen geben allgemeine Ergebnisse zurück. Durch das Definieren von Parametern (wie Computernamen, gute oder schlechte Rückmeldungen) wird sichergestellt, dass deine Monitoring-Ausgabe kontextbezogen informativ ist.

Wenn du eine positive Rückmeldung definieren willst, z. B. einen HTTP-Statuscode, musst du diesen als Ganzzahl ([int]) bezeichnen. Solche Codes können 200 (erfolgreich, OK-Antwort), 202 (akzeptiert, aber wartend) oder etwas anderes sein, das sich auf die Serverfunktionalität bezieht. Da Server letztlich auf API-Anfragen antworten, ist es sinnvoll, eine Überwachungsfunktion zu entwerfen, die korrekte Antworten bestätigt. Du musst auch Zeichenketten ([string]) einfügen, um wichtige Überwachungsobjekte oder Datentypen zu kennzeichnen.

Bild1-2-1

So könnte eine grundlegende HTTP-Antwort-Testfunktion aussehen.
Mit freundlicher Genehmigung von 
Adam the Automator. "What a basic HTTP response test function might look like." 

Du solltest auch Bedingungsanweisungen in deine PowerShell-Funktionen einbauen und validieren. Dadurch wird dein Server angewiesen, bestimmte Ausgaben zu produzieren – wenn der Status true oder false ist. PowerShell befolgt diese Anweisungen entsprechend und gibt ein aussagekräftiges Ergebnis an dich oder dein Team zurück.

 

Starte mit deinem PowerShell-Monitoring durch

Das Erstellen deiner Überwachungsfunktionen ist Schritt eins. Du musst jedoch auch einen Mechanismus zum Auslösen dieser Überwachungsskripte schreiben. Das aufrufende Skript aktiviert deine relevanten vorgefertigten Funktionen und definiert gleichzeitig alle zusätzlichen Aufgaben, die zur Ausführung anstehen. Dieses Namensschema folgt unserem bisherigen Überwachungsschema:


C:\CallServerMonitors.psl

Die Struktur ist hier extrem wichtig. Du wirst deine verschiedenen Monitore in Hash-Tabellen organisieren, die als kompakte, organisierte Datenstrukturen fungieren. Diese enthalten Schlüssel- und Wertepaare. Du kannst deine Servernamen und Monitornamen definieren. Dieses Aufrufskript kann auch Alerts basierend auf Backend-Ergebnissen auslösen. Auf diese Weise kannst du auch spezifische Regeln nach Wunsch anwenden.


 

Häufigkeiten und Schlussbetrachtungen

Deine externen Tasks aktivieren diese Kernskripte so oft, wie du es wünschst. Während es sinnvoll ist, einige Serverparameter häufiger zu überwachen, sind andere deutlich weniger unternehmenskritisch. Microsoft betrachtet diese Überwachungsskripte als idiomatisch, da sie stark von Cmdlets und Funktionen abhängig sind.

Das gleichzeitige Ausführen einer großen Anzahl von PowerShell-Überwachungsskripten kann Ressourcen kosten; da sie nicht direkt auf .NET zurückgreifen, nutzen sie die Pipeline. Es ist möglicherweise am besten, Skripte, die häufig ausgeführt werden müssen, und solche, die nicht kritisch sind, zu staffeln. Glücklicherweise wird die inhärent leichtgewichtige Natur deiner Funktionen dazu beitragen, diese Bedenken zu entschärfen.

Diese Beispiele sind nicht erschöpfend. Es gibt noch viele weitere Monitoring-Möglichkeiten – du kannst dich darauf verlassen, dass PowerShell dir den Rücken freihält, wenn es um die Überwachung von Servern geht.

 
Webinar: PRTG & ScriptRunner – Monitoring & Automation at its best

PRTG and ScriptRunner – Monitoring and Automation at its best

(English-only)

Erfahre, wie PRTG Network Monitor und ScriptRunner Hand in Hand arbeiten, um all deine Anforderungen an die Überwachung deiner IT-Infrastruktur zu erfüllen!

Schau dir hier das Webinar an >

           

Zusammenhängende Posts

3 min read

IT-Automation für maximale Effizienz nutzen

Bist du bereit für eine Transformation deines IT-Mangements? Unser brandneues Whitepaper, Maximizing IT Automation: The...

14 min read

Microsoft Teams – 3. Teil der Graph PowerShell Reihe

MVP Damien Scoles berichtet über seine Erfahrungen mit Microsoft Graph. In seinem dritten Artikel geht er näher auf...

15 min read

Exchange Online – 2. Teil der Graph PowerShell Reihe

Wie unterscheidet sich die Exchange Online-Administration mit dem Microsoft Graph PowerShell-Modul vom herkömmlichen...

Über den Autor: