1 2 Previous Next

THWACK EMEA

30 Posts authored by: saschg

Tach Zusammen!

 

Dieses Posting ist ein Inhaltsverzeichnis meiner deutschsprachigen Themen hier in thwack.
Ich versuche das Ding hier immer aktuell zu halten.

 

Falls euch irgendein Thema interessiert – Vorschläge sind immer willkommen.

 

Die Evergreens zuerst

Wie installiert man ein SolarWinds Orion® Modul
https://thwack.solarwinds.com/groups/thwack-emea/blog/2016/12/28/wie-jetztinstallieren

Network Discovery – Erkennungsvorgang
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/02/14/sonar-oder-wie-bekomme-ich-mein-zeug-in-solarwinds-hinein

Lizensierung
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/11/22/lizensierung-h%C3%B6here-mathematik-mit-katzen

 

Produkt-spezifische Informationen

Network Configuration Manager (NCM) Teil 1
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/03/22/ncm-auf-die-schnelle

Network Configuration Manager (NCM) Teil 2
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/03/30/ncm-auf-die-l%C3%A4nge

Server & Application Monitor
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/06/06/es-ist-ja-nicht-immer-das-netzwerk-es-gibt-auch-anwendungen

Patch Manager (SPM) Teil 1
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/07/24/einfach-mal-patchen-teil-1

Patch Manager (SPM) Teil 2
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/08/04/einfach-mal-patchen-teil-2

Patch Manager (SPM) Teil 3
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/12/13/einfach-mal-patchen-teil-3

Log & Event Manager
https://thwack.solarwinds.com/groups/thwack-emea/blog/2018/02/27/log-event-manager-ich-weiss-was-du-letzte-woche-getan-hast

Virtualization Manager
https://thwack.solarwinds.com/groups/thwack-emea/blog/2018/03/29/virtualization-manager-die-achte

Database Performance Analyzer – erste Schritte
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/11/30/dpa-erste-schritte

Log Manager für Orion
https://thwack.solarwinds.com/groups/thwack-emea/blog/2018/06/06/log-manager-f%C3%BCr-orion

 

Monitoring - Basics

Datenbanken-Überwachung
https://thwack.solarwinds.com/groups/thwack-emea/blog/2016/11/30/immer-diese-datenbanken

Echtzeit Monitoring
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/08/25/echtzeit-monitoring

SolarWinds Orion Agents
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/03/10/agents

 

Fortgeschrittene Themen

Orion Alarmierung
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/11/07/red-alert-alarm-%C3%BCberall

Orion Skalierung
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/12/20/orion-skalierung

Orion High Availability
https://thwack.solarwinds.com/groups/thwack-emea/blog/2018/01/25/high-availability

Orion Migration
https://thwack.solarwinds.com/groups/thwack-emea/blog/2018/04/27/orion-migration

Vyos
https://thwack.solarwinds.com/groups/thwack-emea/blog/2017/04/24/vyos

saschg

Log Manager für Orion

Posted by saschg Jun 6, 2018

Tach Zusammen,

 

Das Leben ist voller Herausforderungen.

 

Manche davon sind existentiell wie z.B. die Frage „was koche ich am Samstag“, manche basieren auf variablen Konstrukten wie „welchen Wein trinke ich dazu“.

Manche sind schwierig. Ich meine wirklich schwierig:

 

Aber manche Herausforderungen werden ganz einfach mit den richtigen Werkzeugen.

Erinnert ihr euch noch an Diskussionen zum Echtzeit-Monitoring und asynchrone Benachrichtigungen über Syslog und Traps?

 

Mit eurer Hilfe haben wir ein paar Herausforderungen beim Verwalten von Protokoll-Logs identifiziert:

  • Fehlende Integration zum normalen Monitoring

Ich habe ständig Logs die eintreffen und auf der anderen Seite ein Gerät welches ich über SNMP beobachte. Ich muss die Daten verbinden können sonst bringt mir das gar nichts.

 

  • Steigende Anzahl an Log-Quellen

Eine Infrastruktur wächst im Laufe der Zeit und damit steigt naturgemäß die Anzahl an Elementen die zu überwachen sind

 

  • Steigende Anzahl an Logs

Manche dieser Quellen senden eine große Menge an Daten. Nicht jede Quelle erlaubt das Selektieren bestimmter Meldungen vor dem Versenden

 

  • Speicherort der Logs

Wo lege ich die Logs ab, wie lange behalte ich sie? Ich kann vorab kaum einschätzen welche Ressourcen benötigt werden.

 

  • Visualisierung der Logs

Das ist ein großer Punkt! Syslog und Trap sind Textzeilen die unter Umständen nur schwer zu deuten sind. Ich muss das in den Griff bekommen und will nicht extra ein Studium anfangen. Ich muss verstehen was passiert. Jetzt.

 

Dank eurem Feedback haben wir den Bedarf erkannt und uns entschieden: Ja, wie hören euch und das bekommen wir hin!

 

In den letzten Monaten waren unsere Entwicklungsteams ziemlich beschäftigt und haben schliesslich ein komplett neues (und unserer Meinung nach beeindruckendes) Produkt geliefert um eure Probleme mit Logs zu beseitigen.

Ich freue mich also euch eine Vorschau geben zu können auf…


<trommelwirbel>

Log Manager für Orion

</trommelwirbel>

 

Was genau ist das Ding jetzt, und warum sollte mich das interessieren?

 

Zuerst einmal haben wir es mit einem neuen Modul für die Orion® Plattform zu tun das entweder für sich selbst läuft oder im Verbund mit anderen Modulen.

Besonders sinnvoll natürlich mit SolarWinds® Network Performance Monitor (NPM)!

 

Aber Moment, sagt ihr jetzt, Log Verwaltung…das macht ihr doch schon…

 

Richtig! SolarWinds hat schon einige Produkte für das Sammeln von Logs und jetzt kommt noch eins um die Ecke!

Man kann schon fast sagen wir sind Logging-Experten!

 

Kiwi Syslog®, Log & Event Manager (LEM), Papertrail™, Loggly® – und jetzt „LM“.
Wo sind die Unterschiede?

 

Schauen wir einmal – Papertrail und Loggly sind SaaS Produkte und zielen primär auf DevOps.

LEM ist eine SIEM Lösung die komplexe Regeln erlaubt, automatisierte Aktionen steuern kann und dient den Aspekten Sicherheit und Konformität.

Kiwi® hat tatsächlich eine ähnliche Zielgruppe wie LM, aber wenn Kiwi der Einstieg in die zentrale Log-Verwaltung ist, ist LM der nächste Schritt in Richtung Korrelation, Visualisierung und natürlich der Integration in die Orion Plattform mit all den Vorteilen.

 

Genug geredet, lasst uns das Ding einmal anschauen!

 

Nach der normalen Installation gibt es einen neuen Reiter im Menü, fantastisch!

 

 

Damit wir Daten bekommen klickt bitte auf ein Gerät das Logs sendet und auf „Edit Node/Knoten bearbeiten“ und scrollt ein wenig herunter:

 

 

Nach dem Eintreffen der ersten Logs finden wir einen neuen Button in der Management-Box:

 

Ich wähle aber den Einstieg über Dashboards --> Logs --> Log Viewer.
Wenn wir drauf klicken sieht es erstmal ein wenig aus wie der Performance Analyzer innerhalb der Plattform:

 

 

Oben haben wir die eingegangenen Logs der letzten 10 Minuten. Ich klicke auf die 10 Minuten und sehe:

 

Nett, wie beim PerfStack!
Natürlich kann ich in der Zeitachse oben auch mit der Maus dynamisch einen Zeitraum auswählen.

 

Links finde ich einen Filter:

 

Im Moment ist nichts ausgewählt also sehen wir alle Nachrichten und diese natürlich in der Mitte.
Ganz unten die Anzahl an Events die im ausgewählten Zeitraum eingetroffen sind:



Klicken wir mal auf irgendeine Nachricht und sehen ein neues Element ganz rechts:

 

 

Ein paar Dinge sollten ins Auge fallen – wir sehen direkt das aktive Filtering welches Elemente als Login und in Grün klassifiziert:

 

Das funktioniert durch Regeln. Die finden wir rechts oben:

 

Aufgepasst. Links kann man zwischen vordefinierten und eigenen Regeln wählen:

 

Basteln wir uns einmal eine Regel?

Klickt auf „my custom…“ und dann auf „Create new rule“ um den Assistenten zu starten:

 

Ich habe verschiedene Bedingungen zur Auswahl – schaut euch das bei einem Livesystem einmal in Ruhe an, hier nur ein Beispiel:

 

 

 

Der nächste Schritt:

 

 

Zur Auswahl stehen uns schon ein paar Aktionen:

 

 

Taggen wir einmal!

 

Wir sehen eine Vorauswahl die um unsere eigenen Tags ergänzt werden kann:

 

Das Verändern oder Löschen von bestehenden Tags ist im Moment noch nicht über die Benutzeroberfläche möglich, kann aber über die Datenbank erledigt werden.

 

Alternativ können wir als Aktion auch Executables und Scripts ausführen und ein paar Variablen als Schalter übergeben:

 

 

Gehen wir noch einmal auf die Übersicht zurück. Rechts oben neben den Regeln ist noch ein Knopf:

 

Jetzt werden die Events in Echtzeit angezeigt wenn sie hereinkommen und die Zeitachse oben ist dynamisch.

 

Es gibt auch eine Such-Box:

 

Wonach Suchen…im Grunde genommen kann ich nach allen Dingen suchen die in Logs auftauchen wie vielleicht IP Adressen, Zeit/Datum oder beliebigen Inhalten. Ich bin gerade so unkreativ und suche nur nach dem Port:

 

Die Suche funktioniert sowohl mit historischen- wie auch mit Echtzeit-Daten als adhoc Filter, und auch Geräteübergreifend. Das ist ziemlich praktisch. Trotzdem kommen mir jetzt Selbstzweifel. Schreibt man Geräteübergreifend oder geräteübergreifend? Was auch immer!

 

Natürlich haben wir auch eine neue Position bei den Einstellungen:

 

 

Dort finden wir folgendes:

 

Die beiden „Show“ Positionen sind Berichte. Das macht mich neugierig.



Es gibt auch ein paar neue DB-Einträge für eigene Berichte:

 

 

Aber Moment – da kommt noch was!

 

 

Hier ist noch einmal ein Screenshot von der alten Liste von Syslogs innerhalb der Plattform. Keine Filter, keine Intelligenz, nur ein paar Zeilen Text!

 

 

Das hat sich nun geringfügig geändert

 

 

Das sollte reichen für eine Vorschau zum neuen Produkt. Nagut, noch eine Sache.

 

LM benötigt seine eigene Datenbank basierend auf 2016SP1 oder neuer.
Deswegen gibt es beim Installationsprozess auch eine neue Abfrage:

 

Wichtig: Wir empfehlen die SQL Volltext-Suche zu aktivieren.

 

 

Jetzt aber!
Bleibt nur noch die Frage, was am Samstag zu kochen.
Mein Vorschlag:
Pasta mit Salsiccia, Pistazien-Pesto und viel Parmesan.

Dazu passt hervorragend ein Glas Primitivo!

 

 

Macht’s gut!

saschg

Orion Migration

Posted by saschg Apr 27, 2018

Tach Zusammen!

 

Migration ist so ein tolles Wort. Es kommt mit einem eigenen Wiki-Eintrag:
https://de.wikipedia.org/wiki/Migration

Wir lernen also Migration heisst eigentlich nur Umzug auf Lateinisch aber selbstverständlich klingt das viel interessanter!
Tatsächlich gibt es ja nur einen interessanten Umzug:
https://de.wikipedia.org/wiki/Karnevalsumzug

Zumindest gibt es da Prinzen!

 

 

Besonders uninteressant finde ich die „die Wanderung von Schadstoffen im Grundwasserleiter“…wie gut, dass für uns lediglich die System-Migration wichtig ist.
Leider hat es diese Art der Migration noch nicht in das deutsche Wiki geschafft:
https://en.wikipedia.org/wiki/System_migration

Also ein Umzug jenseits von Köln und Düsseldorf!

 

Innerhalb der Orion® Plattform bekommen wir es eigentlich nur mit zwei Arten der Migration zu tun – die der Datenbank und/oder des Anwendungsservers.

Mehr generelle Info hier:
https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/Migration_Guide

 

In meinem Beispiel möchte ich die DB von 2014 auf 2016 umziehen!
Der Hauptgrund dafür befindet sich…*trommelwirbel*…hier:
https://thwack.solarwinds.com/docs/DOC-176988#start=25

Tatsächlich ist das ein Szenario dem man sogar schon direkt nach Abschluss einer Evaluierung begegnen kann, wenn man vielleicht von der Express Version auf eine volle DB wechseln möchte ohne Daten zu verlieren.

 

Meine Situation:

1 VM mit den Anwendungen

1 VM mit der aktuellen Datenbank auf Version 2014SP2

1 VM mit der neuen Datenbank auf Version 2016SP1

Die offizielle Dokumentation in English befindet sich hier:
https://support.solarwinds.com/Success_Center/Orion_Platform/Migrate_the_SolarWinds_Orion_SQL_database_to_a_new_server

 

Da mein System läuft, muss ich es erst anhalten.
Dadurch entsteht natürlich ein Loch im Monitoring was ich aber ignorieren kann – ihr solltet das planen!

Ich gehe zu meiner VM und starte den Kollegen hier:

 

Okay jetzt stellt bitte sicher, dass ihr entweder
a) ausserhalb der Geschäftszeiten im Buero sitzt
-oder-
b) schon einen neuen Arbeitsvertrag irgendwo anders unterschrieben habt

 

Wenn a oder b zutreffen, klickt auf „Shutdown Everything“.
Keine Sorge, mit „everything“ ist nur SolarWinds gemeint und nicht der Rest der Welt!

Nach ein paar Sekunden ist alles Rot:

 

Tipp: Vergewissert euch, dass überall „stopped“ und nicht „stopping“ steht.

Dann auf zum nächsten Schritt. Kaffee? Noch nicht!

 

Wir müssen die DB Dateien verschieben.

Öffnet SQL Management Studio und findet die DB:

 

 

Rechtsklick darauf, Tasks und Backup

 

Merkt euch den Standardpfad oder ändert ihn und klickt auf OK

 

Schnappt euch die Datei und schiebt sie auf ein Netzwerkshare oder gleich direkt in das Dateisystem auf die neue Maschine.

Im SQL Management Studio ebenfalls wechseln:

 

Database --> Restore

Ich habe die .bak auf C: liegen:

 

Alles gut:

 

 

Jetzt müssen wir dem System noch mitteilen, dass die DB umgezogen ist. Migriert meine ich natürlich, migriert!

Also gehen wir auf den Anwendungsserver und starten den Configuration Wizard und wählen die Database aus:

 

Jetzt aber aufgepasst!

Hier kommt der aktuelle Zustand:

 

 

So soll es aussehen nach dem Einpflegen der neuen Daten – wir brauchen temporär ein Konto mit mehr Berechtigungen um einen neuen Benutzer anlegen zu können:

 

Die DB wurde gefunden! Ein Meilenstein!

Nun schnell noch das Konto erstellen:

 

Jetzt ist es Zeit für einen Kaffee. Viel Kaffee:

 

 

Wir haben unseren Job gemacht und müssen warten:

 

Und schliesslich:

 

Die Webseite startet:

 

Und ein kurzer Test zeigt, dass per „add default“ der neue SQL angesprochen wird:

 

Das war es! Jetzt kann die alte DB weg.

Es gibt dazu übrigens auch ein tolles Wort mit Wiki-Eintrag: Decommissioning.
https://en.wikipedia.org/wiki/Decommissioning

In Deutsch ganz einfach: Stilllegung. Mit drei L.

 

Und um das Thema auch noch kurz anzusprechen – wenn ich jetzt auch den Anwendungsserver migrieren möchte, vielleicht um von einem 2008 auf ein 2016 zu kommen folge ich in etwa diesen Schritten:

Ich installiere erst die Orion Plattform mit meinen Modulen auf der neuen VM – ganz einfach als Evaluierungsversion ohne vorherige Eingabe von Lizenzschlüsseln.
Durch den Configuration Wizard lasse ich mir irgendwo temporär eine DB anlegen die ich aber nie benutze.

Sobald das neue System steht, deaktiviere ich die Lizenzen auf dem alten System mittels License Manager. Diese stehen mir dann auf dem neuen System wieder zur Verfügung.
Sobald die Plattform wieder lizensiert ist, nutze ich den Configuration Wizard noch einmal und verweise auf die schon bestehende, echte, SQL hin.

 

Es gibt ein paar Stolperfallen – so werden z.B. Berichte die irgendwann mal mit der alten Win32 Anwendung erstellt worden sind nicht automatisch gesichert und wenn die neue VM eine andere IP oder gar einen anderen Hostnamen hat muss dies per Hand in der DB angepasst werden.

Aber das will ich heute ja alles gar nicht machen.

Meine Datenbankmigration ist geglückt, ich werde das Wort Migration auf der nächsten Party benutzen um schrecklich intellektuell zu erscheinen, und ausserdem scheint gerade die Sonne!

 

BRB, muss meine Sonnenbrille suchen!

Tach Zusammen,

 

Gute Neuigkeiten:
Wir starten eine Deutschland-Tournee!

 

 

Die meiste Zeit über sitzen wir in unseren Bueros und suchen nach weiterem Optimierungspotential für unsere Software. Und trinken Kaffee, na klar!

Im April und Mai aber steigen wir in ein Flugzeug und kommen zu ein paar Terminen nach Deutschland.

 

Am 24.April sind wir zu Gast bei unseren Partner Ramgesoft der uns eine nette Location in München gesichert hat. Es gibt ein paar „fliegende Überraschungen“  

Details und Anmeldung hier:

http://ramgesoft.eu/index.php/de/component/seminarman/courses/72-hybrid-it-monitoring-mit-solarwinds?Itemid=1420&mod=1

 

Am Folgetag, dem 25.04., hat uns unser Partner heureka nach Stuttgart eingeladen.
Dort werden wir uns im Fernsehturm treffen und danach von einem Fernsehkoch verköstigt!
Mehr Informationen hier:
https://www.heureka.com/solarwinds_partner_event_2018

 

Weiter geht es dann im Mai.

Am 15.05. sind wir in Düsseldorf, nicht zu weit weg von meiner Heimat!
Dort findet man uns hier:
https://www.budenfreunde.de/

 

Einen Flug weiter, einen Tag später sind wir in Berlin:
https://www.sohohouseberlin.com/de/private-event

 

Von da aus mit dem Zug nach Hamburg, wo wir am 17.05. „auftreten“:
https://www.gastwerk.com/hotel-hamburg/tagungshotel/

 

Aber was machen wir den jetzt eigentlich an den Terminen?

Nun, ihr könnt euch sicher vorstellen was ich mache im Land von Schnitzel und Currywurst!

 

Aber ganz nebenbei haben wir einige Vorträge im Programm, bringen Neuigkeiten mit, stellenweise werden wir von Kunden hören wie ein Rollout von unseren Lösungen das Leben erleichtert hat – das ist auch für mich spannend da mein Verantwortungsbereich üblicherweise beim Planen eines Deployments aufhört.

Wir werden ein oder zwei Laptops im Gepäck haben um Abseits der Vorträge ein paar Dinge zeigen zu können für jeden der an gezielten Informationen interessiert ist.

Selbstverständlich wird zwischendurch auch Zeit für ein kleines Gespräch sein!

 

Zum Anmelden für die Termine im Mai bitte hierhin:

https://www.silicon.de/event/solarwinds-roadshow-2018/

Natürlich ist die Teilnahme an sämtlichen Terminen vollkommen kostenlos!

 

Ich bleibe noch eine Woche länger in Deutschland. Ab dem 22.05. sind wir in Berlin auf diesem Event:

http://www.nitec.nato.int/

Wer in diesem Bereich tätig ist und auf der Messe erscheint kann gerne einmal vorbeikommen. Man munkelt wir haben ein paar Goodies zu vergeben!

Zwischen Hamburg und Berlin bin ich das Wochenende über in Leipzig – ausnahmsweise aber nicht für die Firma unterwegs. Ich war noch nie dort! Falls jemand ein paar Restaurant-Empfehlungen für mich hat, immer her damit!

 

Bis dahin – ich hoffe wir sehen uns!

 

Tach Zusammen!

 

Vor gefühlten hundert Jahren habe ich unseren Virtualization Manager (VMan) vorgestellt. Seitdem hat sich einiges geändert.

Nein, ich rede nicht von der Erfindung des Mobiltelefons was schon ungefähr 250 Jahre her sein muss, wenn ich auf den Stapel Rechnungen schaue.

Tatsächlich gab es bei unserem VMan eine Metamorphose im wahrsten Sinne des Wortes.

Kurz zur Erinnerung:
VMan war ursprünglich eine virtuelle Appliance und sah so aus:

Nach und nach wurden Features von der Appliance in die Orion® Plattform geschoben und das ganze Ding wurde im Laufe von Jahren mehr und mehr integriert.

- Im September 2017 haben wir Version 8.0 veröffentlicht mit der Option auswählen zu können, ob das Polling von der Appliance oder vom Orion Server durchgeführt werden soll.

- Im Dezember mit Version 8.1 wurde mit Capacity Planning das letzte exklusive Feature von der Appliance zu Orion migriert, was die Appliance dadurch nicht nur optional, sondern obsolet gemacht hat.

- Im März 2018 schliesslich Version 8.2 mit einem verbesserten Wizard um virtuelle Infrastruktur zu Orion hinzuzufügen.

 

Die Installation des VMans ist jetzt wie bei jedem anderen Orion Produkt und demnach etwa so simpel wie eine Tasse Kaffee herzustellen:

 

Okay nach der Installation bzw dem Trinken dieses Kaffeepuddings müssen wir Zeug in Orion hineinbekommen. Dazu gibt es verschiedene Methoden, z.B. in den Settings um direkt einmal den neuen Wizard auszuprobieren:

Ich bin so aufgeregt, weil der auch für mich neu ist!

Ich kann auswählen:

 

Ich bin vor ein paar Monaten umgestiegen auf Hyper-V™ und gehe einen Schritt weiter:

 

 

Ich bekomme eine ganze Menge Zeugs angezeigt:

 

 

Und füge einfach alles hinzu:

 

Im Prinzip muss man jetzt warten bis genug Daten gesammelt haben.
Aber ich habe hier etwas geschummelt und die Daten sind alle da.

 

Also legen wir los. Ein guter Startpunkt ist immer die Zusammenfassung:

 

Die Daten links habt ihr vielleicht auch schon einmal vom NPM oder SAM allein gesehen:

 

Andere Dinge kommen jetzt neu dazu wie zum Beispiel diese wirklich hervorragende Nachricht:

 

Wer meine Posts verfolgt weiss, dass das jetzt üblicherweise ein Grund wäre um entweder eine Tasse Kaffee zu trinken, einen Wein zu öffnen oder ein Schnitzel zu essen.

Auf der Suche nach irgendwas bin ich hier im Büro in die Küche gegangen und sehe das hier:

 

Ich werde euch nicht mitteilen, für was ich mich entschieden habe.

 

Also weiter.
Ich klicke auf einen Host und sehe wieder bekannte Datensätze:

 

Aber guckt mal links dort sind jetzt zwei neue Reiter dazu gekommen, Storage und Virtualization Summary:

 

 

Storage gibt mir Latenz und IOPS für sowohl die Datastores als auch die VMs:

 

Aufgepasst: Bei Hyper-V gibt es leider keine VM Latenz:
https://support.solarwinds.com/Success_Center/Virtualization_Manager_(VMAN)/Hyper-V_virtual_machine_latency_shows_as_zero

 

Ich klicke auf eine VM, diesmal wähle ich den Reiter Virtualization Summary und plötzlich wird es richtig interessant.

Links stehen mir Aktionen zur Verfügung:

 

Ihr könnt ruhig ein bisschen Herumklicken – es kommt immer noch eine Sicherheitsabfrage bevor tatsächlich was passiert.

Rechts, unter den Tachos, ist ein Element das ihr lieben lernen werdet:

 

Es werden vergleichende Werte für die VM und den Host angezeigt. Prima, um einmal über den Tellerrand hinaus schauen zu können.

Übrigens ist das eine gute Stelle um einmal in unseren Performance Analyser zu schauen falls ihr den noch nicht kennt. Klickt einfach mal oben auf den Link.

 

Aber ich mag euch noch ein paar richtig nette Dinge beim VMan zeigen.

Wählt bitte einmal „sprawl“ aus.

 

Hier nutzen wir die gesammelten Daten und vergleichen Auslastung mit zugewiesenen Ressourcen.

Bei mir liegt gerade eine frische VM herum – der Plan ist, meine Orion DB bald von 2014 auf 2016 zu migrieren – die hat natürlich Memory zugewiesen der gerade nicht in Benutzung ist:

 

Auf der gleichen Seite werden weitere VMs angezeigt die nichts tun außer zu existieren.
Was macht man mit solchen?

 

Ich nenne das Holzhammeradministration.

 

Ein weiteres Feature ist das Planen von zukünftigen Änderungen in der Virtualisierung. Klickt auf Capacity Planning.

Ich kann hier verschiedene Spiele betreiben:

 

Hier werden ebenfalls die gesammelten Daten genutzt um diese exakt berechnen zu können, wie viele VMs ich noch platzieren kann und welche Resources als erstes knapp wird.
Da unter Umständen mehrere Wochen von Daten benötigt werden hier ein Auszug aus einem fertigen Bericht:

 

 

Das dritte besondere Feature sind die Empfehlungen/Recommendations.

Zuerst etwas Offensichtliches:

 

Schauen wir uns die einmal genauer an:

 

Vertrauen wir dem System? Eigentlich schon, aber lasst uns das einmal überprüfen.
Ein Mausklick gibt etwas mehr Details:

 

Ich schaue mir die Orion VM genauer an. Ich habe verschiedene Möglichkeiten.

 

Oder:

 

Oben auf Edit kann ich natürlich den Zeitraum anpassen

 

Dazu sind diese Elemente/Widgets zwar nicht gedacht, aber um einmal kurz etwas anzuschauen:

 

Weil ich grad dabei bin öffne ich noch den „Average CPU Utilization – This week“ Report der mitgeliefert wird:

 

Nach all diesen Informationen beschliesse ich den VMan Empfehlungen zu vertrauen und nie wieder in Frage zu stellen!

 

Ich könnte jetzt also diese Aktionen durchführen lassen:

 

 

Das mache ich nun aber nicht…weil…

 

 

Auf einem anderen System habe ich eine weniger offensichtliche Empfehlung gefunden:

 

Das ist etwas das uns eigentlich gerade nicht stört. Es läuft ja alles wunderbar.
Aber was ist wenn ein Ernstfall eintritt? Dann mag mir das durchaus Kopfschmerzen bereiten.
Daher hier der Vorschlag:


Zusammen gefasst bietet VMan eine schönes Paket zum Überwachen der virtuellen Infrastruktur und geht über normales Monitoring hinaus mit Features wie Capacity Planning.

Die Lizensierung ist einfach anhand aller physischen CPUs in den Hosts.
Das heisst, dass ich auf Performancedaten sämtlicher VMs bekomme ohne diese lizensieren zu müssen.

Wenn ihr auf eine VM klickt wird unter Umständen jedoch so etwas erscheinen:

 

Das besagt einfach, dass VMan die VM im Griff hat, aber ich jetzt gerade noch keine Anwendungen darauf überwachen könnte. Dazu muss ich die VM aktiv überwachen und mir stehen die Daten in SAM und weiteren Modulen zur Verfügung.

Das wiederum wird allerdings Lizenzen bei den jeweiligen Produkten konsumieren.
Für weitere Informationen zu diesem Thema verweise ich auf meinen Lizensierung-Blogpost. Schon alleine wegen der Katzen!

 

Da fällt mir ein…ich war neulich in Edinburgh und dort gibt es tatsächlich ein „Katzen-Cafe“.
Man kann dorthin gehen, Kaffee trinken, Kuchen essen…und überall sind Katzen!! Fantastisch!

 

 

Bis demnächst!

saschg

Bad day at work?

Posted by saschg Mar 9, 2018

...here is how to fix it.

 

First of all: You probably do not know me.That is because I usually post in German.

I am working for the company that unites us here at this beautiful place.

 

You are wondering how working for Solarwinds could possibly end in a bad day? Now there is the weather here in Ireland, issues with laptops when you rely on them, the lack of schnitzel in general or the worst-case scenario: no milk left in the fridge when you just got a fresh coffee.

Whatever. Let me show you how to fix such a day.

 

1) As soon as you finish work go home and only stop to get a (surprisingly) nice bottle of wine

 

2) At home, do not get rid of shoes, phone or the keys to your Star Destroyer. Instead, the first thing you do is to open the wine.

     2a) do not forget to drink the wine

 

3) Turn on a playlist with stuff no one likes but you. Here are some suggestions how that looks like for me:

4) Use the skills sharpened in endless Molten Core raids since 2005 and raid your kitchen for a few ingredients

 

5) Find the stuff you need for this recipe http://www.donalskehan.com/recipes/tomato-mozzeralla-basil-pizza/ and follow the first two steps

 

6) Return to your kitchen raid group and find ingredients for a recipe loosely based on this
https://www.housebeautiful.com/lifestyle/recipes-cookbooks/recipes/a478/salmon-pea-risotto-recipe-tyler-florence-0411/

 

7) Fail because there is only normal rice left and no Arborio. Make a note to yourself.

     Make sure to revisit 2a) frequently. Create an Orion alert if necessary.

 

8) Prepare the risotto and ignore the fact that it looks poor.

     We want to fix a bad day remember? Any issues? 2a my friends.

 

 

9) Eat. Do you want to know a secret? It is the ingredients. I have chosen the 30-month-old Parmesan:

 

10) Make sure your girlfriend/partner got flowers because it is Woman’s day
     10a) If the flowers coming from you; bonus points!
     10b) If you are like me; you may have failed

 

11) Now things become really interesting. Return to 5) and get a glass of your favourite nut nougat spread.

 

12) Put some of it on top of bits of the dough and add shredded nuts or almonds.

13) Throw a batch into the oven for 8-10 minutes at around 200 degrees

 

14) Enjoy your first Mini-Nutella-Calzone!

 

15) Make sure that there are no leftovers for your co-workers
     15a) Make sure they are not aware of what you just did!!

 

Now I am actually looking forward to the next bad day at work!

Tach Zusammen,

 

Neulich habe ich einmal meine thwack Punkte investiert. Guckt hier:

Ich habe eine gute Idee, was man damit machen kann!
Aber vor dem Vergnügen erst ein bisschen Arbeit.

 

Bisher habe ich über einige Orion Module referiert sowie den „teil-integrierten“ Patch Manager. Um Langeweile vorzubeugen heute einmal etwas Anderes – unsere SIEM Lösung Log & Event Manager, kurz LEM.
LEM sitzt hinter euren AV-Lösungen, Firewalls, DLP Software etc und zeigt die Daten zentral und übergreifend an. Ich kann also mit LEM nachvollziehen, wer wo durch mein Netzwerk wandert und was angefasst oder auch nur angesehen hat.

 

LEM wird nicht irgendwo hin installiert, sondern kommt als virtuelle Appliance basierend auf Linux. Je nach Geschmacksrichtung Hyper-V oder Vmware wird das Ding direkt auf den Host importiert.

Nachdem Importieren nehme ich zuerst ein paar der Ressourcen von der Kiste runter und gebe hier nur 4 Gigs und 2 vCPUs. Das reicht für ein kleines System im Test oder bei mir im Labor. Ich bin geizig.

Wenn ihr die VM startet und dann auf die Konsole geht, kommt nach wenigen Sekunden ein Screen wie dieser hier:

Das ist keine Hommage an den BSOD!
Wir sehen direkt die IP Adresse und könnten per Browser loslegen, aber zuerst geht mal unten auf die Timezone und stellt es bei korrekt ein also bei euch vermutlich Europe/Berlin.

 

Dann aber mal direkt in den Browser eures Vertrauens und ab dafür!
Das erste was man vermutlich sieht ist, dass es mit dem Vertrauen dann doch nicht so weit geht:

Ignorieren! Der Login ist admin/password als Standard:

Nach dem Ändern das Passworts sieht man ein paar Buttons ganz oben:

Und vermutlich das Ops Center unten was aber bei euch noch leer sein wird.

Bevor wir irgendwas machen empfehle ich zuerst, die Appliance auf den aktuellen Stand zu bringen.
Zum Zeitpunkt an dem ich diesen Artikel schreibe ist Hotfix 7 das neueste Release:
https://downloads.solarwinds.com/solarwinds/Release/HotFix/SolarWinds-LEM-v6.3.1-Hotfix7.zip

Im Archiv sind die Schritte zum Updaten – in a nutshell: Auf ein Netzwerkshare entpacken, dann in die LEM VM-Konsole und über Appliance den HF einspielen. Dann von dort aus Neustarten.

 

Dann die Connectors. Wenn die Appliance Internetzugriff hat klickt einfach Manage/Appliance


Dann rechts oben auf Update Now.

Wenn die Appliance kein Internet hat:
http://downloads.solarwinds.com/solarwinds/Release/LEM/SolarWinds-LEM-Connectors.zip

Der Updateprozess ist ähnlich wie beim HF – Details sind im Archiv.

 

Was ist ein Connector überhaupt?
Ich vergleiche das immer gerne mit einem Babelfisch! Kennt ihr das noch? Wenn nicht, attestiere ich euch eine böse Kulturlücke!

 

LEM kommt mit einer sehr langen Liste an Connectoren für die verschiedenste Hard- und Software die es gibt.
Eine aktuelle Übersicht findet sich immer hier:
https://thwack.solarwinds.com/community/log-and-event_tht/log-and-event-manager/lem-connector-list

 

Wenn für eine Logquelle ein Connector vorhanden ist heisst das, dass die gelieferten Daten verstanden werden können.
Diese werden dann normalisiert und stehen für weitere Korrelation zur Verfügung.

 

Die Liste wird etwa einmal pro Monat aktualisiert. Den Prozess habt ihr ja jetzt schon kennen gelernt.
Als Daumenregel; alles was bekannt, populär und überall in Benutzung ist sollte sich schon in der Liste finden. Vielleicht nicht zwingend in den aktuellsten Versionen, aber ein Hersteller X stellt beim Sprung von Version 12 auf 13 eher selten etwas am Logging um.

 

Was aber, wenn dem jetzt doch so ist? Oder – bei euch läuft irgendwas, was noch nicht in der Liste ist?
In dem Fall ist es Teil des Wartungsvertrages, dass wir versuchen einen Connector für euch herzustellen.
Auch dafür haben wir einen Prozess:
https://support.solarwinds.com/Success_Center/Log_Event_Manager_(LEM)/Submit_a_request_to_SolarWinds_for_a_new_LEM_connector

Mir fällt gerade auf das die Anzahl an Prozessen hier bei Solarwinds exponentiell gestiegen ist seitdem ich hier bin. Aber glaubt mir ich bin unschuldig! Zumindest hierbei!

 

Lassen wir die Connectoren erst einmal Connectoren sein und machen weiter. Wir kommen später noch einmal zu diesem Thema.

 

Wir brauchen jetzt Daten. Und Details.

Grundsätzlich gibt es zwei Methoden:
a) Netzwerkhardware kommuniziert über Syslogs
b) Betriebssysteme (und Anwendungen) kommunizieren über einen Agent

 

Im Falle von Networkgear ist das für uns hier gerade einfach: Wir brauchen innerhalb von LEM nichts einstellen weil das alles in der Hardware erledigt wird.
In meinem Labor zu Hause habe ich zwei Syslog-Quellen, mein NAS (QNAP) :

 

… sowie meinen Network-Controller (UBNT), der Daten von Firewall, Switch und AP liefert:

Bei anderen Devices erledige ich das natürlich über die CLI.
Wenn ich Syslogs aktiviert habe tauchen die Nodes üblicherweise von alleine auf:

Falls dort auch nach einem längeren Zeitraum nichts steht ist die beste Idee oben hier zu klicken:

Die interne Datenbank wird dann noch einmal durchforstet und etwaige neuen Geräte aufgelistet.
Wenn auch dann nichts auftaucht…wird es kompliziert. Aber nicht in diesem Posting.

 

Bei Servern/Workstations wird ein Agent benötigt, um an Daten zu kommen.
Der Agent sorgt zum einen dafür, das auch andere Events ausserhalb des Windows Eventlogs gesammelt werden können, aber er komprimiert und verschlüsselt die Daten auch vor dem Senden.
Bei Manage/Nodes habe ich diesen Knopf hier:

Dort dann Agent anklicken und ich finde die Downloads:

Für einen Test nimmt man einfach den lokalen Installer. Ich lasse Ihn einmal auf meiner Workstation laufen und es gibt eine wichtige Info zum Ausfüllen:

Und eine weniger wichtige

Das war es auch schon:

Der Agent verbindet ziemlich schnell – CTRL ist neu hinzugefügt:

Wenn ihr meinen Schritten gefolgt seid, habt ihr jetzt einen LEM up2date sowie mindestens zwei Logquellen im System.
Geben wir der Appliance nun etwas Zeit zum Sammeln von Daten und gehen ein paar Kekse essen.

 

Oder vielleicht…Deutscher Käsekuchen! Der einzige seiner Art hier in Irland, weil von mir erschaffen:

Lecker! Aber okay nun noch ein paar Basics.
Klickt bitte oben ins Ops Center und geht zu dem orangenen Ding hier:

Beim ersten Punkt stelle ich meinen Mailserver ein:

Sowie einen AD Connector:

Man könnte jetzt im Ops Center etwas aufräumen und die „getting started“ Box ebenso wie „what’s new“, „thwack“ usw entfernen – wie ihr mögt.

 

Mittlerweile sollten Daten da sein!
Schaut mal oben wieder in die Leiste und klickt auf MONITOR.

 

Monitor zeigt Echtzeit-Informationen. Schaut mal nach links unter Filters – dort sind verschiedene Gruppen mit einzelnen Kategorien aufgelistet.
Unter IT Operations finde ich bei Service Events schon etwas von meiner CTRL Maschine:

 

Ich verschiebe einmal eine Datei auf meinem NAS:

Wenn der AD Connector da ist, sieht man direkt auch die wirklich wichtigen Dinge wie fehlgeschlagene Logins, verschobene Benutzer usw ohne weitere manuelle Anpassung.

 

Bei ausgewähltem Filter kann ich oben auf das Zahnrad und Edit klicken:

Wir sehen dann wie sich dieser Filter tatsächlich zusammensetzt und könnten in manchen Situationen ein finetuning betreiben mittels drag&drop von links nach rechts:

Aber so weit will ich jetzt nicht gehen.

 

Stattdessen zeige ich euch noch schnell wo man historische Informationen finden kann.
Klickt oben auf Explore/ndepth

 

Hier schauen wir zuerst auf diese Spalte hier:

Wir sehen rechts den Zeitraum der beliebig umgestellt werden kann, ansonsten wird hier gerade nichts gefiltert.
Darunter sehen wir, dass in den letzten 10 Minuten 587 Events herein gekommen sind:

 

Ich wähle links aus, was mich gerade interessiert, sagen wir mal UserLogons, und doppelklicke:

 

Jetzt guckt noch einmal nach oben in die Leiste:

 

Der Logon wurde hinzugefügt aber ich muss noch auf den blauen Pfeil drücken um die Auswahl zu aktivieren:

 

Logons sind so ein klassisches Szenario. Üblicherweise sind fehlgeschlagene Logons interessanter aber ich habe gerade keine bei mir.
Der nächste Schritt zum Filtern ist entweder in Richtung der Benutzerkonten oder der Maschinen auf denen der Logon stattgefunden hat. Beides können wir, ich nehme zuerst einen Benutzer:

 

Den blauen Pfeil nicht vergessen:

Mein Admin hat auf drei Maschinen einen Logon-Event generiert:

 

Ich frage mich gerade, welche meiner Schatten-Existenzen hier in meinem Netzwerk herumgeistert. Ich sollte vielleicht weniger Trinken.

 

Ich kann jetzt weiter heruntergehen auf eine Maschine, kann aber auch mit den Events weiter arbeiten die mir angezeigt werden.
Guckt mal ganz nach unten:

Das sind verschiedene Visualisierungen. Klickt mal ein wenig herum, die zweite von links ist ganz nett. Wir machen aber in der zweiten Position von rechts weiter.

Alle Events mit Details werden angezeigt:


Ich kann das auch exportieren bei Bedarf:

Ganz oben kann ich die Suche auch speichern für spätere Benutzung:

Okay ein Thema zeige ich euch noch. Der LEM ist nicht nur ein Werkzeug zur Anzeigen von Daten sondern erlaubt auch Aktionen zu automatisieren.
Klickt auf Build/Rules

Und schaut einmal in die untere Hälfte. Dort finden wir einige Hundert Beispiele an vordefinierten Regeln. Guckt sie euch an. JEDE EINZELNE!

Oder nutzt links oben die Suchbox und hackt „logon failure“ ein, dann schaut unten nach dem hier

Klickt auf das Zahnrad und Clone

Zwei Dinge passieren gleichzeitig – nicht erschrecken! Zum einen wird eine Kopie der Regel nach oben befördert, zum anderen öffnet sich ein neuer Spielplatz

Ganz oben sehen wir ein Element das wir schon bei den Filtern kennen gelernt haben.
Darunter in violett die Zeit in der wir Schwellwerte einstellen können.

In Gelb (oder ist das orange? Schmutzig-weiss?) sehen wir Aktionen.

Wir sehen auch Actions ganz unten links, klickt da mal drauf!

 

Die verschiedensten Aktionen stehen uns zur Verfügung von einer simplen Email, über das Verschieben von Benutzern in AD Gruppen bis zum Herunterfahren einer Maschine.

 

Hier in thwack haben wir in der Content Exchange auch viele weitere Beispiele für Regeln, Filter und sogar Reporte:

https://thwack.solarwinds.com/community/log-and-event_tht/log-and-event-manager/content?filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Bdocument%5D

Schaut mal rein!

 

Ich aber habe jetzt etwas Anderes vor:

Aperol, Prosecco und Orange – auch Spritz genannt.

Prost & bis dann!

saschg

High Availability

Posted by saschg Jan 25, 2018

Tach Zusammen!

 

Um das Thema Skalierung abzuschließen stelle ich jetzt einmal das Sahnehäubchen vor – Orion Hochverfügbarkeit.

Es war einmal…bis Ende 2016 hinein gab es ein schreckliches Produkt bei uns. Ja, ich gebe zu, es war schrecklich: Die Failover Engine, oder auch FOE.
Hat jemand von euch einmal damit gearbeitet? Seid ihr immer noch Mitglied in der Selbsthilfegruppe?
Okay das ist Vergangenheit.
Letztes Jahr wurde FOE durch Orion HA Version 1 abgelöst und seit ein paar Monaten ist Version 2 verfügbar.


Orion HA erstellt im Prinzip eine Kopie des primären Orion Servers und funktioniert durch active/passive, liegt also solange im Hintergrund bis etwas passiert. Der Installationsprozess ist einfach, die notwendigen Anpassungen an die Infrastruktur gering.

Version 1 hatte leider eine Beschränkung: Beide Maschinen mussten im gleichen Subnetz sein.

Bei kleineren Umgebungen ist das kein Thema, aber bei mehreren Standorten muss man hier unter Umständen mit Technologien wie OTV tricksen um das VLAN zu strecken und Datenzentren verbinden.
Die Kommunikation beider Maschinen wird in dem Fall über eine virtuelle IP gelöst.

In Version 2 kam dann richtiges Desaster Recovery und erlaubt den Einsatz über Subnetze hinaus. Die Kommunikation läuft nun über einen virtuellen Hostnamen anstatt einer IP.

Soweit die Zusammenfassung und hier die komplette Dokumentation:

http://www.solarwinds.com/documentation/en/flarehelp/sam/content/ha_what_is_high_availability.htm

 

Aber ich führe euch einmal durch den Prozess!

 

Zum Verständnis:
Auf meinem Host sitzt sowohl der Orion Server (ORION) und die Datenbank (MSSQL) in einem 10.0.0.0/24 das auch nach draussen geht. Ich habe mir ein 10.0.1.0/24 erstellt das aber nur auf dem Host in einem eigenen vswitch existiert. Dazwischen sitzt eine freundliche VYOS Instanz welche die beiden Subnetze routed.
Im zweiten Subnetz habe ich eine VM ORIONHA erstellt und bisher nur in die Domain aufgenommen.

Zuerst teste ich die Namensauflösung. Es sind drei Tests notwendig; IP, FQDN, Shortname:

Das Ganze muss natürlich auf beiden Maschinen funktionieren!

Bevor ihr loslegt schlage ich vor alle Module auf den aktuellsten Stand zu bringen um Zeit zu sparen.

Öffnet auf der HA Box einen Browser, logged in Orion ein und geht zu Settings à Product… und wählt High Availablahblah:

 

Das sieht noch nackt aus und ich klicke auf Set Up:

 

Viel Auswahl gibt es hier nicht:

 

Ich evaluiere:

Dann lade ich den Installer herunter:

 

Der Installer startet, haltet euch fest…einen Installationsprozess. Und den kennen wir schon.

Ich schlage vor, das Fenster unten zum letzten Test für die DNS Auflösung zu nutzen und nur den einfachen Hostnamen einzugeben:

 

Anstatt APE/AWS wie beim letzten Mal wählen wir nun HA:

 

Oh was ist das da ganz oben?
Es gibt HA für den primären Poller, was ich gerade vorhabe, aber auch HA für zusätzliche Poller.
Das ist bei mir ausgegraut weil keine mehr vorhanden. Also weiter und der richtige Installer startet.

Nur ein Screenshot hier weil wir den schon des Öfteren gesehen haben.

 

Danach startet der Configuration Wizard. Den haben wir auch schon ungefähr so oft gesehen wie James Bond Goldfinger.

Sobald alles durchgelaufen ist wird automatisch die Seite High Availability Deployment Summary aufgerufen und wir sollten beide Maschinen sehen:

 

 

Und jetzt wird es endlich interessant. Wir brauchen einen Namen für den Pool sowie den virtuellen Host – ORIONPOOL in meinem Beispiel:

 

 

Jetzt wird der virtuelle Hostname angelegt:

 

Wir bekommen eine Zusammenfassung und klicken auf das blaue Knöpfchen:

Das war es! Naja fast.

In einer Produktivumgebung kommt jetzt natürlich noch ein Schritt der leider etwas Zeitraubend sein kann:

 

Ich würde an dieser Stelle NCM empfehlen um den Syslog Receiver/Netflow umzuändern.
Mir ist das furchtbar egal, ich ignoriere die Meldung und freue mich über das hier:

 

Ein kurzer Test:

 

Klasse:

 

Wer meinen Blog verfolgt weiss, dass ich stark abhängig bin – von Kaffee. Von daher ist jetzt Zeit für eine weitere Tasse da wir gerade einen Milestone erreicht haben.

Im DNS sieht es übrigens so aus:

 

Perfekt!

Kurz etwas für diejenigen von euch die wie ich unter OCD leiden:

- Ich nehme die ORIONHA Maschine als Node ins Monitoring

  Wenn ich das Orion SAM Template auf der HA Maschine nutze sehe ich „Probleme“:

 

- Ignorieren soweit möglich…schaltet Alarme hierfür aus.

JETZT KOMMT DER ERNSTFALL!


Hat jemand von euch einen Kollegen namens Ernst? Passt gut auf ihn auf.

Ich gehe zu meiner Orion Maschine und klaue das Netzwerk:


 

Teste die alte URL:

 

Mein Beileid:

Aber unter dem virtuellen Hostnamen:

 

Alles gut:

 

Cross-check! Die Dienste laufen nun wie erwartet auf der HA Maschine:

 

Und der Pool sagt „mir geht’s nicht gut, aber irgendwie geht’s trotzdem weiter“ – das sage ich übrigens auch wenn ich zum Mittagessen beim goldenen M war:

War das kompliziert?
Es waren ein paar Schritte sicherlich, aber wir haben gerade die Ausfallsicherheit für unser Orion innerhalb von wenigen Minuten realisiert. Das ist schon eine interessante Sache.

 

Ein paar Dinge noch hinterhergeworfen:

Windowsupdates sollten hier ähnlich behandelt werden wir ihr es bei einem Cluster erledigt, also schön nacheinander.

Orion Updates muss man planen. Wenn auf der primären Maschine Updates eingespielt worden sind, deaktiviert dies den Pool! Hier die Schritte:
http://www.solarwinds.com/documentation/en/flarehelp/sam/content/ha_upgrade_pool_members.htm

 

Es gibt HA für den Anwendungsserver, HA für die Polling Engines sowie HA für zusätzliche Webserver (wobei das vermutlich zu vernachlässigen ist).
Wir kümmern uns nicht um HA für die Datenbank – das ist eure Angelegenheit – nutzt AlwaysOn oder was auch immer am besten passt:
https://logicalread.com/sql-server-availability-technology/

 

Viel Spass mit dem Herumspielen!

saschg

Orion Skalierung

Posted by saschg Dec 20, 2017

Ich frage mich manchmal ob es einen Zusammenhang zwischen dem Wachstum einer Firma und dem Wachstum des IT Teams gibt. Vermutlich nicht so wirklich!

Es ist leicht zu messen, wenn der Helpdesk überfordert ist und wenn der CEO einmal zu lange auf ein Ticket warten muss ist das vielleicht ein Argument um das Staffing zu erhöhen.

Nagut, wenn der CEO zu lange warten muss wird das Staffing vielleicht zuerst um einen Kopf kürzer…

 

Aber im DC oder Infrastruktur-Management? Eine Handvoll mehr Switches, ein neuer Host - das kann doch alles problemlos von denen verwaltet werden die das bisher auch schon gemacht haben. Aber sicher doch!
In einer perfekten Welt ganz bestimmt, aber in einer perfekten Welt würden Dolce & Gabbana die Frühjahrskollektion kostenfrei direkt zu mir ins Haus liefern.

 

Im Idealfall sollte das IT Team natürlich mitwachsen um mit den erhöhten Ansprüchen umgehen zu können.

 

Das gleiche gilt natürlich auch für ein Solarwinds Deployment.

Die meisten von euch setzen Orion in einem ganz normalen Szenario ein – wir nennen es “central deployment”.

 

Die Orion VM kommt irgendwo in ein DC, oder auch ganz einfach den Serverraum und alles was von dort aus erreicht werden kann wird direkt abgefragt.
Das ist simpel und in der Infrastruktur muss nur sichergestellt werden, dass die Kommunikationsmethoden des/der entsprechenden Module zu den jeweiligen Elementen gegeben sind, als Beispiel also UDP 161 für SNMP, vielleicht UDP 2055 für Netflow.
Die darunterliegende Infrastruktur ist für uns transparent und uninteressant, solange eine Verbindung vorhanden ist.

 

Wie in meinem Posting zur Lizensierung erklärt, kann man das beim NPM bis zu etwa 10000 Interfaces einfach so gestalten. Darüber hinaus muss dann ausskaliert werden.

Der erste Schritt ist hier ein zusätzliches Abfragemodul einzusetzen.

 

Ich werfe in diesem Posting mit verschiedenen Begriffen um mich, lasst mich das zuerst einmal erklären inklusive der Abkürzungen die es bei uns gibt:

 

Zusätzlicher Poller --> Additional Polling Engine --> APE
Zusätzlicher Webserver
--> Additional Webserver --> AWS
Übergeordnete Zentralkonsole
--> Enterprise Operating Console --> EOC
Orion Server
--> Anwendungsserver, aber auch primärer Poller (sobald APE involviert sind)
Hochverfügbarkeit
--> High Availability --> HA

 

Zuerst etwas Theorie – zusammen gefasst:
Ein Poller erweitert die Kapazitäten sämtlicher vorhandener Orion Module um die gleiche Menge wie die „unlimitierten“ Versionen, also pro Poller z.B. weitere 10000 Interfaces beim NPM.
Der Installationsprozess erstellt im Prinzip eine Kopie des Orion Servers, daher sollten auch die Resources identisch sein.
Es wird die gleiche Datenbank genutzt! Das ist wichtig beim Planen des Standortes.

Üblicherweise setze ich mir einen Poller in ein entferntes DC und lasse alles, was dort steht, lokal abfragen. Der Poller sendet die Statistiken direkt in die DB.
Wenn die Verbindung einmal abbricht werden die Daten für eine Weile zwischengespeichert und beim Wiederherstellen der Verbindung in die DB abgesetzt.
Im Moment wird dazu noch MSMQ genutzt welches allerdings mittelfristig durch RabbitMQ abgelöst werden wird.

 

Die komplette Theorie inklusive der Kommunikationsports hier:
https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/NPM_Documentation/Scalability_Engine_Guidelines_for_SolarWinds_Orion_Products?CMPSource=THW&CMP=DIRECT

 

Achtung: Oftmals wird hier nur auf die Ports geachtet. Bitte ignoriert die maximale Latenz nicht – die sollte unter 200 ms liegen.

 

Alles klar, jetzt kommt die Praxis!

 

Der Prozess ist seit etwa einem Jahr denkbar einfach.
Zuerst wird eine VM aufgesetzt die im Idealfall, wie oben schon angemerkt, die gleichen Ressourcen hat wie das primäre Orion System.

Von der VM aus gehe ich mittels Browser auf meinen Orion Server und zu Settings --> All Settings --> Polling Engines und dort klicke ich auf diese freundliche Schaltfläche

 

Das Ding führe ich aus und sehe:

 

Dann werde ich gefragt was ich denn eigentlich vorhabe, ausnahmsweise weiss ich das auch und entscheide mich zuerst für die APE:

 

Oh hier kommt eine Zwischenfrage:

 

Hier sei kurz gesagt, dass APEs sowohl beim SRM als auch beim VMAN kostenlos sind, für die anderen Module aber nicht!
Bei mir spielt Geld aber keine Rolle! Nur bei Dolce & Gabbana

 

Der Installer zieht sich die korrekten Dateien nun vom Orion Server und testet:

 

Bei mir passt alles:

Und dann startet die tatsächliche Installation die aussieht wie die eines einzelnen Orion Moduls daher spare ich uns die Zeit und Screenshots.

 

Das habe ich mir so gedacht! Windows ist anderer Meinung:


Ich schiebe die Schuld einfach auf Windows und starte den Vorgang noch einmal. Windows kann sich schließlich auch nicht wehren.

 

Dieses Mal: Prima!

 

Was jetzt folgt kennt ihr auch:

 

Alles bleibt bei den defaults – next next next und irgendwann:

 

Dann öffnet sich ein Browser mit meiner Orion URL – was jetzt?

Zuerst gehe ich wieder zu Settings --> All Settings --> Polling Engines und verifiziere die APE:

Die APE lebt und ist verbunden aber langweilt sich. Das ändere ich nun.

Manage Nodes

 

Suche mir irgendeine Node und klicke auf More Actions / Change Polling Engine

Wähle aus:

Ich kann links nach Polling Engine gruppieren:

Natürlich kann ich das auch im Bulk ändern mit mehreren Nodes gleichzeitig, ebenso geht das direkt in der Datenbank bei NodesData in der Spalte EngineID:

 

Irgendwann nächstes Jahr reden wir mal über die Datenbank. Aber nicht jetzt.

 

Das gleiche Spiel gibt es beim zusätzlichen Webserver.
Zuerst: Warum brauche ich den?
Wir sagen bei 20-25 Benutzern die gleichzeitig auf Orion zugreifen macht es Sinn, AWS einzusetzen um die Last zu verteilen.
Aber!

Ein AWS ist vergleichsweise günstig für einen dreistelligen Listenpreis zu bekommen.
Einige Kunden setzen den auch bei weniger gleichzeitigen Zugriffen ein allein um ein schnelleres Webinterface zu bekommen.

 

Auch dazu etwas Hintergrund:
Auf dem Orion Server hat das Polling höchste Priorität. Alles andere wird hinterhergestellt.
Wenn die Ressourcen knapp werden, muss unter anderem die Web-Performance darunter leiden.

Wenn das GUI outsourced ist, bekomme ich also auch bei kleineren Deployments bessere Performance.

Probiert es einfach einmal aus – der Prozess ist einfach. Tatsächlich genauso wie oben erklärt daher gehe ich nicht erneut durch die Schritte. Passt einfach nur hier auf:

 

 

 

Gut, jetzt gehen wir mal noch einen Schritt weiter.
Wir garantieren offiziell bis zu neun APEs neben dem NPM (oder anderen Modulen), es gibt Deployments da draußen die deutlich höher ausfallen. Sogar in Deutschland
Wenn ein Unternehmen jetzt aber auch darüber hinauswächst? Sagen wir mal 500 000 Interfaces?

Dann arbeiten wir mit individuellen Instanzen.

 

Hier bekommt jede Region ein eigenes Orion zum Spielen. Mit allen notwendigen Modulen und jeweils einer eigenen Datenbank.

Das System hat viele Vorteile, so kann man z.B. unterschiedliche Lizenzgrößen in Europa und den USA nutzen, auch unterschiedliche Module.
Man hat in den jeweiligen Regionen den vollen Zugriff auf sein eigenes Zeugs und es kann mir relativ egal sein, was an anderer Stelle vor sich geht.
Ebenso kann ich so ein Setup auch als Art von active/active sehen und einige extrem kritische Nodes von zwei Standorten aus überwachen, falls mal irgendwo ein Totalausfall ist.
Last but not least – manchmal gibt es schwierige politische Situationen in einer global agierenden Firma und hier kann ein System mit individuellen Instanzen einfach Brennpunkte aus Diskussionen nehmen. Jeder überwacht halt sein eigenes Zeugs!

 

Aber, auch bei getrennten Instanzen möchte ich sicher irgendwie mit der Gesamtsituation unzufrieden die Gesamtsituation im Überblick halten. Wie geht das?

Dazu gibt es die EOC!

 

Vereinfacht gesagt, ist die EOC das virtuelle Gegenstück zu einer Kontrollwand bei der NASA wie ihr das aus vielen Filmen kennt. Ja genau, die gleichen Filme mit als Raumschiffen getarnten Bügeleisen.

Früher hat die EOC auch tatsächlich so ausgesehen, hat aber vor etwa einem halben Jahr ein neues Kleidchen bekommen und sieht jetzt wie ein modernes Orion System aus.

Verschiedene Orion Instanzen sitzen irgendwo und werden zu einer gemeinsamen EOC verbunden, wo dann die Daten bzw Störungen zusammenfließen.

Die Software wird irgendwo auf einer VM abgelegt und benötigt eine eigene Datenbank. Installiert wird es wieder sehr einfach – hier nur ein Bild:

Dann der Config Wizard, den haben wir auch schon des Öfteren gesehen, aber eine Einstellung ist wichtig:

Legt eine neue DB an. Auch wenn es angeboten wird, nutzt nicht die Orion DB.
Nochmal.
Legt eine neue DB an.

 

Das kann gerne in der gleichen Instanz wie ein Orion sein, aber erspart euch den Ärger und mischt es nicht in die gleichen DB.

Nach Installation und Login erscheint dieses Element:

 

 

Ich verbinde mein Orion:

 

Ich kann der Instanz einen netten Namen geben oder vielleicht einen speziellen Benutzer anlegen:

 

Das war es:

 

Viel gibt es hier allerdings nicht zu tun.

Irgendwo läuft etwas nicht wie gewünscht zeigt die EOC es an, ihr klickt drauf und landet dann bei der entsprechenden Orion Instanz.

Weitere Informationen gibt es hier:

https://support.solarwinds.com/Success_Center/Enterprise_Operations_Console_(EOC)

 

Okay, wie so üblich gibt es ein paar Themen auf die ich nicht eingegangen bin!
Bei den APEs gibt es z.B. auch „stackable“ Poller, also „stapelbar“ was nichts anderes heisst, dass ich einen Zusatzpoller auf die gleiche VM wie das Orion selbst werfen kann.
Ganz vorsichtig ausgedrückt ist das suboptimal, da zum einen nicht jedes Modul stacked Poller unterstützt, und ich so zum anderen weder Loadbalancing noch Regionen auseinanderziehen kann.

 

Ein großes Thema auf das ich hier nicht eingegangen bin ist die Ausfallsicherheit/Hochverfügbarkeit. Das allerdings hebe ich mir für einen neuen Blogpost nächstes Jahr auf!

 

Bis dahin wünsche ich euch frohe Weihnachten usw usw.

Ich schreibe dies gerade während eines weiteren Aufenthaltes in unserem Büro in London und Secret Santa hat gerade stattgefunden (auf Deutsch: Wichteln). Man kennt mich hier zu gut:

 

Geekzeugs, Katzen, Essen…toll! Nur kein Dolce & Gabbana, aber das kommt dann sicher, wenn ich wieder zurück in Cork bin!

Bis dahin macht es gut und entspannt euch!

Tach,

 

Bereit für die nächste und letzte Runde mit unserem Patch Manager?

 

Wir hatten bisher über die Installation und die ersten Schritte gesprochen und sind einmal einen einfachen Patchprozess durchgegangen. Was noch fehlt, ist das Erstellen eines eigenen Paketes.

Leider warte ich seit August auf meinen Schokoriegel! Aus reiner Verzweiflung habe ich neulich einen Schnitzelberg gegessen:

 

Ich hatte ja schon erwähnt, dass wir eine Liste von Updates haben die wir permanent aktuell halten damit ihr es einfach habt.
In der Liste sind weit verbreitete Pakete wie Firefox, Chrome usw usw. Damit kommt man schon ziemlich weit aber, machen wir uns nichts vor, es gibt mehr dort draußen.

Damit der Patch Manager flexibel bleibt gibt es natürlich die Möglichkeit eigene Pakete zu erstellen. Rein theoretisch kann ich die Lösung sogar benutzen um komplett neue Software in meiner Infrastruktur auszurollen.

 

Fangen wir an.
Der erst Schritt ist immer der gleiche: Man benötigt frischen Kaffee. Hört auf zu Lesen. Geht zur Kaffeemaschine. Geht nicht über Los.

 

Danach klickt man in der Konsole auf Administration and Reporting --> Software Publishing --> All Packages (oder auf irgendein Packet), dann ganz rechts auf „New Package“ und ein unschuldiges Fenster erscheint:

 

Schreibt jetzt mal irgendetwas bei „Package Title“ hinein und die Unschuld geht verloren:

 

Hier werden jetzt fehlende Informationen angezeigt die aber zur Weiterverarbeitung benötigt werden.
Füllt das aus wie es passt, hier wurde die Unschuld wiederhergestellt:

 

 

Jetzt wird es interessant. Regeln. Wir lieben Regeln, oder nicht?

 

Wozu brauchen wir die? Eigentlich klar; wir wollen vorab sicherstellen, dass das Paket nicht auf die falschen Maschinen trifft um Probleme zu vermeiden.
Es gibt vier verschiedene Startpunkte:

 

Ich bleibe beim obersten und habe dann eine weitere Auswahl:

 

An dieser Stelle sind die drei ganz oben die interessantesten Optionen, um zwischen 32/64 Bit, Sprachen und OS Versionen zu unterscheiden bevor das Paket überhaupt weiterverarbeitet wird.

Ein Beispiel:

 

Okay weiter geht’s.

Beim nächsten Fenster gibt es dann das vermutlich wichtigste Feature – die Scripting Engine.
Liegt versteckt hinter dem kleinen grünen Icon

 

 

Ich kann hier beliebige Schritte vor und nach dem Starten des Paketes ausführen und verketten.

 

Klickt einfach mal ein wenig herum und macht euch mit den Optionen vertraut, hier wieder das populärste Element:

 

Run a program kann vielleicht cmd.exe starten und irgendwas ausführen mit Schaltern hintendran, oder warum nicht gleich PowerShell mit komplexeren Scripts?
Alles geht!

Protipp: Ich kann leere Pakete erstellen und einfach die cmd.exe starten ohne weiteres, kein Update kein nichts, nur um an die Scriptfunktion an dieser Stelle zu kommen. Ähnlich wie beim SCCM.

 

Gut weiter. MEHR REGELN!!!

 

An dieser Stelle wissen wir bereits, dass das Paket nur auf bestimmte Maschinen trifft.
Vielleicht Windows 10, Deutsch, 64 Bit.

Aber wir müssen jetzt aufpassen. Ein Paket, das mit den bisherigen Informationen auf eine der obigen Maschinen trifft, wird ausgerollt.
Wollen wir das in jedem Fall? Bestimmt nicht!

Wir wollen etwas Bestehendes updaten aber nicht auf jeder Maschine neu installieren. Also suchen wir die Bestätigung, dass eine vorherige Version der Software schon da ist.

Dazu gibt es zwei simple Methoden – ein Check der Registrierung nach einem bestimmten Key, oder, falls das nicht geht, eine Datei irgendwo die sicherlich vorhanden sein muss.
Beides kann man anlegen und bei den Dateiregeln sogar ziemlich granular:

 

Danach kommen nur noch ein paar Zusammenfassungen aber nichts Wildes mehr und die Paketierung ist abgeschlossen.

Das wichtigste jetzt ist testen, testen, testen. Ihr wollte sicher kein Java auf den Domain Controllern ausrollen.

 

Nicht vergessen: Wie auch bei den von uns betreuten Paketen muss das Ding noch an den WSUS weitergeliefert werden, also immer rechtsklick und „publish“

Es gibt noch weitere interessante Themen rund um den Patch Manager, wie vielleicht das Reporting oder auch eventuell das Setup in größeren Umgebungen.

 

Aber im Prinzip ist mit den drei Artikeln zum SPM nun alles gesagt, legt einfach mal los und spielt etwas herum.
Wenn es Fragen gibt wisst ihr ja, wie und wo ich zu erreichen bin. Ein Snickers hilft dabei meine Antwortzeit zu minimieren!

saschg

DPA Erste Schritte

Posted by saschg Nov 30, 2017

Kaum zu glauben – es ist schon ein Jahr her, dass ich etwas über Datenbanken geschrieben habe:
https://thwack.solarwinds.com/groups/thwack-emea/blog/2016/11/30/immer-diese-datenbanken

Vor ein paar Monaten bin ich auf den SAM eingegangen und heute bekommt der DPA seinen grossen Auftritt.

 

DPA misst die Zeit die ein Query innerhalb der Datenbank verbringt und zeigt, wo die meiste Zeit aufgebracht wird. Das funktioniert ohne Agent und ohne Änderungen an der Datenbank.
Die Software ist getrennt von Orion, integriert sich aber gerne in eine bestehende Umgebung.
Fangen wir bei Null an. Wobei, ich schreibe das gerade aus unserem Buero in London und hier ist es furchtbar kalt, fast schon unter Null!

 

Die Installation ist denkbar einfach:

 

Ein paar Mal auf Next und 90 Sekunden später ist die Sache erledigt. Das folgende Fenster erscheint:

 

Also weiter geht es im Browser eurer Wahl.

Zuerst wird das Repository angelegt. Das ist die DB in der DPA sein eigenes Zeugs ablegt.

 

Kompatibel sind die folgenden Systeme:

 

In den meisten Fällen wird eine SQLExpress vollkommen ausreichen. Es gibt nur eine Regel:
Nehmt nicht die DB die ihr überwachen wollt, da sonst die Ergebnisse nicht realistisch sind.

Ich nehme eine kleine DB die auf meinem Orion Server liegt. Nicht wirklich empfehlenswert aber ich bin ja auch nicht produktiv!

 

Ich lasse mit dem SA Konto einen Benutzer anlegen:

 

Das Erstellen des Repository dauert nur wenige Sekunden und wir klicken auf „Register“.

Jetzt wird die DB eingehängt die wir tatsächlich überwachen wollen.

 

Ich entscheide mich für meine SQL

 

Keine Sorge wegen des SA Kontos hier. Das dient nur zum Erstellen des Benutzers im nächsten Schritt:

 

Mehr zu den erforderlichen Berechtigungen beim SQL hier:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/SQL_Server_permissions_for_DPA_monitoring

Und für Oracle:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/Oracle_permissions_for_DPA_monitoring

 

Alles erledigt! Ein nahezu leeres Dashboard begrüßt euch, aber Daten kommen nun hinein:

 

Weil ich aber nicht Tage warten möchte wechsle ich auf ein schon bestehendes System:

 

Schaut mal auf das Element rechts. Eigentlich wollen wir ja immer, dass Trends nach oben gehen. Hier nicht!

Es ist Wartezeit und die soll gefälligst sinken. Also schalte ich auf „trending down“

 

Was heisst das jetzt? Nichts Gutes! Die Wartezeit ging leider hoch.

 

Schauen wir einmal warum.

Unten ist meine SQL Instanz und wir sehen schon, dass irgendwo ein Problem mit einem Query vorliegt:

 

Ich klicke auf die Instanz.

Das erste was ich sehe ist die Gesamtwartezeit innerhalb der letzten 30 Tage

 

Ich sehe auch direkt, dass meine Baseline bei etwa 22 Minuten am Tag liegt, irgendetwas muss am 08.11. passiert sein, und die Wartezeit wird hauptsächlich durch ein einziges Query erzeugt.

Ich bin jetzt echt interessiert am 08.11. Was war da los? Eine kurze Googlesuche sagt mit, dass Gordon Ramsey am 08.11. geboren wurde, aber 1966 und nicht 2017. Das kann es also nicht sein.

 

Nagut, dann klicken wir mal auf den Tag.

 

50 Sekunden Wartezeit pro Stunde mit der Ausnahme von den zwei Stunden zwischen 0800-100. Es wird immer unheimlicher. Es kann nur ein SQL-Poltergeist sein.

Ich klicke auf 0800. Nur ein Query hat hier wirklich etwas getan. Wir sehen auch schon anhand der Farbe und der Legende rechts, wofür in etwa die Zeit aufgebraucht wurde

 

Ich bin mal mutig und klicke auf das Query.

 

Wir sehen oben 482 Ausführungen innerhalb der Stunde und es war eine reine lesende Abfrage.

Ich kann dem Query oben einen Namen geben „name SQL“, rechts habe ich zwei Knöpfe für weitere Informationen mit historischen Daten und zusätzlichen Statistiken.

 

In meinem Fall steht hier nicht sehr viel – aber das ist auch klar. Ist ein neues Query verursacht von einem Report, den es vorher noch nicht gab.
Wenn ich nur wüsste, was ich da versucht habe!

 

Was auch immer. Wo wir gerade hier sind, schauen wir einmal nach oben.

 

Ich kann hier vom Query zurück navigieren auf den ganzen Tag.

Dort angekommen kann ich hier die Stunde erneut auswählen:

 

Aber jetzt passt mal auf.

Links ist ein Button für „Timeslice“ und nach Klicken dort kann ich einen granularen Intervall einstellen:

 

Unten sehe ich dann die Stunde unterteilt in 10 Minuten:

 

Klickt mal auf einen Block. Dann wieder auf Intervall:

 

Jetzt kann ich mir das ziemlich genau anschauen. Schade, dass das so versteckt ist!

 

 

Wenn ich aber nicht gezielt nach einem Problem suche, sondern einfach nur mal schauen möchte was mein SQL gerade so macht (und warum er gefühlt eine Million GB Ram braucht), nutze ich die Navigation oben und gehe zurück auf den ganzen Tag:

 

Jetzt klicke ich auf einen der anderen Buttons – wie wäre es mit dem hier:

 

 

Rechts sehe ich gut aufgelöst die Programme/DLL die auf die DB zugreifen:

 

Klickt bei der Gelegenheit klickt einfach mal auf die anderen Knöpfchen. Bei einer Produktivumgebung ist der Punkt DB User meist recht interessant – da sieht man vielleicht sogar, wer wirklich arbeitet

Scrollt mal etwas herunter da sind vier weitere Reiter. Nein, nicht die apokalyptischen. Okay der letzte vielleicht:

 

Klickt wieder etwas herum.
Wenn bei euch, so wie bei mir, gerade keine Deadlocks sind guckt einfach hier nach weiteren Details:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/Deadlock_analysis_in_DPA

 

Oben sind noch mehr Knöpfe. Es kann nie genug Knöpfe geben.

 

Wenn man auf Resources klickt gibt es ein paar Standardkennzahlen, die mit dem Umweg SQL über WMI aus der Maschine herausgezogen werden. Die Elemente hier sind selbsterklärend und ich verliere nicht viel Worte. Schaut euch um.

 

Aber nicht zu viel! Es gibt noch mehr zu sehen!

Ziemlich weit oben ist ein Knopf bei mir der bei euch vielleicht noch nicht ist:

 

Beim DPA gibt es ein optionales Paket mit dem Namen „VM Option“, das getrennt lizensiert werden muss. Ich kann mir hier mein vCenter oder meinen ESX direkt einpflegen.

Dazu gehe ich zuerst in die Options und dann „Register…“

 

Es werden readonly Berechtigungen benötigt daher es sollte kein Problem sein, diese von eurem freundlichen VM Admin zu bekommen.
Das vCenter wird scanned und nach einigen Sekunden sollte in der Übersicht der Instanzen rechts ein kleines Icon erscheinen:

 

Wenn ich jetzt also ganz oben auf Virtualization drücke sehe ich zuerst unten in der Übersicht etwas andere Info

 

Spannend wird es jetzt, wenn ich auf die Instanz klicke und alles etwas anders aussieht:

 

Wenn ich auf einen der Pfeile klicke erscheint ein Popup:

 

Ich sehe nun also Events aus der virtuellen Umgebung. Das ist stellenweise mehr als nur nett, weil es mir Dinge erklären kann die ohne diese Informationen so viel Sinn ergeben wie Grünkohl.

Ganz oben der Reiter VM Config:

 

Darunter mehr Knöpfe:

 

Wir sehen mit welchem Host wird es zu tun haben, welche anderen VMs dort sind und wie diese priorisiert sind.
Dazu fällt mir eine Anekdote ein – ich hatte irgendwann mal eine DPA Demonstration mit einem IT Manager der an dieser Stelle sagte „Das sind Informationen die ich meinem DBA niemals geben würde. Danach kündigt der mir noch!“

 

Wir sind fast durch. Folgt ihr mir noch? – Gut!

Ganz oben haben wir noch Buttons:

 

Bisher waren wir auf HOME, klicken wir kurz auf REPORTS

Nach Auswahl der Instanz gibt es ein paar vordefinierte Berichte

 

Unter Report Options kann ich das Ding noch etwas anpassen, unter anderem mit meinen eigenen Statements:

 

 

Das gleiche bei den ALERTS. Hier erlaubt mir „custom“ meine eigenen Statements:

 

Aber ihr seht schon, Berichte und Alarme sind hier eher rudimentär wenn man es mit Orion vergleicht.

Bei den OPTIONS finden wir Grundeinstellungen, können SMTP und AD zufügen sowie andere administrative Aufgaben erledigen.

 

Unter THWACK findet sich wieder etwas Interessantes:

 

Das bringt euch zu benutzerdefinierten Berichten. Diese laufen nicht innerhalb von DPA!
Die Berichte dort werden gegen das Repository gesetzt um spezielle Informationen herauszuziehen. Dazu nutzen wir dann das Management Studio.

 

Jetzt klicken wir auf LOGOUT und verlassen DPA und gehen zu Orion.

Dort unter Settings --> Product specific Settings finden wir Database Performance Analyzer

 

Nach dem Verknüpfen werden automatisch Abhängigkeiten gesucht für den Fall, dass ich Anwendungen überwache die auf meine DB zugreifen.
Das Resultat sieht dann so aus:

 

DPA bringt also seine Informationen in die Orion Plattform. Das ist interessant auf mehreren Ebenen, z.B. im Zusammenspielt mit AppInsight, aber natürlich auch dem Appstack

 

 

Noch recht neu ist die Integration in den Perfstack

 

Das ist schon heiss, oder nicht?
Hier in London ist es immer noch kalt aber das Problem beseitige ich jetzt mit einem Kaffee!

Ich arbeite ja in so einer komischen Position als Techniker im Vertrieb.
Das Problem mit der Rolle liegt darin, dass du zwei verschiedene Persönlichkeiten haben musst; die eines Vertrieblers (extrovertiert, schnell handeln) und die eines Technikers (introvertiert, überlegt handeln).

Erst meine multiplen Persönlichkeiten erlauben mir also in meinem Job zu funktionieren. Macht mir das mal nach.

 

Eine Frage bei der sich die Interessengebiete von Vertrieb und Technik häufig Überschneiden ist die nach der Lizensierung der Solarwinds-Produkte.

Hierzu muss man natürlich bedenken, dass jedes Produkt anders lizensiert wird weil man zum Beispiel in der Virtualisierung mit anderen Kennzahlen zu tun hat als in einem Netzwerk.

Schauen wir uns einmal die Produkte einzeln an.

 

NPM

 

Das Schwierigste zuerst.
Offiziell wird NPM lizensiert nach der höchsten Anzahl von Elementen einer Kategorie.
Elemente wären Ports/Interfaces, Nodes, Volumes. Die höchste Anzahl davon ergibt dann die Lizenz, und es gibt verschiedene Stufen.
Das versteht kein Mensch und keine Katze!

 

Also ein Beispiel:
Wir haben einen Switch, einen Router und einen Server.

Node    Interface             Volume

1             48                           0             --> Switch

1             2                             0             --> Router

1             2                             4             --> Server

 

Macht 3 Nodes, 52 Interfaces, 4 Volumes, also zusammen 59, hier ist der Beweis:

 

Aber nur die höchste Anzahl in einer Kategorie zählt! Das sind in 99% aller Fälle die Interfaces und in diesem Fall 52. Ich kann demnach 51 Geräte und insgesamt 51 Volumes haben – spielt keine Rolle solange die Zahl kleiner ist als 52.
Natürlich kann ich von den 52 Ports noch entscheiden, welche mir wichtig genug zum überwachen sind.

Eventuell noch Bedenken, dass virtuelle Interfaces auch mitgezählt werden, vielleicht ein VLAN, wenn ich es auch monitoren möchte.

NPM ist verfügbar in verschiedenen Größe, von „bis zu 100 Elementen“ bis zu „theoretisch unlimitiert“.

 

Verstanden?
Der hier schon und hat sich wieder hingelegt. Er heisst übrigens Palpatine wie der Imperator in Star Wars.

 

 

NTA

 

NTA ist simpel – es wird immer an die vorhandene NPM Lizenz gekoppelt.
Der technische Grund ist der, dass NPM den Interface-Index liefert den NTA braucht, um Flows zuzuordnen.
In manchen Situationen ist das zugegebenermaßen nicht optimal, vielleicht bei einer riesigen NPM Lizenz aber nur einer Handvoll Flowexportern, aber andererseits ist uns die Menge an generierten Flows vollkommen egal.

Ein einzelnes Abfragemodul kommt spielen mit 50000 flows pro Sekunde klar.
Also, ein NPM 2000 benötigt ein NTA 2000.

 

NCM

 

Ebenfalls einfach – jedes Gerät, mit dessen Konfiguration hantiert wird, konsumiert eine Lizenz.
30 Switches --> NCM 30.

 

IPAM

 

Hier reden wir von „managed IP“ die lizensiert werden müssen.
Beim IPAM gibt es vier verschiedene States:

 

Available wird nicht lizensiert, die drei anderen schon.
Rechenbeispiel: Ich habe ein /24 aber nur noch knapp 200 Adressen sind frei, also muss ich nur die 50 lizensieren.
Die Anzahl an DHCP und DNS Servern sind uninteressant.

UDT

 

Hier werden einfach alle Switchports in einen Topf geworfen. 10 x 24 sind ungefähr 240! Ich bin mir fast sicher!

 

VNQM

 

Okay jetzt müssen wir uns wieder konzentrieren.
VNQM wird über zwei verschiedene Datensätze lizensiert: IP Telefone und IP SLA Quellen.
Telefone sind klar, bei IP SLA sollte man sich mit der Technologie auseinandersetzen – das kann man hier.
Es werden nur die Quellen lizensiert, nicht die Beantworter. Wenn eine distributed operation genutzt wird, können dort unter Umständen mehrere Quellen definiert sein.

Hier gilt wieder die höchste Anzahl einer der beiden Datensätze. VNQM startet mit 5/300, wenn ich also 6 IP SLA Quellen habe, aber nur 200 Telefone, muss ich trotzdem in die höhere Lizenzstufe die bis 25/1500 ausreicht.

 

Der Kollege hier hängt grad irgendwie und muss sich das noch mal durchlesen. Er heisst übrigens Chewbacca wie…ach, den kennt ihr.

 

VMAN

 

Etwas Einfaches zwischendurch – die Virtualization Manager wird über die Gesamtanzahl der physischen CPU in allen Hosts lizensiert, also wie das vCenter.
Cores spielen keine Rolle.

 

SRM

 

Bei Storage ist es auch einfach, hier wird nach Disks lizensiert. Also alles was von euren Arrays als Disk gesehen wird, ob das jetzt rotiert oder virtuell ist. Hier auch einfach die Gesamtanzahl nehmen.

 

SAM

 

Server & Application Monitor funktioniert wie der NPM, mit dem Unterschied, dass wir statt Interfaces jetzt auf „monitored component“ schauen. Die anderen Elemente sind dann wieder die Nodes, und die Volumes.
Aber die Komponenten sind hier normalerweise ausschlaggebend und wären z.B. Dienste, Prozesse, irgendwelche PerfMon-Daten usw.
Beispiel: Die Vorlage um einen DC zu überwachen hat 32 Komponenten, bei einem Apache sind es gerade mal 7.
Bitte behaltet im Hinterkopf, dass die Vorlagen jederzeit angepasst werden können mit der Ausnahme der AppInsights (SQL/Echange/IIS), aber die sind ja ohnehin ein Sonderangebot.

 

SPM

 

Der Patch Manager lizensiert sich total langweilig über die Anzahl an Systemen die patched werden. Dabei spielt es keine Rolle ob das Server oder Workstations sind, und auch die Anzahl der eingesetzten Patch Manager Instanzen bzw Rollen ist unerheblich.
Es ist auch gleich ob dahinter ein WSUS oder SCCM steht.

WPM

 

Okay das ist manchmal eine Herausforderung. Der Web Performance Monitor erlaubt es, Schritte innerhalb des Browsers aufzunehmen um detaillierte Funktionen einer Webanwendung zu testen. Diese Tests können dann von beliebigen Standorten oder auch der Cloud ausgeführt werden.
Lizensiert wird er über das Produkt von Aufnahmen und Standorten, die diese Aufnahmen wiedergeben. Wir nennen die Summe Transaktionen.

 

Beispiel:
Ich habe einen Webshop und einen Exchange mit OWA. Den Webshop teste ich von meiner Zentrale in Deutschland und meiner Zweigstelle in Wien, sowie aus der Cloud.
OWA teste ich nur von meiner Zentrale aus.
Also 4 Transaktionen insgesamt.

 

WHD

 

Die Anzahl an Technikern, die innerhalb von WHD registriert sind, definieren die Lizenz. Also vielleicht: 5 Mitarbeiter in der IT die an Tickets arbeiten, alle 5 werden dann innerhalb von WHD lizensiert.

Langweilig!

 

LEM

 

Beim Log & Event Manager spielen die eindeutig identifizierten Log-Quellen eine Rolle. Ob von einer IP jetzt verschiedene Logs kommen ist egal, es kann also ein Windows Server gleichzeitig einen Webserver betreiben und die Daten von irgendeinem Endpoint-Security System liefern.
Aber aufgepasst: Es gibt eine Lizenzstufe für Server und Netzwerkkomponenten, und darüber hinaus ein Addon für Workstations welches günstiger ist. Klar, ich habe ja meistens auch ein oder zwei Workstations mehr als Server!

 

DPA

 

Eigentlich ist die Lizensierung ganz einfach…pro DB Instanz, in den meisten Fällen also pro Server. Es kommt recht selten vor, dass ich zwei Instanzen auf der gleichen VM laufen habe, aber in dem Fall müssen dann beide getrennt lizensiert werden.
Aber! Wir unterscheiden hier nach DB System in zwei Kategorien.
Die günstigere ist Cat2 und passt für alle MSFT SQL, MySQL und alle Oracles bis auf EE.
Die Cat1 erlaubt Oracle EE, DB2 und Sybase

 

Cat2 auf dem Bild oben, Cat1 unten ist nicht wirklich eine Cat, aber weiss das nicht.

Ich habe einige Produkte ausgelassen deren Lizensierung aber extrem einfach ist.

Von daher noch ein paar weitere Dinge!

 

Jedes Produkt ist in verschiedenen Stufen erhältlich und bei den meisten gibt es am oberen Ende der Fahnenstange eine Version die üblicherweise auf *LX endet, z.B. NPM SLX, und die wir als theoretisch unlimitiert bezeichnen.
Theoretisch heißt, dass es in der Praxis eine technische Limitierung gibt und die tritt dann ein, wenn das Abfragemodul (Poller) überfordert ist.
Nehmen wir als Beispiel den NPM, dort sagt das System bei etwa 10000 Interfaces und den Standardintervallen „ich kann nicht mehr“. Man kann dann entweder die Intervalle verlängern um dem System mehr Luft zu geben, oder aber ich skaliere nach oben und setze einen weiteren Poller dazu. Diese zusätzlichen Abfragemodule, wir nennen sie APE (Additional Polling Engine), dienen dem erweitern der Kapazität aber können auch genutzt werden um größere, verzweigte Umgebungen klüger zu überwachen.
Ich werde irgendwann mal darüber bloggen, solange schaut einfach hier in die Originaldoku:

Scalability Engine Guidelines for SolarWinds Orion Products - SolarWinds Worldwide, LLC. Help and Support

 

Wenn ich sehen möchte was zur Zeit in Benutzung ist und was noch frei ist, klicke ich innerhalb von Orion auf Settings --> All Settings --> License Details (ganz runterscrollen):

 

Ebenso, unter Settings --> All Settings --> Polling Engines sehe ich wie beschäftigt mein Abfragemodul ist.
Wenn ich mehrere Poller habe tauchen diese auch an exakt dieser Stelle auf:

 

Die hier sind extrem beschäftigt:

 

Macht’s gut!

Kennt ihr das noch, C&C: Red Alert? Ich musste das Erscheinungsjahr googlen – 1996.

22 Jahre her, darf man gar nicht drüber nachdenken!

 

Reden wir über aktuelle Alerts

Alarme sind bei der Orion Plattform ein sogenanntes „platform feature“, also unabhängig von den tatsächlich verfügbaren Modulen. Zu finden ganz oben unter Alerts.

Dort dann bitte einmal ganz rechts auf „Manage Alerts“:

Auf einem frisch installierten System wird es ungefähr so aussehen:

Und damit fängt das DRAMA dann auch schon an

 

Jedes Solarwinds Modul bringt etliche Standardalarme, wie z.B. sende mir eine Email wenn ein Knoten nicht mehr antwortet, aber auch wenn irgendwo ein Schwellwert überschritten wurde.

Oder aber ein Switchport plötzlich nicht mehr verbunden ist, was vermutlich vollkommen normal gegen 17:02 am Abend ist wenn ich Accessports im System überwache. Glaubt mir, das hat es alles schon gegeben!

 

Das System sendet also einen ganzen Haufen Emails die im Grunde genommen nicht notwendig sind. Was machen wir also naturgemäss? Wir werden entnervt und beginnen Emails zu ignorieren.

Dann geht plötzlich ein Uplink down. Und wir merken es nicht, weil unser Monitoringsystem mich zugespamt hat.

 

Daher mein erster Vorschlag, und das ist vermutlich die Beste Idee die ihr heute liest:
Schaltet erst einmal alle Alarme aus.

 

Dazu sortieren wir oben nach „Enabled“ und klicken, dass ON oben steht. Alle markieren und „disable“ – erledigt. Ruhe im Haus. Enjoy the Silence ist übrigens von 1990 und damit noch älter als Red Alert.

 

Im Prinzip kann ich jetzt einen beliebigen Alarm anpassen. Passt jedoch bitte auf – bei einem out-of-the-box Alarm würde ich nur an einer Kopie arbeiten und nicht am Original. Dazu gibt es oben den Schalter „Duplicate & edit“.

Aber ich führe einmal durch den Prozess, einen Alarm komplett selbst zu erstellen, also oben auf „add new alert“.

Zuerst brauchen wir einen Namen, und vielleicht auch eine Beschreibung, wenn der Alarm komplexer ist.

Unten sind ein paar Einstellungen:

Die Zeit ist unter Umständen ganz interessant.
Hier wird nichts anderes getan, als alle 60 Sekunden zu überprüfen ob die Bedingung die gleich kommt eingetreten ist.

Zuerst denkt man sicherlich „Oh das möchte ich alle 10 Sekunden haben“ – aber das bringt nicht wirklich viel.

 

Bedenkt bitte, dass jede Überprüfung der Bedingungen CPU Zyklen kostet und ich grundsätzlich defensiv mit Ressourcen umgehen würde.
Dann: Die Daten, auf denen die Bedingung aufgebaut ist werden ja abgerufen. Dieser Vorgang geschieht alle x-Minuten je nachdem, was ihr eingestellt habt. Basis wäre alle 10 Minuten.

 

Macht es jetzt Sinn, alle paar Sekunden nach einer Situationsänderung zu schauen, wenn die zugrunde liegenden Daten eh nur alle 10 Minuten aktualisiert werden?
Bedingt.

 

Letzten Endes ist das ein dynamisches Konstrukt. Ich würde vermutlich Alarme gruppieren und wirklich kritische Dinge zeitnaher laufen lassen, was ein Kompromiss wäre.

Schaut dazu auch bitte in mein Posting zur Echtzeit.

Dazu empfiehlt sich dann auch die Einstellung „severity“

 

Die untere Position dient dem Erstellen von Limitierungen, welche dann in der Kontenverwaltung weiter definiert werden können. Dazu schreibe ich auch irgendwann einmal etwas, aber gerade lasst mich das einfach erklären mit „Mitarbeiter aus Berlin sieht nur Alarme aus Berlin.“.

 

Okay weiter geht’s mit dem nächsten Fenster – der Bedingung.
Was muss passieren, um meinen Alarm zu aktivieren.

Zuerst teilen wir dem System mit, auf was wir alarmieren möchten

 

Man kann hier ziemlich kreativ werden. Vielleicht möchte ich auf ein bestimmtes Exchange-Konto alarmieren – mein CEO ist gefährlich Nahe an der Obergrenze für Dateianhänge und ich möchte es ihm persönlich mitteilen, bevor die Automatik zuschlägt? Oder ich habe plötzlich eine unbekannte MAC Adresse in meinem Netzwerk?

Aber – ich bleibe bei der Node.

Die nächste Position ist der Umfang des Alarmes.

 

 

Gilt das Ding für alle Nodes in meinem Netz? Oder nur bestimmte?

 

Dann die eigentliche Bedingung. Normalerweise nehme ich ein simples Beispiel wie CPU Load:

Aber schaut einmal hier:

 

Ich bekomme nun Zugriff auf alles, was wir vom Element „node“ sammeln.
Unter Umständen ist das eine ziemlich lange Liste

 

Wir sehen rechts in der Vorschau was für ein Wert zurück geliefert wurde. Der Inhalt dieser Spalte gibt nicht immer Sinn – vielleicht haben wir gerade keine Infos zu den Werten – aber es hilft einzuschätzen, ob die Info hilfreich ist oder nicht.

Weil mir gerade die Kreativität abhanden geht nehme ich einmal den administrativen Kontakt:

 

 

Aber das reicht mir nicht. Ich klicke auf das Plus und kann mir andere Bedingungen danebenlegen:

 

 

Ich nehme eine weitere simple Bedingung – dieses Mal meine freundliche CPU:

 

 

Achtet auf die Zeile in Gelb – da versteckt sich ein logischer Operator!

 

Dann noch ein nettes Spielzeug – die Zeit:

Ganz unten dann noch die „advanced options“. Im Grunde genommen erlaubt das weitere, in sich abgeschlossene Bedingungen, die dann gegeneinander laufen:

 

Ein Szenario wäre hier vielleicht:
SQL A (on prem) down, Backup B (on prem) down, Notfall DB bei AWS antwortet auch nicht, in der Vertriebsabteilung klingeln Telefone, es ist noch nicht 17:00, ich habe keinen Urlaub.
Auweia!

Aber das wollen wir hier ja nicht. CPU Load und verantwortlich ist dieser Admin-Typ, das reicht mir. Also klicke ich auf weiter zum nächsten Fenster.

 

Soll sich der Alarm selbst ausschalten? Falls ja, unter welchen Bedingungen?

In den meisten Fällen ist die automatische Einstellung ratsam welche nichts Anderes besagt als „wenn die Bedingung die ich vorhin erstellt habe nicht länger wahr ist“.

Es mag aber auch eine Situation geben, in der ich die manuelle Bestätigung eines Mitarbeiters erwarte, dass alles in Ordnung ist.

Ich klicke auf weiter. Das nächste Fenster ist ganz einfach.

 

 

Gilt der Alarm rund um die Uhr? Unwahrscheinlich.

Ich möchte vielleicht andere Aktionen den Tag über auslösen als Nachts, oder auch meine Schwellwerte sind in der Nacht etwas entspannter als am Tag – oder umgekehrt!

Aber – Faulheit siegt heute und ich bleibe bei „always enabled“ und klicke auf weiter.

Jetzt sehen wir die verfügbaren Aktionen und davon gibt es eine ganze Menge:

 

 

Üblicherweise nehme ich das hier

 

Wenn ich auf meinen blauen Knopf drücke erscheint ein Fenster für weitere Details – hauptsächlich natürlich Empfänger und Inhalt der Email:

 

Vielleicht möchte ich eine Grafik in die Email legen? Bedenkt einfach, dass man sämtliche Charts in Orion in andere Webseiten oder eben Emails exportieren kann.
Oder, für den Fall das eine bestimmte Situation öfter auftritt ist es sinnvoll, Lösungsansätze gleich mit der Email zu senden damit die ausführende Person direkt weiss, was zu tun ist.

Oben im Screenshot sind schon einige Variablen aufgelistet, bei „insert variable“ sieht man eine List der verfügbaren Optionen.


Jetzt reicht mir das aber nicht – ich kann neben der Email direkt noch eine weitere Aktion starten

 

Ich entscheide mich für einen Ton:

 

Und jetzt könnte ich sogar noch eine Eskalationsstufe abbilden:

 

Vielleicht eine SMS?
Das macht ihr, wenn z.B. zuerst eine Email gesendet wurde, kein Mensch reagiert, und ihr dann vielleicht eine andere Email zu einem anderen Empfänger senden möchtet.

Was auch immer! Ich klicke auf weiter.

 

Wir können eine Aktion definieren die beim Zurücksetzen der Bedingung eingeleitet wird.

Noch eine Email? Mehr Spam? Nein Danke. Aber es gibt Situationen wo dies sehr nützlich sein kann.
Vielleicht habe ich ja ein Ticketing System informiert mit einer Email oder einem Syslog. Das System hat ein Ticket eröffnet, eventuell weitere Schritte eingeleitet. Jetzt könnte ich eine weitere Email, Syslog, Trap oder ähnliches Senden um dem System mitzuteilen, dass die Sache erledigt ist.

 

Zum Schluss, in Punkt 7, gibt es eine Zusammenfassung und danach kann ich meinen Alarm aktivieren.

 

So in etwa spielt sich das in den meisten Situation ab – es gibt natürlich noch Themen darüber hinaus wie z.B. dem Erstellen eines Alarms anhand einer ankommenden asynchronen Mitteilung.

Aber ich möchte es heute nicht unnötig verkomplizieren!

Deswegen gibt es jetzt Donuts zur Belohnung:

 

Zu Black Friday habe ich mir den Einstieg in das Philips Hue System gegönnt mit der Bridge, ein paar Leuchtmitteln, Schaltern, Bewegungssensoren und so weiter.
Normale Nutzer stöpseln das alles zusammen und nutzen die App um Szenen zu erstellen. Wir gehen hier einen Schritt weiter.
In meinem Paket war auch eine Hue Go, das ist eine Lampe mit integriertem Akku der angeblich für 3 Stunden hält.
Die ist wie geschaffen für mein Alarmszenario.
Zuerst einmal - wie kommunizieren wir mit Hue?
Die Bridge ist über Rest API steuerbar.
Ich mag die einzelnen vorbereitenden Schritte nicht wiederholen – guckt einfach hier:
https://www.developers.meethue.com/documentation/getting-started
Es wird ein Benutzerkonto auf der Bridge erstellt, wir finden die Lampe, stellen eine Farbe ein – natürlich Rot:https://www.developers.meethue.com/documentation/core-concepts#color_gets_more_complicated
Das Resultat ist eine json Zeile die mit einem put Kommando an die Lampe übergeben wird.
Wie verknüpfe ich das mit Solarwinds?
Leider gibt es von Haus aus noch keine Unterstützung von Rest API in den Alarmaktionen und http get/post reicht mir nicht. Hier kann man upvoten bei Bedarf:
Es gibt jetzt verschiedene Möglichkeiten, so kann ich entweder das SDK nutzen, oder Powershell, oder ganz einfach curl. Tatsächlich wollte ich erst curl nutzen habe dann aber bei meinen Nachforschungen das hier entdeckt:
Zu bequem!
Ich installiere das PS Module wie in der Anleitung beschrieben und folge den ersten Schritten.
Mein Resultat ist zuerst eine red.ps1 – die Details ergeben Sinn wenn ihr die Anleitung oben gelesen habt - ich definiere meine Bridge mit 10.0.0.21 und die Hue Go mit dem Namen "Mobile" sowie mein Konto:
Import-Module-NamePoSHue
$Bridge=[HueBridge]::New('10.0.0.21','aUcswswfnZhqzTQNX2h92mfqsm-7F7IvEf9lAZty')
$Light=[HueLight]::New('Mobile','10.0.0.21','aUcswswfnZhqzTQNX2h92mfqsm-7F7IvEf9lAZty')
$Light.SwitchHueLight("On")
$Light.SetHueLight(150,0,150)
Jetzt brauchen wir einen beliebigen Alarm – ich erstelle mir hier einen der mich warnt wenn meine Internetverbindung zu Hause nicht mehr da ist.
Ich habe www.google.com als externe Node angelegt und pinge alle 10 Sekunden dorthin und nehme das als Indikator, also Node gleich down.
In Schritt 5 nutze ich „externes Program“ als Aktion für eine Kommandozeile.
Okay super. Aber das ist nur die halbe Miete. Wenn sich das Internet jetzt zufällig wieder verfügbar macht wollen wir das auch wissen.
Also brauche ich auch eine Reset-Aktion im Alarm: Die Lampe soll Grün leuchten. 
Syntax:
Import-Module-NamePoSHue
$Bridge=[HueBridge]::New('10.0.0.21','aUcswswfnZhqzTQNX2h92mfqsm-7F7IvEf9lAZty')
$Light=[HueLight]::New('Mobile','10.0.0.21','aUcswswfnZhqzTQNX2h92mfqsm-7F7IvEf9lAZty')
$Light.SwitchHueLight("On")
$Light.SetHueLight(150,25500,150)
Das ist copypasta und ich habe lediglich Rot (0) gegen Grün (25500) eingetauscht.
Jetzt simulieren war mal den Ernstfall. Oh huch und den Staub…habe ich per Photoshop hinein editiert für mehr Realismus!
Und warte…ALARM!
Kabel wieder rein…
Grossartig. Warum jetzt also diese Hue Go Lampe und nicht irgendwas das an der Wand hängt?
Das Ding ist portabel und du kannst es mit dir rumschleppen während du einen Kaffee trinken gehst.
Aber viel besser:
Du stellst es einem Kollegen auf den Schreibtisch während du den Kaffee trinkst und sagst einfach "Du bist dran"!
Ich glaube genau dafür wurde das Ding erfunden.

 

 

Jetzt möchte ich aber auch eine SMS erhalten. Dazu gibt es verschiedene Optionen, eine kommt hier!

 

Auf einer Messe in Paris habe ich Mitarbeiter von SMSEagle™ kennengelernt die mir mitgeteilt haben, dass deren System schon mit der Orion Plattform verbunden und getestet wurde.

Das hat mich neugierig gemacht und man hat mir freundlicherweise ein Testkonto zur Verfügung gestellt.

 

SMSEagle ist im Prinzip ein Stück Hardware welches über ein Webinterface bedient wird. Strom drauf, LAN Kabel links, SIM Karte rechts rein und fertig.

 

 

Bei der Integration in unser Alarmsystem ist dann natürlich http-get die bequemste Lösung und ich muss mich nicht gross mit irgendwelchen API beschäftigen, tatsächlich muss ich nur die Syntax kennen.

Also!

Mein Alarm – Position 5 – Action!

 

Die SMSEagle Syntax ist echt einfach, URL, Name, Password, Telefonnummer und Inhalt:

http://url-of-smseagle/index.php/http_api/send_sms?login=name&pass=passwort&to=00491234567&message=die+welt+geht+unter

 

Bei mir also:

 

 

Ich teste:

 

Ein paar Sekunden später habe ich die SMS auf meinem Telefon, auch international.

Stressfrei und einfach!

 

Habt ihr auch ein paar Ideen zu Alarmen?

Hallo zusammen,

 

Ich bin im Stress. Dieser Herbst hat es in sich. Aber mal langsam und von vorne.

 

Anfang September war ich im Frankfurter Stadion auf der Hausmesse eines unserer Distributoren.

Ich glaube ich hatte schon einmal erwähnt, dass ich aus dem Ruhrgebiet komme. Da ist die Chance sehr hoch Fan von einem von zwei bekannten Fußball Teams zu sein. Spielt keine Rolle von welchem, Frankfurt ist definitiv... naja schwarz-rot ist nicht mein Ding

Es war ganz nett sich einmal mit ein paar Unternehmen zu unterhalten die ich sonst nur in der "all nodes" Liste von Kunden in Deutschland sehe. Lancom hat mir eine virtuelle Version deren Routers versprochen, mein Plan ist, das Ding einmal in Betrieb zu nehmen und ein paar Poller in thwack zu setzen. Ebenso Datacore.

 

Auf dem Rückweg hatte mein Flieger nach Amsterdam zwei Stunden Verspätung und ich habe den Anschluss nach Cork verpasst. Ein Hoch auf KLM die mich auf deren Kosten in einem 5 Sterne Hotel untergebracht haben. Ich bin am Samstagmorgen zu Hause angekommen, Sonntagmorgen ging es dann nach Barcelona auf die VMworld!

Hier ein Bild vom Stand am Tag bevor es los ging. Links, noch verpackt, sind 1000 T-Shirts:

 

vmworld booth

 

Ich war dort zum ersten Mal und bin quasi von Restaurant zu Restaurant gestolpert. Das gibt schon tolle Sachen dort:

 

steak

 

Am letzten Tag der Messe, mit zwei Tagen Verspätung, haben wir endlich die neuen Versionen von NPM, VMan (lustig: meine Autokorrektur macht daraus Vanessa), NTA und NCM released aber wir konnten sie trotzdem nicht zeigen weil unsere Onlinedemo ein Problem hatte. So ein Pech!

 

Kurz zusammen gefasst ist jetzt neu:

Voller ASA Support in NPM NTA NCM, es werden automatisch Tunnel überwacht, wir verstehen Multicontexts und können Regeln einlesen sowie die Firmware flashen.

Ebenso hat die Orion Plattform neue Spielzeuge bekommen und unterstützt jetzt HA in getrennten Standorten, sowie eine neue EOC Version. Diese beiden Themen werde ich bei Gelegenheit mal genauer beschreiben.

 

Hier Links zu den einzelnen Posts mit weiteren Information:

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2017/09/26/network-configuration-manager-77-is-now-generally-available

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2017/09/25/virtualization-manager-80-is-now-generally-available#start=25

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2017/09/19/npm-122-now-generally-available#start=25

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2017/09/15/what-is-the-enterprise-operations-console-eoc-how-does-it-work-20

 

OK, dann komme ich also zurück nach Cork und was passiert - ich werde krank.

Es zwickt in der Nase und ich befürchte das schlimmste: die Männergrippe!

Die Überlebenschancen sind gegen Null.

Der Doktor sagt "it is just a chest infection" aber ich glaube ihm kein Wort. Und überhaupt, übersetzt das mal "Brustinfektion"? Alter Falter, da liege ich also im Sterben und mir fällt ein, dass in der Folgewoche Urlaub ansteht.

Also unternehme ich die größten Anstrengungen wieder gesund zu werden und bewege mich vom Bett maximal zur Couch. Hat auch halbwegs geklappt!

 

Dann Urlaub.

Zuerst nach Parma.

Richtig, da kommt Parmesan her, und Prosciutto di Parma, und angeblich wurden auch Tortellini hier erfunden.

Ich kann definitiv bestätigen, dass Parmesan hier ein großes Ding ist:

 

parmesan

 

Der Kaffee ist allerdings eher eine kleine Angelegenheit:

 

Dann ging es nach Milan. Die Stadt macht depressiv.

Du läufst an Schaufenstern vorbei und weißt, dass die Kleidung darin etwa ein Monatsgehalt kostet.

Am Abend sitzen wir mit Freunden meiner Partnerin zusammen und ich verstehe kein Wort. Nein das ist nicht richtig, wenn die über Essen reden verstehe ich zumindest den Inhalt des Gesprächs!

Also nutze ich die Zeit und fange an diesen Post zu schreiben.

Morgen geht es nach Sizilien. Sonne. Sonne. Sonne.

Weniger als 24 Stunden nach meiner Rückkehr werde ich wieder im Flieger sitzen um mit Solarwinds an einem Nato Event teilzunehmen. In Belgien!

Das Event heisst NIAS, aber mein interner Spitzname dafür lautet Waffen und Waffeln.

Irgendwelche Tipps für Brüssel?

 

Die Woche danach, Ende Oktober, bin ich in London.

Fish'n'chips incoming!

 

Und dann? Dann bin ich tatsächlich ein paar Tage zu Hause.

 

Aber nicht lang. 10. November steht Berlin an. Details hier.

 

Was machen wir da? Solarwinds kommt mit einigen Produktmanagern, u.A. vom Server and Application Monitor, und einem unserer Headgeeks, Patrick Hubbard. Wir stellen die Neuigkeiten vor, erklären Situationen wo und wie unsere Software sinnvoll eingesetzt werden kann und stehen für sämtliche Fragen zur Verfügung.

Das Ganze ist vollkommen kostenlos! Oh und es gibt Essen

Wenn ihr in der Gegend seid kommt einfach mal vorbei. Das ist wirklich eine gute Gelegenheit.

 

Und dann, wenn das alles vorüber ist, setze ich mich mit einem netten Glas Rotwein auf meinen Balkon.

Ach Moment dann ist es schon kalt draussen. Wird also vermutlich eher ein Glas Jameson!

 

Gute Nacht!

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.

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.