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!

graeme.brown

Seasonal changes

Posted by graeme.brown Nov 14, 2017

Winter is coming slowly but surely. today was chilly and breezy. Making it perfect for hot chocolate and fuzzy sweaters.

Good morning all from Indiana,

 

*STOP AND READ* - If you aren't a database or data focused professional, the below may be boring!

 

I recently attended my first PASS Summit this past week and got to meet so many special people with all different types of skills and experience. With almost 4000 data professionals and 50+ vendors joining the conference, it was almost overwhelming trying to meet as many people and vendors as a single person possibly could. Its almost surprising to me how nice everyone is and how each data professional is willing to meet you, hear your story and help with any issues you might have. #SQLFamily is truly a thing and if you're lucky enough, you'll be apart of it! I'll need to create my twitter to join the family! Attending the pre-conference sessions is definitely worth its wait in gold! Itzik Ben-Gan and David Klee have such a deep understanding of SQL and VMware its such an amazing experience to learn and hear their point of views.

 

For you thwacksters..........I almost got the chance to play the "SysADMANIA" game, below is a picture of the gameboard, but I didnt get the chance since i went off and played Stratego when a game was going on. The SysADMANIA board game looked really fun, below is a picture of BRAD causing issues

 

 

SysADMANIA

 

All in all, PASS Summit 2017 was an amazing experience and I STRONGLY recommend anyone to attend. I met many other data professional and i hope to keep in touch not only to network, but to learn as much as possible!

 

Please leave any comments if you were there as well! I'td be great to talk to others and learn more!

 

-Alex Trepes

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?

Storage Settings

While creating the partitions we must specify either of the below storage settings.
a) ROLAP (Related OLAP): In this case data and aggregations store under relational sources.
b) MOLAP (Multidimensional OLAP): Here data and aggregations store under multidimensional sources.
c) HOLAP (Hybrid OLAP): Here the data stores under relational sources and aggregations store under multidimensional sources.
       

Standard Partition Storage Settings:

Proactive Caching

The feature helps the cube in a sink with the relational data sources.
–> It takes the latency time, schedule time and event table to capture the changes from relational data sources cube databases.
As noted, with MOLAP and HOLAP storage modes, SSAS caches data (MOLAP storage mode only) and aggregations (both MOLAP and HOLAP) on the server.
When you take a data “snapshot” by processing a cube, the data becomes outdated until you process the cube again. The amount of OLAP data latency that is acceptable will depend on your business requirements.
In some cases, your end users might require up-to-date or even real-time Information.
will depend on your business requirements.
In some cases, your end users might require up-to-date or even real-time Information.
A New feature of SSAS 2005, PROACTIVE CACHING, can help you solve data Latency Problems

TIPS FOR EXAMS

Proactive caching is especially useful when the relational database is transaction oriented and data changes at random
when data changes are predictable
Step 1:

  • Such as when you use an extract, transform, and load (etl) proces to load data
  • Consider processing the cube explicitly. When the data source is transaction oriented and you want minimum latency, consider conficuring the cube to process automatically by using proactive caching

HOW PROACTIVE CACHING WORKS

When you enable PROACTIVE CACHING, the server can listen for data change notifications and can update dimensions and measures dynamically in an “AUTOPILOT” mode.

STEADY STATE: In steady mode, no changes are happening to the relational data.

Step 1: Client applications submit multi-dimension expressions(MDX) queries to the cube, pls check in diagram before page.
Step 2: The cube satisfies the Queries from a MOLAP cache. The server listens for a data change notification event, which could be one of the following three types
SQL SERVER: This option uses the Microsoft server trace events that the relational engine raises when data is changed (SQL Server 2000 and later)
CLIENT INITIATED: In this case, a client application notifies SSAS when it changes data by sending a Notify table change XML
For Analysis (XMLA) command
SCHEDULED POLLING: Ninth this option, the server periodically polls the required tables for changes.
UNSTEADY STATE
STEP 4: At some point, a data change occurs in the data source as shown in figure
STEP 5: This change triggers a notification event to SSAS server.
STEP 6: The server starts two stopwatches. The silence Interval stopwatch measures the time elapsed between two consecutive data change events. This will reduce the number of false starts for building the new cache until the database is quiet again.

FOR EXAMPLE

If data changes are occurring in batches, you do not want to start rebuilding the cache with each data change event.
Instead, you can optimize proactive caching by defining a silence interval that allows a predefined amount of time for the batch changes to complete.
After data in the relational database is changed, the server knows that the MOLAP  cache is out of date and starts building a new version of the cache
STEP 6: The latency stopwatch specifies the maximum latency period of the MOLAP cache,  the administrator can also predefine the maximum latency period. During the latency period, queries are still answered by the old MOLAP cache.
When the latency period is exceeded, the server discards the old cache. While the new version of the MOLAP cache is being built, the server satisfies client queries from the ROLAP database
Step7: When the new MOLAP cache is ready, the server activates it and redirects client queries to it.
PROACTIVE CACHING enters a steady state again until the next data change event takes place.

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.