Zielführende Netzwerk- und Systemüberwachung beginnt im Kopf Auf was es beim Monitoring ankommt

Eine effektive Kombination aus Überwachung und Alarmierung versorgt IT-Experten bei der Netzwerkverwaltung optimal mit Informationen. Doch ein gutes Monitoring stellt sich nicht zwangsläufig ein, nur weil neueste Tools und Techniken zum Einsatz kommen. Selbst die besten Produkte, Methoden und Verfahren nützen nichts, wenn die Denk- und Herangehensweise nicht passt.

Jeder Aspekt der Netzwerk-Überwachung lässt sich auf eine Entscheidung zurückführen. Es ist die Entscheidung über die Frage, wann, wie und wo Daten aus dem Umgebungen gesammelt werden sollen. Und sobald diese Daten vorhanden sind, müssen wir entscheiden, was wir mit ihnen anfangen wollen.

Mit der richtigen Herangehensweise kann Monitoring für einen positiven Wandel im Rechenzentrum sorgen. Umgekehrt bedeutet dies jedoch auch, dass eine Überwachungslösung, die auf einer falschen Herangehensweise beruht, sogar Systemunterbrechungen zur Folge haben kann.

CPU-Warnungen

Was ist an einer Warnung falsch, die ausgelöst wird, sobald die CPU-Auslastung auf über 90 Prozent steigt? Einfach alles. Eine hohe CPU-Auslastung ist vermutlich das Ereignis, für das am häufigsten eine Kombination aus Überwachung und Warnmeldung konfiguriert ist. Sie sagt jedoch nichts über die Ursache des Problems aus und trifft nicht einmal eine verlässliche Aussage darüber, ob überhaupt ein Problem vorliegt.

Eine hohe CPU-Auslastung ist häufig lediglich der Beleg dafür, dass das System mit dem Bedarf Schritt hält und somit für den konzipierten Workload richtig dimensioniert ist. Mit einigen Änderungen kann die Warnmeldung allerdings nützlich werden. Hierfür müssen zuerst drei Daten gesammelt werden:

• Die CPU-Auslastung (CPU_UTIL)

• Die Anzahl der CPUs (oder Kerne) im System (CPU_COUNT)

• Die Anzahl der Aufträge in der Verarbeitungswarteschlange (CPU_QUEUE)

Anschließend sollte für den folgenden Fall eine Warnmeldung ausgelöst werden:

(CPU_QUEUE > CPU_COUNT) UND (CPU_UTIL > x%) [für mehr als y Minuten]

Wenn diese Warnmeldung ausgelöst wird, erfüllt der Rechner mit Sicherheit nicht die Workload-Anforderungen. In diesem Fall liegt entweder ein Fehler in der Prozessplanung vor, oder die Hardware ist zu alt und kann nicht mehr Schritt halten.

Warnmeldungen im Zusammenhang mit der Bandbreite

Wenn man sich bei der Überwachung von Linkauslastungen ausschließlich auf die Bandbreite konzentriert, kann man erneut nicht feststellen, was schiefläuft – nicht einmal, ob überhaupt etwas schiefläuft. Auch hier gilt: Eine hohe Bandbreitenauslastung ohne weitere negative Indikatoren ist im Allgemeinen ein Anzeichen dafür, dass die benötigte Bandbreite für die entsprechenden Anforderungen zur Verfügung steht und die Bandbreitenanforderungen gut geplant sind.

Eine Warnmeldung im Zusammenhang mit der Bandbreite ist nur dann sinnvoll, wenn man bspw. auch die Antwortzeit mit einbezieht. Denn nur, wenn die Bandbreitenauslastung über einem bestimmten Prozentsatz liegt und gleichzeitig die Antwortzeit über die Schnittstelle einen hohen Wert aufweist, gibt es einen Engpass im System.

Bei oben genanntem Prozess würde keine Warnmeldung ausgegeben, wenn sich die Bandbreitenauslastung auf einem normalen Niveau bewegt und die Antwortzeit einen hohen Wert aufweist. Dennoch kann bei dieser Konstellation ein Problem vorliegen. In diesem Fall kann man beispielsweise mit NetFlow einen guten Einblick in die Verwendung der Bandbreite bekommen und bestimmen, ob die Kombination aus langer Antwortzeit und konkreter Bandbreitenauslastung Sorge bereiten muss.

Überwachung der CPU-Auslastung in virtuellen Umgebungen

Die Überwachung der CPU-Auslastung von virtuellen Maschinen ist – gelinde gesagt – problematisch. Dies liegt daran, dass die virtuelle Maschine eventuell davon ausgeht, dass die CPU-Auslastung hoch ist, obwohl die physische Ressource tatsächlich nicht einmal ansatzweise ihre Kapazitätsgrenze erreicht hat. Ebenso kann es vorkommen, dass die virtuelle Maschine von einer geringen CPU-Auslastung ausgeht, obwohl es eventuell ein Problem mit einer anderen VM auf demselben Host gibt – etwa einen “Noisy Neighbour”, der für eine suboptimale Kapazität sorgt.

Um diese Warnmeldung korrigieren zu können, muss man zuerst die CPU-Bereitschaftszeit (den RDY-Prozentsatz) ermitteln. In diesem Zustand könnte die virtuelle Maschine die Aufgaben des IT-Administrators erledigen, muss aber warten, bis der Hypervisor diese Aufgaben auf die physischen CPUs verteilt hat. Hierzu kommt es in der Regel, wenn sich auf einem physischen Host zu viele virtuelle Maschinen befinden.

Das zweite Datenelement, das bestimmt werden muss, ist der Co-Stop-Wert. Dieser Wert steht für die Dauer, in der eine SMP-VM bereit zur Ausführung war, aber aufgrund eines Planungsproblems bei einer anderen virtuellen CPU (vCPU) noch nicht ausgeführt werden konnte. In einer virtuellen Maschine mit mehreren vCPUs ist der Co-Stop-Wert ein Indikator für: a) die zusätzliche Dauer zwischen dem Zeitpunkt, zu dem die erste vCPU verfügbar ist, bis zum Zeitpunkt, zu dem die anderen für die Jobausführung erforderlichen vCPUs verfügbar werden, oder b) die Dauer, während der die vCPU aufgrund von Planungsproblemen angehalten wird.

Wenn man beide Datenelemente ermittelt hat, empfiehlt es sich, auf der Basis der folgenden Formel, einen Warnungsschwellenwert festzulegen:

CPU-Bereitschaftszeit > (10 % * <Anzahl der vCPUs>) oder Co-Stop > 3 % [für mehr als y Minuten]

Warnungen auf Basis von Top-10-Liste

Warnungen auf Grundlage einer Liste wie „Top 10 der Abfragen, sortiert nach CPU-Auslastung“ sind im Grunde genommen nahezu nutzlos, werden aber sehr häufig definiert. Dabei sollte es anstatt um die „häufigsten Anfragen“ vielmehr um die Anfragen gehen, die innerhalb eines bestimmten Zeitraums die längste Wartezeit aufweisen. Wenn man diese bestimmt hat, lassen sich Probleme mit der Datenbankleistung viel einfacher ermitteln und beheben.

Fazit

Die Beispiele für eine schlechte Überwachungs- und Warnmeldungs-Konfiguration erstrecken sich über verschiedene Bereiche der IT. Sie verdeutlichen exemplarisch, dass sich die richtige Denk- und Herangehensweise bei der Festlegung von Überwachungsparametern und Warnmeldungen in erheblichem Maße positiv auf das Aufspüren tatsächlicher Probleme auswirkt. Vielleicht waren die gezeigten Beispiele ja ein Anstoß, sich die eigene Überwachungskonfiguration im Hinblick auf Optimierungspotenzial noch einmal genau anzusehen.

Über den Autor

Leon Adato ist Head Geek bei SolarWinds.

(ID:45344036)