Hallo Zusammen!

 

Immer wieder höre ich “Echtzeit-Monitoring. Ich will Echtzeit!“ und in Gedanken sage ich „Das willst du nicht wirklich.“ oder aber „Und ich will einen Lottogewinn.“

Nehmen wir das einmal auseinander.

 

Der Grund aus dem nach Echtzeit gefragt wird ist verständlich: Man möchte so früh wie möglich über ein Problem informiert werden, um reagieren zu können.
Im Idealfalle sogar vorab nach dem Motto „das sieht nicht gut aus…gleich passiert was“ – normalerweise sagt man das wenn der gegnerische Stürmer vor dem eigenen Strafraum auftaucht, hier ist das ziemlich ähnlich (Strafraum: dein Office; Stürmer: dein Boss)!

Interessanterweise sind das zwei vollkommen verschiedene Ansätze und ich werfe einmal die Stichworte Synchron und Asynchron hinein.


Synchron bedeutet, dass in bestimmten Abständen abgefragt wird.
In Orion wird in der Grundeinstellung alle 120 Sekunden per ICMP nach Verfügbarkeit sowie Antwortzeit gefragt und etwa alle 10 Minuten nach Statistiken, die natürlich je nach System unterschiedlich sind. Richtig geraten – das sind die SNMP und WMI Geschichten.
Tatsächlich gibt es noch ein paar weitere Frequenzen aber der Einfachheit halber lassen wir es einmal dabei.

 

Polling verursacht „Stress“ auf drei verschiedenen Ebenen:
a) der Polling Engine (Orion)
b) dem Zielgerät
c) dem Netzwerk dazwischen

 

Ein NPM Poller kommt mit etwa 10000 Elementen klar solange die Pollingfrequenzen nicht geändert werden.

 

Einem vernünftigen Netzwerkgerät macht das Polling nichts aus. Irgendwo hier in thwack finden wir Beobachtungen von bis zu 6% CPU beim Polling, aber nur für eine Sekunde - also vernachlässigbar.

Meistens

 

Heartbeat via ICMP benutzt etwa 1 KB per Poll, SNMP Stats 1.5 KB und Rediscovery (hier wird nach Änderungen gesucht) 2.7 KB.
Übrigens das ist SNMP v2 – v3 mit Verschlüsslung setzt natürlich noch etwas Overhead darauf, aber v3 wird eher selten genutzt. Bei WMI auf einer Windowsbox kann man dies etwa mit 5 multiplizieren.

 

Das klingt erst einmal nach nicht viel, oder?

 

Beide Werte können je nach Bedarf global oder individual (per Node) verändert werden, das Minimum ist 10 Sekunden für den Heartbeat und 60 Sekunden für Stats.
Und natürlich hat man nicht nur eine Node/Interface.

 

Also fangen wir mal mit dem Rechnen an. Wie gut, dass ich zumindest die Baumschule besucht habe!

Nehmen wir 1000 Elemente, setzen Heartbeat auf 30 Sekunden und Statistiken auf 5 Minuten.
Also pro Stunde:
ICMP 120 Polls a 1KB x 1000 = 120 MB
SNMP 12 Polls a 1.5 KB x 1000 = 18 MB

 

Dem Netzwerk macht das immer noch nichts, oder? WAN Verbindungen ins Remote Office in Niederbayern?

 

Aber auf der Polling Engine haben wir jetzt gerade die Last verdoppelt, also können wir statt 10k nur noch 5k Elemente überwachen. Auch kein Thema, jedoch wir werden in dem Falle eher skalieren müssen und zusätzliche Poller danebenlegen was mit Kosten verbunden ist.

 

Und auf dem Zielgerät? Die Anzahl an CPU Spikes erhöht sich auf mehr als zwei pro Minute.
Das kann in manchen Situationen schon eher ein Problem sein.

 

Wenn wir das jetzt noch einmal verdoppeln, auf 15 Sekunden ICMP und 150 Sekunden SNMP…rechnet es euch selbst aus.
An Echtzeit ist hier also überhaupt nicht zu denken.

 

Aber!
Wir sehen Trends. Mit jedem Poll sehen wir Annäherungen an Schwellwerte und ich kann unter Umständen tatsächlich vorab einschätzen, dass der Wert durchaus überschritten werden kann, wenn die Situation so weitergeht. Mein Boss hat also schon sein Office verlassen, ist an der Toilette vorbeigegangen, auch nicht in die Küche die auf dem Weg liegt. Es wird eng für mich!

 

 

Jetzt kommt Asynchron dazu.

 

Was ist das? Syslogs und Traps. Zeugs passiert auf dem Gerät und das Gerät sendet eine Nachricht in so ziemlich dem gleichen Moment. ECHTZEIT!

Orion kann diese Nachrichten empfangen, Auswerten und in einen Alarm packen.

Das hilft uns in vielen Situationen wirklich weiter, z.B. bei einem plötzlichen Anstieg von irgendeinem KPI, vielleicht CPU.

Natürlich gibt es auch hierbei ein paar „aber“, wie z.B. dem Zeitraum den ein Alarm braucht, um die Bedingungen zu überprüfen (standard: 60 Sekunden), ebenso ist das Anlegen eines Alarms auf Syslogs nicht ganz so komfortabel wie bei SNMP Werten.

 

Trotzdem bedient das mein zweites Scenario.
Ich warte jetzt auf eure Ideen wie ich ein Syslog meines Bosses erhalte!

 

Jetzt stelle ich aber einmal eine These auf:
Echtzeitpolling mit Solarwinds ist möglich.

Wie jetzt Sascha, hast du nicht gerade erst erzählt Echtzeit ist Mist suboptimal? Ja, aber…

 

Nehmen wir mal an, wir erhalten von einem Switch ein Syslog über HIGHCPU.
Über SNMP sehen wir das frühestens wenn das Polling das nächste Mal zuschlägt, und dann auch nur als errechnetes Delta. Bei einer kleinen Spitze wird das nicht weiter auffallen – und, ganz ehrlich, spielt dann meist auch keine Rolle. Aber wenn der Zustand länger bleibt wird Handlung erforderlich.
Wie also messen wir jetzt?
Hier kommt das Engineers Toolset wie gerufen.

 

Das kennen sicherlich einige – falls nicht; es ist eine Sammlung von knapp 60 kleinen Werkzeugen die man normalerweise auf dem Laptop installiert. Das Paket kommt aber auch mit 5 Tools die sich in Orion integrieren und eines davon ist ein CPU Monitor.
Das Ding sammelt dann tatsächlich Daten in Echtzeit, solange es läuft. Sieht so aus:

 

Na klar verursache ich jetzt gerade Stress auf dem Netz und dem Gerät aber es läuft nicht permanent sondern adhoc; dann, wenn ich es wirklich brauche. Ein Kompromiss!

 

Und jetzt kommt das Nähkästchen.
Ihr kennt ja den Perfstack.

Wir arbeiten ja gerade an einem grossen Plattform-Update und nahezu alle Produkte bekommen eine neue Version. Teil dessen ist auch Perfstack 2.0 und damit kommt…TROMMELWIRBEL… Echtzeit!

 

 

Das „real-time polling“ ist im Prinzip auch nur ein normales Polling jedoch im Abstand von einer Sekunde und wird von einer unabhängigen Pollingengine durchgeführt. Die Daten landen nicht in der DB neben dem Standardpolling – das wäre auch schrecklich unpraktisch bei der Berechnung von Durchschnitts- und Schwellwerten, ebenso müsste viele Alarme angepasst werden.

Die folgenden Datensätze werden sich per SNMP oder WMI abfragen lassen:

 

Das Beste daran: Im Gegensatz zum Toolset ist hier keine weitere Lizenz erforderlich, das Ding kommt als kostenloses Feature mit dem nächsten Update. PARTY ON!

 

Also, fassen wir es einmal kurz zusammen.

Permanentes Echtzeitpolling überall ist sinnlos und kontraproduktiv.
Ein kluger Einsatz von asynchronen Benachrichtigungen hilft uns die Pollingfrequenzen in gemäßigten Intervallen zu halten, und sollte temporär Echtzeit erforderlich sein gibt es zwei verschiedene Methoden innerhalb Orion.
Und mein Boss muss outbound UDP 514 freischalten.