Sonntag, 25. Februar 2018
Twitter Facebook Mister Wong Delicious stumbleupon digg Yahoo

Neueste Technologie für Administratoren

Systembetreuer im Windows-Umfeld brauchen Know-how über die neuesten Entwicklungen. Einsatzbeispiele und Tipps aus der Praxis führen zu mehr Effizienz im täglichen Betrieb. Wir bieten Skript-basierte Lösungen von Windows IT Pro exklusiv im deutschsprachigen Raum für unsere Abonnenten.

Fehler bei der Rechenzentrumsüberwachung umgehen

Leon Adato, Head Geek bei SolarWinds (Quelle: SolarWinds)

Es gibt eine Kombination aus Rechenzentrumsüberwachung und Warnung, die ich bisher in jedem einzelnen Unternehmen gesehen habe, mit dem ich gearbeitet habe – als Mitarbeiter, als Berater und sogar als Gast auf einem Rundgang durch die Betriebszentrale eines Rechenzentrums: „Hohe CPU-Auslastung“. Es gibt sie, weil IT-Experten mit einer neuen Überwachungslösung loslaufen und nach einer Möglichkeit suchen, das neue Spielzeug auszuprobieren. Und das kann ins Auge gehen.

Aber ich nehme an, dass Sie es gerne erfahren möchten, wenn die Anzahl der Aufträge, die auf eine CPU warten, größer ist als die Anzahl der CPUs im System und dabei die hohe CPU-Auslastung für längere Zeit anhält.

Idealerweise sollte eine Warnung (neben den jeweiligen ausgelösten Trigger) mitteilen, welche zum Zeitpunkt der Auslösung die wichtigsten laufenden Prozesse waren. Im Folgenden möchte ich auf einige konkrete Beispiele für schlechte Überwachungspraktiken eingehen und überlegen, wie sie verbessert werden können. Schließlich ist Monitoring im Grunde weder eine Technologie noch eine Reihe von Techniken oder gar die Implementierung eines bestimmten Anbieters.

Sie ist eine Wahl, die wir darüber treffen, wie und wo wir Daten aus unseren Umgebungen erfassen und wie wir diese Daten weiterverarbeiten, sobald wir über sie verfügen. Mit der richtigen Herangehensweise sind Überwachung und Warnungen wohlüberlegt, durchdacht und direkt handlungsrelevant und umsetzbar. Sie sind maßgeblich dafür, wie wir mit unserer Technologie interagieren. Mit der falschen Herangehensweise entsteht ein Hintergrundrauschen aus unwichtigen Informationen, die unseren Tagesablauf und – noch schlimmer – unsere Systeme unterbrechen.

Naturgemäß kann ich in einem Artikel nicht alle Detailinformationen unterbringen, die man vielleicht gebrauchen könnte. Daher möchte ich Ihnen an dieser Stelle gerne auch mein kostenloses, englischsprachiges E-Book zu Best Practices bei der Rechenzentrumsüberwachung ans Herz legen.

Die Überwachung ist eine Denk- und Herangehensweise.

Nichtsdestotrotz möchte ich nun ein paar schlechte Monitoring-Einstellungen vorstellen und erläutern, wie man sie anpassen und ihnen so mehr Bedeutung verleihen kann. Diese sind nach folgendem Schema aufgebaut:

  • Der Schuldige: Der Überwachungsauftrag oder die Warnmeldung, um die es geht.
  • Das Verbrechen: Warum das Ganze (meiner Meinung nach) falsch ist.
  • Die Maßregelung: Wie man es anpassen kann, um es nützlich zu gestalten.

CPU-Warnungen

Ich werde mit dem Punkt beginnen, den ich zu Beginn dieses Artikels genannt habe: CPU-Warnungen.

Der Schuldige: Warnmeldungen bei einer CPU-Auslastung über x Prozent.

Das Verbrechen: Eine hohe CPU-Auslastung alleine ist nur selten ein Zeichen für ein wirkliches Problem. In vielen Fällen ist eine hohe CPU-Auslastung sogar ein Beleg dafür, dass das System die richtige Größe für die Workload hat. Der Grundgedanke ist folgender: Wenn die CPU-Auslastung beständig hoch ist (aber nicht ständig bei 100 Prozent) und das System weiterhin mit der Nachfrage Schritt hält, nutzen Sie alle Hardwareressourcen effektiv.

Die Maßregelung: Der Schlüssel ist das Erfassen von drei unterschiedlichen Informationen:

  • Die CPU-Auslastung (ja, die brauchen Sie weiterhin) – CPU_UTIL
  • Die Anzahl der CPUs (oder Kerne) im System – CPU_COUNT
  • Die Anzahl der Aufträge, die darauf warten, verarbeitet zu werden – CPU_QUEUE

Anschließend sollte der Warnungsauslöser für folgenden Fall eingestellt werden: (CPU_QUEUE > CPU_COUNT) AND (CPU_UTIL > x%) für mehr als y Minuten. In dieser Situation wissen Sie, dass die CPU-Auslastung einen Spitzenwert erreicht hat und der Rechner Probleme hat, mit der Nachfrage Schritt zu halten. Dies ist ein klares Zeichen dafür, dass entweder ein Prozess aus dem Ruder gelaufen ist oder es Zeit wird, über ein Upgrade für Ihre Hardware nachzudenken. Bei Windows-Rechnern ist CPU_QUEUE ein Leistungsindikator (Perfmon Counter). Sie finden ihn in der Kategorie „System“ als „Prozessor-Warteschlangenlänge“ angegeben.

Auf Linux-Systemen heißt CPU_QUEUE hingegen loadAverage15MinInt und ist über die SNMP-OID 1.3.6.1.4.1.2021.10.1.5.3 abrufbar. Beachten Sie, dass es sich um eine Ganzzahl handelt, die Sie also durch 100 teilen müssen, damit sie mit dem CPU_COUNT übereinstimmt. Wenn Sie eine detailliertere Überwachung wünschen, gibt es einen Wert für fünf Minuten (1.3.6.1.4.1.2021.10.1.5.2) und sogar einen Wert für eine Minute (1.3.6.1.4.1.2021.10.1.5.1).

Mit diesem Beispiel im Kopf sollte es einfach sein, dasselbe Konzept auch auf Arbeitsspeicherwarnungen zu übertragen (schließen Sie die Auslastung von Auslagerungsdateien und Speicherseiten pro Sekunde in Ihren Auslöser ein).

Bandbreitenauslastung

Das nächste Beispiel stammt aus dem Netzwerkbereich: die Bandbreitenauslastung.

Der Schuldige: Warnungen, wenn die Bandbreite einen bestimmten Schwellenwert überschreitet, der unter 100 Prozent liegt.

Das Verbrechen: Genau wie bei der CPU erzählt Ihnen die Überwachung der Bandbreite alleine nichts darüber, wo eigentlich das Problem liegt und ob es überhaupt ein Problem gibt. Wer sich nicht mit dem Netzwerk auskennt, wird oft unnötig in Panik versetzt. Wenn beständig 97 Prozent der Bandbreite ausgelastet sind, ist das für sich genommen nur ein Zeichen dafür, dass Sie genau die richtige Menge an Bandbreite für Ihre Anforderungen erworben haben.

Die Maßregelung: Dieses Problem kann sehr einfach behoben werden: Sie müssen lediglich Antwortzeit hinzufügen. Wenn die Bandbreitenauslastung einen bestimmten Level überschreitet und Ihre Antwortzeit für dieselbe Schnittstelle hoch ist, besteht ein Engpass, gegen den Sie etwas unternehmen sollten.

Die zugrundeliegende Frage (nicht das Problem, sondern die Frage, die überhaupt erst dazu führt, dass Sie eine Situation als Problem identifizieren) können Sie auch von einer anderen Seite angehen: Nutzen Sie NetFlow, um anzuzeigen, wie die Bandbreite verwendet wird. Stellen Sie sich die folgenden zwei Situationen vor:

  • Die Bandbreite auf der Schnittstelle, die die Haupt-Anwendungsdatenbank versorgt, ist gleichbleibend zu 97 Prozent ausgelastet. Die Antwortzeit dieser Schnittstelle ist auf einem normalen Niveau. NetFlow zeigt an, dass der Großteil des Datenverkehrs an Port 1433 stattfindet (der Standard-MS-SQL-Port).
  • Die Bandbreite des Routers des Büros ist zu 60 Prozent ausgelastet. Die Antwortzeit dieser Schnittstelle ist höher als erwartet. NetFlow zeigt an, dass der Datenverkehr aus einer Mischung aus Netflix (50 Prozent der Nutzung), Nachrichtensendern (20 Prozent), sozialen Medien (20 Prozent) und Datenverkehr zum Hauptbüro besteht (10 Prozent).

Würden Sie nur die Bandbreite nutzen, würden Sie eine Warnung für das erste Szenario erstellen, aber nicht für das zweite. Mit den zwei Messwerten, die ich zuvor genannt habe (Bandbreite und Antwortzeit), lösen Sie zwar immer noch keine Warnung für das zweite Szenario aus, aber auch nicht für das erste. NetFlow ermöglicht Ihnen festzustellen, ob die Kombination aus einer langsamen Antwortzeit und der spezifischen Bandbreitennutzung Grund zur Sorge ist, selbst wenn die Bandbreitenauslastung einwandfrei ist.

Virtualisierung

Mangelhafte Überwachungspraktiken und eine schlechte Nutzung von Warnungen sind jedoch nicht auf „traditionelle“ physische Geräte begrenzt. Lassen Sie uns einen Blick in die Welt der Virtualisierung werfen.

Der Schuldige: Überwachen der CPU-Auslastung auf virtuellen Servern.

Das Verbrechen: Es hat zwar seine Vorteile, virtuelle Maschinen so zu überwachen, als wären sie physische Server, doch einer der größten Nachteile liegt bei der CPU. Wenn eine virtuelle Maschine annimmt, dass die CPU-Auslastung hoch ist, hat das nur sehr wenig oder überhaupt nichts damit zu tun, ob die physische Ressource ihre Kapazitätsgrenze erreicht hat oder nicht. Umgekehrt kann ein Problem auf Host-Ebene dazu führen, dass die Maschine mit suboptimaler Kapazität funktioniert (was die Datenverarbeitung betrifft), selbst wenn das Betriebssystem der virtuellen Maschine eine niedrige CPU-Auslastung angibt.

Die Maßregelung: Es gibt zwei Werte, die wir betrachten sollten, bevor wir uns um Überwachungsauftrag und Warnung kümmern.

Zunächst wäre da die CPU Ready Time (RDY-Prozentsatz). CPU Ready Time beschreibt den Zustand, in dem die virtuelle Maschine etwas zu tun hat (ein so genannter „ready to run“-Status), aber darauf warten muss, dass der Hypervisor diese Arbeit einer oder mehreren der physischen CPUs zuweist. Diese Situation tritt typischerweise auf, wenn ein physischer Host überzeichnet ist (zu viele virtuelle Maschinen) oder wenn sich eine größere virtuelle Maschine mit einer SMP-Anwendung (beispielsweise SQL Server) auf demselben Host wie mehrere kleinere virtuelle Maschinen befindet. Wichtig ist hierbei zu erwähnen, dass der entsprechende Wert in Microsoft Hyper-V-Umgebungen „Wartezeit pro Verteilung“ heißt.

Der zweite Wert ist Co-Stop (%CSTP). Co-Stop bezeichnet die Dauer, für die eine virtuelle SMP-Maschine betriebsbereit war, aber aufgrund von vCPU-Planungskonflikten (virtuelle CPU) Verzögerungen erlitt. Bei einer virtuellen Maschine mit mehreren vCPU bezeichnet dieser Messwert entweder

  • die zusätzliche Zeitdauer der Verfügbarkeit der ersten vCPU, bis weitere vCPU für den Auftrag bereit sind, der verarbeitet werden soll, oder
  • jegliche Zeit, in der die vCPU aufgrund von Planungsproblemen gestoppt ist.

In Bezug auf Microsoft Hyper-V-Umgebungen ist noch ein weiterer Punkt zu beachten: Der entsprechende Wert wird mithilfe eines Performance-Monitoring-Zählers (PerfMon-Zähler) namens „Prozessorübergreifende Interrupts/s“ erhalten. Auch wenn es so klingt, als wären CPU Ready und die Co-Stop-Messung ein und dasselbe, sollte man sich einen Hauptunterschied merken: Co-Stop ist besonders zum Messen von virtuellen SMP-Maschinen gedacht (bei einer virtuellen Maschine mit einer einzelnen CPU wäre der Wert Null), während CPU Ready für jede virtuelle Maschine im System anwendbar ist.

Wenn man all dies zusammenfügt, ergibt sich ein sinnvoller Warnungsschwellenwert mit CPU Ready > (10% * <vCPU count>) oder Co-Stop > 3% für einen längeren Zeitraum. Für Hyper-V-Systeme landen wir bei Wait Time > 40ms oder Inter-processor interrupts /sec > (20 * <number of vCPUs>) für einen längeren Zeitraum.

Datenbanken

Werfen wir zu guter Letzt einen Blick auf einen besonders häufig genutzten Überwachungsauftrag, den viele für ihre Datenbanken einrichten, um dann später festzustellen, dass er, sagen wir, etwas suboptimal ist.

Der Schuldige: Warnungen auf Grundlage einer Liste wie „Top 10 der Abfragen, sortiert nach CPU-Auslastung“.

Das Verbrechen: „Top 10 der Abfragen nach CPU“ ist so gut wie nutzlos. Sicherlich, es ist zu einem Branchenstandard geworden, jedoch werden damit nahezu keine aussagekräftigen und handlungsrelevanten Informationen ausgegeben. Wenn die Top-10-Abfragen nach CPU effizient Daten verarbeiten und gleichzeitig die zehn am häufigsten ausgeführten oder wichtigsten Abfragen sind, funktioniert alles auf dem Server genauso, wie es soll.

Die Maßregelung: Bei der Datenbankleistung liegt die Wahrheit in Sperren, Blockierungen und Wartevorgängen. Lassen Sie mich diese Faktoren kurz definieren:

  • Sperren liegen vor, wenn eine Sitzung eine Ressource sperrt, und andere Sitzungen versuchen, miteinander in Konflikt stehende Sperren für dieselbe Ressource zu erlangen. Die zweite Sitzung wartet mit einem der LCK_M-Wartezeittypen und je nach den Bedingungen können ernsthafte Leistungseinbußen auftreten.
  • Blockierungen treten auf, wenn eine separate Transaktion versucht, auf eine gesperrte Ressource zuzugreifen.
  • Wartevorgänge treten immer dann auf, wenn ein Thread oder eine Sitzung vor der Ausführung auf etwas warten muss. Möglicherweise wartet eine Ressource darauf, dass eine gesperrte Ressource wieder verfügbar wird, Daten in den Puffercache geladen werden oder andere Bedingungen erfüllt werden.

All das bedeutet: Wenn Sie den Fokus Ihrer Überwachungs- und Warnsysteme von „Top-Abfragen“ auf die Abfragen richten, die in einer bestimmten Zeitspanne die meiste Wartezeit haben, werden Sie mit einer sehr viel größeren Wahrscheinlichkeit Leistungsprobleme aufspüren und beheben.

Fazit

Wenn ich Ihnen Beispiele aus dem gesamten Spektrum der IT vorstelle, dann nicht, um so zu tun, als sei alles ganz furchtbar, sondern um aufzuzeigen, dass falsche Überwachungstools und falsche Denkweisen jeden Technologiebereich betreffen und beeinträchtigen können. Gleichzeitig können die richtigen Methoden auch jedem Bereich zugutekommen.

Leon Adato, Head Geek bei SolarWinds

 

Anmelden
Anmelden