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.

Weiter geht’s!

 

Letzte Woche sah ich mich in einer Krisensituation. Ich wurde von einer Fliege attackiert.

Jetzt sagt ihr natürlich „nimm halt eine Fliegenklatsche“ – aber so einfach ist das nicht. Man will ja auch langfristig Ruhe haben und braucht einen Plan.
Als ich mit dem Planen angefangen habe dachte ich sofort in größeren Dimensionen:

 

 

Leider hat sich sowohl Dimension als auch Dauer der Planungsphase etwas erhöht.
Aber die gute Nachricht ist; während dessen ist die Fliege weitergezogen. Sie hat sicher erkannt, dass ich Großes plane!

 

Nun aber zu anderen Planungen. Was haben wir bisher mit dem Patch Manager angestellt?
Das Ding läuft, WSUS ist integriert, Clients anhängend, wir haben ein komplettes Inventar und können loslegen.


Besorgen wir uns also zuerst einmal ein Paket zum Patchen. Glücklicherweise müssen wir uns in den meisten Fällen nicht selbst darum kümmern.

Solarwinds hat hier eine Liste mit betreuten Updates. Generell läuft das simpel aber wir müssen es noch kurz einrichten.

Klickt einmal auf Administration and Reporting --> Software Publishing, dann rechts auf Patch Manager Update Configuration Wizard

 

 

Den Schritten folgen

 

 

Wählt aus was von Interesse ist:

 

 

Wann soll nach neuen Updates gesucht werden -  das sind hier keine „Patch Dienstag“ Dinge, von daher schlage ich jede Nacht vor:

 

 

Lasst die Synchronisierung einmal durchlaufen – die kann man auch schnell manuell triggern – und sucht euch ein Paket aus. Ich nehme das Beispiel hier:

 

 

Ich habe nach „creation date“ sortiert um die aktuellsten Pakete direkt oben zu sehen, suche nach „upgrade“, rechtsklicke das oberste Paket und wähle „Download Content“

 

 

Patch Manager hüpft dann direkt zum Hersteller und lädt die Datei herunter:

 

 

Nochmal rechtsklicken aber dieses Mal wählen wir Publish Packages. Beachtet das kleine grüne Icon links – das sagt uns, dass die Datei runtergeladen wurde.
Unter Umständen wird dies erst nach einem Refresh angezeigt.

 

 

WSUS auswählen und weiter geht’s:

 

 

Was macht „publish“? Der Vorgang schnappt sich sowohl die Datei als auch das Script und leitet es an den WSUS weiter.
Sobald der Prozess fertig ist klicken wir auf Enterprise --> Update Service und den WSUS, dann Updates und Third Party Updates. Dort finde ich den Browser:

 

 

Rechtsklick und approve:

 

 

Das kennt ihr vom WSUS:

 

 

 

Okay fassen wir zusammen was wir gerade gemacht haben.
Ein „3rd party Paket“ wurde heruntergeladen, samt Script paketiert, in den WSUS weitergeleitet und dort zum Deployment erlaubt. Eigentlich ziemlich simpel, oder?


Jetzt verteilen wir es mal. Dazu klickt man irgendwo rechts, oder guckt einfach ganz nach rechts und wählt den Update Management Wizard

 

 

Das hier nutze ich normalerweise:

 

Next, nicht so spannend:

 

Aber jetzt!

Hier stellen wir ein, wann, warum und wie ein Neustart durchgeführt wird:

 

 

Links auch ein Knöpfchen zum Senden eines magischen Paketes!!

Ganz unten im gleichen Fenster gibt es noch zwei interessante Themen:

 

 

„Planning Mode“ geht durch die kompletten Schritte des Patchens ohne wirklich Aktionen durchzuführen. Das Ergebnis ist ein Report der mir anzeigt, was und wo patched wird.

Rechts kann man einstellen wie mit „exklusiven Updates“ umgegangen wird. Was ist das denn jetzt?!

Ihr habt sicher schon einmal gesehen wie nach Updates und Reboots plötzlich wieder Updates verfügbar sind die vorher noch nicht da waren.
Irgendwo bei dem Prozess sind Updates die Systemdateien blockieren und keine weiteren Updates erlauben bis zum Neustart. Ärgerlich! Aber hiermit stellen wir ein wie damit umzugehen ist.


Okay jetzt wählen wir die Ziele aus. Geht nicht über Los, geht direkt zu „Browse Computers“

 

 

Von den verschiedenen Möglichkeiten wähle ich die einfachste aus und gehe zu Update Services Servers und schnappe mir eine Maschine aus den existierenden WSUS Gruppen

 

 

Jetzt setzen wir endlich die Aufgabe an:

 

 

Wählen Zeit, Frequenz und Ablaufdatum aus:

 

 

 

Das war es – die Aufgabe sitzt dann unter Administration and Reporting --> Scheduled Tasks

 

 

Man könnte jetzt noch durch den Prozess gehen um eigene Pakete zu erstellen!
Das ist tatsächlich ein ganz interessantes Thema, aber auch wieder ein längeres.
Ich glaube ich benötige erst eine Kickstarter Kampagne um mir einen Schokoriegel leisten zu können…falls es mal wieder länger dauert!

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.