Habt ihr Ton? Ah, jetzt ist es da. Okay, also ein bisschen auf die Technik ein. Beschreibe kurz, aus welchen Komponenten sich das System zusammensetzt. Führe dann aus, welche Checks ich halt für das Monitoring von einem Data Warehouse

als sinnvoll erachtet oder im ersten Schritt umgesetzt habe. Dann gibt es eine kurze Live-Demo und am Ende ziehe ich ein Fazit. Genau, über uns. Genau, also wie schon gesagt, ich arbeite bei Cologne Intelligence.

Wir machen verschiedene Dinge, entwickeln Software unter anderem und Apps, machen Strategieberatung und ich arbeite halt im Business Intelligence Umfeld. Gehöre somit zu diesem Punkt BI-Experten.

Und ja, im Zuge dessen, wie kam es dazu, dass ich mich damit beschäftigt habe? Es gab da so ein Schlüsselerlebnis. Wir hatten ETLs gebaut, die liefen auch. Wir hatten eine Datenbank, hatten die irgendwie mal so zurückgesetzt.

Auf einmal liefen die ETLs nicht mehr. Dann haben wir angefangen, an dem einen ETL zu schrauben, weil das dauerte Stunden. Und es funktionierte nicht, es funktionierte nicht und irgendwann habe ich dann gedacht, okay, gut, dann lass mal gucken, vielleicht ist IO kaputt, weil irgendwie das ETL war in Ordnung, der Prozess zu beladen des Data Warehouses. Ja und irgendwann kam ich dann auch mal auf die Idee, auf den Datenbank-Server zu gucken

und auf den ETL-Server und stellte fest, der ETL-Server langweilt sich, der Datenbank-Server schwitzt. War vorher nicht so. Das Ende vom Lied war, es fehlte ein Index auf einer Datenbank. Beim Einfügen in die Tabellen hat er sich halt bei Millionen von Datensätzen totgesucht, wo er denn jetzt das Update machen soll.

Hat uns gut und gerne einen halben Tag gekostet. Ja und war ein bisschen ungünstig. Ich selber bin dann viel unterwegs gewesen, so mit Top, VM Start, IO Start und Konsorten auf der Konsole, weil ich doch recht Linux-affin bin und da ein bisschen was auch Spaß dran habe.

Allerdings, meine Kollegen sind da eher weniger begeistert von. Wenn ich denen sage, mach doch mal, guck mal da, Konsole einloggen, irgendwie draufgehen, aufs System gucken, ja, finden die nicht so cool. Ist denen zu umständlich.

Das andere Problem ist halt, wenn ich mir halt irgendwie so Top und Konsorten angucke, habe ich meistens nur Momentaufnahmen. Ich sehe halt weniger, wie war denn jetzt der Verlauf von dem Ganzen? Was war so in den letzten zehn Minuten vielleicht los? Was war in der, wenn es dann im Betrieb übergeht, was war im letzten Tag los? Ja, also die konkreten Fragen, die wir uns so während der Entwicklung immer wieder stellen,

sind halt, wie lange läuft so ein ETL-Prozess überhaupt? Welche CPU-Last haben wir? Werden alle vorhandenen Ressourcen genutzt? Oder liegen Ressourcen brach? Also manchmal glauben wir, wir haben ganz toll irgendwas parallelisiert, aber haben wir es gar nicht. Von den CPU-Kernen arbeitet einer, drei nicht.

Schlecht. Ja, wer ist verantwortlich dafür, dass es nicht so schnell geht, wie wir das gerne hätten? Der ETL-Prozess, der die Daten transportiert vom Quersystem ins Zielsystem oder die Datenbank, vielleicht müssen wir an der Datenbank tunen, muss noch irgendwas ändern.

Das ist so das, was uns die meiste Zeit beschäftigt, während wir halt so ein Data Warehouse aufbauen und entwickeln. Ja. Während, wenn das Ganze da mal fertig entwickelt ist, geht das typischerweise in den Betrieb unter. Wir liefern es aus, lassen es laufen. Und nachdem ich so die ersten Male mich mit Kollegen unterhalten habe,

entstand dann auch schon irgendwie so die Frage im ersten Jahr, können wir damit denn auch so ein Ding im Betrieb überwachen? Und im Betrieb ändert sich dann die Fragestellung, so ein bisschen teilweise kommt was hinzu, zum Beispiel in welchem Maß steigt eigentlich die zu verarbeitende Datenmenge?

Also wie viele Datensätze kommen wir dann wirklich? Man macht natürlich vorher Überlegungen, konzeptioniert das Ganze, aber man will natürlich auch so ein Soll-ist-Vergleich machen. Ja, natürlich welchen Einfluss haben diese steigenden Datenmengen auf diesen ganzen Bewirtschaftungs- und Auswertungsprozess? Weil das ist halt auch so ein Ding. Die Auswertung kommt ja dann gerade im Betrieb dazu,

dann habe ich plötzlich Anwender da drauf, die jaulen einem dann die Ohren voll, mein Report ist so langsam. Der braucht drei Stunden, bis der zurückkommt. Die drei Stunden sind dann meistens zehn Minuten oder fünf Minuten, aber ist halt so. Und natürlich sollte das System vielleicht auch solche Fragen beantworten können, warum ist es dann das Ganze so langsam.

Ja, dann natürlich so typische Überwachungstätigkeiten wie Festplattenkapazität, Tablespace in Datenbanken. Gibt es da noch ausreichend Sachen? Muss ich aktiv werden? Muss ich irgendwas umziehen? Muss ich irgendwas erweitern? Dann die andere Sache, die ich natürlich gerade im Betrieb wissen will,

sind meine Jobs überhaupt gelaufen. Also ich erwarte, der Job läuft um 1 Uhr nachts. Ich will wissen, ob er gelaufen ist, war er erfolgreich, ist er erfolgreich zu Ende gegangen? Oder war da nichts, nicht gestartet oder wie auch immer Fehler geworfen.

Ja, andere Sache ist natürlich immer so, ob meine Quellsysteme alle erreichbar sind und natürlich auch die Komponenten meines Data Warehouse Systems. Ist alles da, läuft alles. Ja, und wenn man natürlich so das ganze Ding vielleicht mit CSV-Dateien füttert, dann will man natürlich auch wissen, nach dem Ladelauf hat er die CSV-Dateien

auch alle verarbeitet und wegräumt oder liegen die immer noch da. Das ist ein super Highlight, wenn die dann noch mal geladen werden. Und es gibt dann Kudelmudel in den Daten. Ja, als regelmäßiger Besucher der Froscon bin ich dann auf die Idee gekommen,

nachdem ich so gesehen habe, was sich so um Isingar 2 und so weiter tut, nehmen wir das Tool doch mal. Gucken wir mal, wie weit wir damit kommen. Andere Ideen hatte ich noch, hier so RRD-Tool und das andere Ding habe ich vergessen. Das kann halt so schöne Verlaufsgrafen machen, Cacti, genau, das war es.

Hab mich dann aber erst mal gedacht, machen wir mal Isingar 2, weil ich früher mal mich mit Nagios kurz beschäftigt habe. Kurz vorweg, ich komme aus der BI-Ecke, ich bin kein Experte für Monitoring-Systeme. Also es ist wirklich aus Anwendersicht getrieben, das Ganze. Ich habe nicht irgendwie ein Isingar-System gehabt oder ein Nagios-System,

habe jetzt gedacht, wie kann ich ein Data-Ware-Haus damit überwachen, sondern ich hatte ein Problem mit Data-Ware-Häusern, Aufbau-Entwicklung, Monitoring und habe dann überlegt, welches Tool nehme ich, was probiere ich aus. Der Isingar gibt es seit, also Isingar 1 ist irgendwann als Fork von Nagios entstanden, 2009.

2014 hat dann Isingar 2 das Licht der Welt erblickt und die aktuelle Version 2.3.8, die habe ich auch für meine Tests jetzt nochmal benutzt. Als Komponente, was macht das? Es führt die eigentlichen Überprüfungen aus. Es guckt also für das aus, was ich halt überwacht haben will und benachrichtigt,

je nachdem, den Benutzer bei Problemen, via E-Mail, XMPP, IRC, Twitter und diverse anderen Kanälen. So, damit hatte ich ein System, was Checks ausführen kann. Die halbe Miete ist nicht schön, man sieht nichts.

Oder man sieht vielleicht schon was, weil man eine E-Mail kriegt. So, es musste eine GUI her, irgendwas, was schön ist, was auch die Kollegen dann gerne nutzen wollen, wo sie drauf gucken können, was ein bisschen Spaß macht. Da dachte ich, nehmen wir State of the Art, Isingar Web 2.

Nachfolger von Isingar Web wurde im November 2013 angekündigt, aktuell Release Kandidat 1. Ja, das muss jetzt irgendwie reden mit dem Isingar, muss ja Daten austauschen, muss die Daten ja irgendwoher erhalten, die es bekommt, geht entweder über DBIDO-Schnittstelle,

also das ist quasi eine Datenbank, wo die darüber Daten austauschen, die beiden, oder Live-Status. Ich habe DBIDO genommen. Ja, es braucht halt einen Web-Server, mit dem es bereitgestellt wird und eine eigene Datenbank,

wo halt Benutzereinstellungen und so weiter abgelegt werden. Um dann mit dem Isingar zu kommunizieren, also in die Richtung Isingar, irgendwelche Aktionen auszulösen, läuft halt über dieses Command-Pipe-Feature von Isingar 2.

Man aktiviert das und das war's. Generell, Setup läuft übers Web, ist recht einfach, schnell, war recht zügig aufgesetzt. So, jetzt hatte ich eine Web-Uberfläche und Checks. Jetzt hatte ich aber immer noch das Problem, dass ich keinen Zeitverlauf sehen konnte.

Also ich konnte nicht sehen, was war jetzt in den letzten 10 Minuten los, sondern ich habe halt so den aktuellen Status gelesen. Ja, dann habe ich da Graphite. Das ist halt eben so eine Time-Series-Database. Die gibt es mittlerweile von Isingar 2, ist die komplett nativ unterstützt.

Man muss es nur aktivieren. Habe ich mir gedacht, nehme ich das. Ja, Graphite aufgesetzt, gibt es seit 2006. Irgendwann dann 2008 unter Apache-Lizenz gestellt worden. Aktuell ist Version 0.9.13. Ja, neben dem Speichern von den Zeitreihen Daten,

also quasi die Daten, die während den Checks entstehen, die zurückgemeldet werden, zum Beispiel bei CPU-Load, wie hoch war meine CPU-Load, die wird dort abgelegt. Oder halt mein Speicherverbrauch oder wie auch immer. Festplatten-Auslastung und so weiter. Rendert das Tool auch Diagramme aus diesen Zeitreihen Daten.

Also die Diagramme, die wir gleich sehen werden, die kommen halt von diesem Tool selber. Geht über eine Web-Schnittstelle. Generell besteht Graphite aus drei Teilen. Einmal halt Carbon, das ist ein Demon,

der nimmt die Zeitreihen Daten entgegen. Also quasi das ist das, die Schnittstelle zwischen Isingar 2 und Graphite. Dann haben wir Whisper als Datenbibliothek, halt zum Speichern von Zeitreihen Daten. Das ist ähnlich vergleichbar wie RAD Tool, kennt man vielleicht.

Ansonsten gibt es noch diese Graphite Web App, die werden wir auch gleich sehen. Das basiert auf Django. Und ja, damit kann ich Diagramme on demand generieren. Und zugrunde liegt da die Cairo-Bibliothek. Und was auch noch geht, man kann das Ganze integrieren in Isingar Web 2

über ein eigenes Modul. Das lässt sich installieren. Dann sehe ich diese Graphen in abgespeckter Variante. Also es ist nicht der Funktionsumfang, den zum Beispiel diese Web App liefert. Dann kann ich mir diese Graphen allerdings dann direkt in der Oberfläche angucken.

Was sollte überwacht werden? Also im ersten Schritt habe ich mir überlegt, ich möchte die CPU-Load inklusive Iowate überwachen, die Arbeitsspeicherauslastung, Festplatte, Kapazität und Auslastung habe ich hier geschrieben.

Damit meine ich eher so die Schreib-Performance. Also wie stark ist die Platte ausgelastet zurzeit? Ja, das Netzwerk, die Datenbank natürlich irgendwie, Erreichbarkeit von den Systemen einfach über Ping und nach Möglichkeit so ein bisschen gucken,

meine ETL-Prozesse überwachen. Ja, dann habe ich mich auf die Suche gemacht, welche Checks kann ich dafür verwenden? Erstmal die Checks für CPU-Arbeitsspeicher, Festplatten, Kapazität und Netzwerk. Gut, also CPU-Load kann ich mit Check-Load überwachen. Das ist eigentlich, wenn man es aus den Paketquellen installiert,

zum Beispiel unter Ubuntu habe ich es gemacht, ist es dabei, also braucht man nicht viel tun. Wenn man das Ganze dann von dem Monitoring-System will ich natürlich dann auch die beiden anderen Systeme überwachen. Zum Beispiel da, wo meine ETL-Prozesse laufen zur Bewirtschaftung und auch meine Datenbank läuft, dann muss ich quasi irgendwie durchgreifen auf dieses Remote-System.

Ja, das kann man machen über Nagios, das heißt nicht NPAE, sondern NRPE. Über dieses NRPE-Plugin, das heißt,

man installiert auf den einzelnen Servern, die man überwachen will, installiert man einen NRPE-Server und das kommuniziert dann, das Isinga kommuniziert dann quasi damit und führt dort auf diesen System die Checks auf und hält die Daten zurück. Das ist so sicherheitstechnisch nicht ganz so optimal,

diese Art und Weise. Deswegen, je nachdem, kann man halt auf SNMP ausweichen oder, wie ich eben erfahren habe, man installiert auf den System halt auch nochmal ein Isinga und macht es dann auch über dieses Command-Interface. Ja, gut, IOvate war jetzt so bei mir nicht drinnen,

musste ich über ein anderes Plugin nachrüsten, habe ich jetzt auch kein SNMP-Plugin dafür gefunden. Ja, für Memory, Check Memory war dabei und Festplattei, Check Disk und ansonsten fürs Netzwerk auch nachgerüstet, Check Traffic.

Damit hatte ich eigentlich so das abgefrühstückt, was so erstmal unspezifisch ist für Data Warehouse. Aber trotzdem interessant. Ja, dann Datenbanksystem, Quellsystem mit Dateien.

Bin ich über eine Seite Consolabs gestolpert, die halt für die Datenbanken, die wir so im Einsatz haben, halt entsprechende Plugins, Health-Plugins liefern, die halt die Möglichkeit geben, gewisse Parameter der Datenbank abzufragen.

SAP fällt da eher so ins Quellsystem-Bereich rein und um zum Beispiel überprüfen, ob all meine Dateien geladen worden sind und weggeräumt worden sind, die Extension Check File Exist Glob, mit der ich das dann halt abfragen kann.

So, dann kam die Frage, wie überwache ich denn jetzt genau die ETL-Prozesse? Da gibt es eigentlich so Allzweckwerkzeuge, nennt sich Check MySQL Query zum Beispiel für MySQL.

Im Endeffekt funktioniert es einfach so, es wird eine Abfrage gegen die Datenbank abgefeuert, ich kriege am besten einen numerischen Wert zurück, der wird ausgewertet und je nach Schwellwert wird eine Warnung ausgelöst. Das zeige ich gleich auch mal im Beispiel, so kann ich halt das Datenwachstum abfragen, kann hingehen und prüfen, ob mein Job gelaufen ist

und habe so auch ein Werkzeug an der Hand, was halt die Statistik und Logtabellen der ETL-Werkzeuge auswerten kann. Also zum Beispiel im Open Source-Bereich arbeiten wir mit Talent. Talent kann ich recht einfach dazu bewegen,

seine Logging-Informationen in zwei oder drei Tabellen reinzuschreiben. Also indem ich in den Projekteinstellungen sage, ok, gut, alles was jetzt irgendwie Fehler usw. ist, landet in einer Tabelle Logs, die Sachen, die die Statistiken ob ein Job gelaufen ist,

ob er erfolgreich war, landen in der Tabelle Stats und alles, wenn ich dann noch Durchflüsse usw. messen will, landen in der Tabelle Mieter. Ähnliches gibt es zum Beispiel dann auch bei Data Stage, gibt es auch die Möglichkeit, dass ich aus dem Tool rausdreckt diese Informationen schreiben lassen kann. Informatiker usw. kenne ich nicht, habe ich nicht gearbeitet.

Notfalls baut man sich selber ein ETL-Tool. Ja, so, das war es jetzt erstmal soweit die Theorie. Schauen wir uns das Ganze mal an.

Also, das zum einen ist Singer Web 2, die Oberfläche. Ich habe jetzt hier meine 3 Hosts. Einmal Frostcon DB, da liegt die Datenbank. Einmal Frostcon ETL, da liegt das quasi.

Mein ETL-Server, da läuft im Moment nur ein ETL-Job drauf, der alle NAS-Langs mal irgendwelche Daten in eine Datenbank reinschiebt. Und halt Frostcon Mon ist mein Monitoring-System. Wenn ich mir jetzt zum Beispiel mal angucken möchte,

was denn so auf meinem Datenbank-Server los war, habe ich hier Checks halt einfach jetzt hier auf dem Demo-System, habe ich eingerichtet halt die Connection-Time. Kann jetzt auch, hallo, ja, genau. Super, meine Karten sehen schön aus.

Kann mir jetzt zum Beispiel mal angucken, wie meine Connection-Time mit dem MySQL-Server in den letzten 10 Minuten ausgesehen hat oder halt dann auch entsprechend länger.

Gleiches gilt auch für das Load. Kann mir zum Beispiel hier das Load angucken, wie es war.

Ich habe hier immer so Spitzen, immer zu den 5 Minuten hin. Das liegt ganz einfach daran, das ist mein ETL-Job. Der wird getriggert immer alle 5 Minuten im Moment. Habe ich über Cron so eingestellt, alle 5 Minuten tut er etwas.

Das sieht man wunderbar. Scheinbar ist meine Datenbank alle 5 Minuten noch irgendwo beschäftigt. Ja, den Nachteil, den man jetzt hier schon sieht, ist, ich sehe immer nur eine Grafik. Ich kann nicht gucken zum Beispiel, ich kann nicht gucken, was jetzt,

also ich kann hier nicht zusätzlich einblenden zum Beispiel, was tut mein ETL-Server. Ich kann das nebeneinander legen. Ich habe aber halt keine Möglichkeit, beide Grafen jetzt zum Beispiel die Load von dem ETL-Server mir gleichzeitig anzugucken in demselben Diagramm wie von meinem Datenbank. Das ist ein bisschen ungünstig, wenn ich halt rausfinden will, wo klemmt.

Das kann allerdings dieser Graphite Browser, den ich eben schon angesprochen habe. Also hier habe ich jetzt einfach mal, genau,

also bis 14.17 war die Kiste scheinbar aus. Oder da war wenig los. Aber hier sieht man halt schon die Load Kurven. Einmal in Blau von der ETL-Maschine und einmal in Grün von der Monitoring-Maschine. Das ist aber Blödsinn.

Das war der falsche. Wir wollen die Datenbank dazu haben. Wie man jetzt hier sieht, also vielleicht gar nicht schlecht. Man sieht hier in diesem Bereich, sehe ich halt quasi alle Daten, die von Isinga in das Graphite eingefüttert werden.

Ja, ist eine Menge Zeug. Man muss immer so ein bisschen suchen, bis man das gefunden hat, was man haben will. Hier habe ich meine Load. Klicke jetzt hier drauf. Und jetzt sehe ich halt in der roten Kurve noch zusätzlich, sehe ich halt, wie jetzt mein Load Verlauf war

bezüglich Datenbank. Und kann natürlich dann auch Rückschlüsse drauf ziehen, wo es jetzt klemmt. Also, wie man halt hier zum Beispiel sieht, 14.20, die Load auf dem ETL-Server, die, ach nee, das ist ja der, ja genau, die in Blau, die Load auf dem ETL-Server,

die war eher gering. Dafür war die Load auf der Datenbank ziemlich groß. Liegt ganz einfach daran, er macht Inserts und dabei Updates. Ja, und ich habe halt absichtlich keinen Index gesetzt, eben damit man so eine Diskrepanz sehen kann. Wahrscheinlich, wenn ich jetzt den Index setzen würde, dann würde die Load nachher runtergehen.

So, so viel dazu. Ja, kann ich natürlich jegliche anderen Checks auch mit reinbauen, die ich haben möchte, um die da miteinander zu vergleichen. Könnte jetzt auf dieselbe Art und Weise noch andere Daten dazu packen,

wie Arbeitsspeicherauslastung, ob ich in irgendeinen Swap reinlaufe zum Beispiel, oder wie meine Anzahl, genau, meine Anzahl, wie viele Threads verbunden waren mit dem,

ja, da sieht man zum Beispiel dann auch, dass ich scheinbar immer zwei Threads habe, die dauerhaft verbunden sind mit der Datenbank und zum Zeit von dem Ladeverlauf steigt die plötzlich auf 4 und fällt dann wieder ab. Das ist halt auch ein Wert, der sich echt lohnt zum Monitoren.

Also wir hatten es schon gerade im Zusammenspiel mit Talents schon mehrfach, dass die Connections nicht abgebaut werden und irgendwann macht der Server dann dicht und weil er einfach so viele offene Connections hatte, ja, dass er ja nicht mehr wollte.

Gut, ja, vielleicht noch so ein bisschen, wie kann ich denn jetzt die ETL-Jobs überwachen? Da habe ich es nicht mehr geschafft, das hier soweit zu integrieren. Das kann ich aber auf der Kommandozeile zeigen. Dann sieht man auch, wie man da hinkommt.

Also hier, das ist zum Beispiel die Tabelle. Ja, ist jetzt leider alles ein bisschen unschön, sich so anzugucken, aber einfach mal so, damit man Überblick hat.

Also das ist das, was mir zum Beispiel das Tool rausschreibt. Wie man sieht, bekomme ich hier halt Informationen über den Job, den ich angestoßen habe und dann halt auch, ob er successful war oder nicht. Und das kann ich zum Beispiel auswerten dann mithilfe von einem Plugin,

um zu gucken, um das Ganze in meinen Monitoring zu integrieren. Schauen wir uns das mal an, wie das dann aussehen würde. Wie gesagt, Allzweckwaffe, Check MySQL Query benutzt. Und hier mache ich halt eben genau Folgendes.

Ich feuere über das Plugin ein Statement ab, baue mir das halt hier um, damit ich einen numerischen Wert kriege. Also wenn es Success ist, wird es eins. Ansonsten, ja, gehe ich auf den letzten Job, der gelaufen ist.

Das ist jetzt nicht ganz optimal. Natürlich müsste ich irgendwie, ich habe mir jetzt einfach mal den Letzten rausgegriffen. Natürlich will ich normalerweise gucken, ist der einmal am Tag gelaufen oder so. Dann müsste ich halt entsprechend dieses Moment noch weiter eingrenzen, sodass ich dann mit Between oder so arbeite, dass ich halt dann entsprechend eventuell hier auch nichts rauskriegen würde.

Ja, also so bin ich dann vorgegangen, um diese ganzen, um die Checks dann zu entwickeln. Ich habe erst mal auch wirklich auf der Kommandozeile mithilfe von diesen Plugins angefangen, das zu bauen. Ja, wie merkt er denn, ob es jetzt kritisch ist oder nicht?

Das macht er hier hinten. Ich habe ihm halt gesagt, alles, was, also C ist eins, heißt, wenn er ein eins zurückgibt, ist alles okay. Ja, wenn er da halt da drunter liegt, also quasi eine Null zurückliefert, würde er ein Fehler auslösen.

Ja, das müsste man jetzt halt noch über die Konfiguration verpacken, in halt Commands und dergleichen, dass das halt dann entsprechend in die Oberfläche mit reinpasst. Ja, was haben wir noch?

Ja, das Gleiche kann ich natürlich dann hier machen, um meine Anzahl Records in einer Tabelle zu checken. Kann ich halt genauso sagen, okay, gut, lasse ich hier auch wieder mein Statement laufen, liefert mir einen Wert zurück, in dem Fall den Wert.

Und der würde dann auch über das entsprechende Plugin, also über die entsprechenden Konfigurationen als Kommando und Service würde es dann in meinem Nagios, in meinem Isinga drinnen landen und in meinem Graphite. Einen habe ich noch vorbereitet.

Ich habe auch gerade Blödsinn erzählt. Das ist gar nicht, das hier ist gar nicht der Check auf die Reihe, sondern auf die Duration. Also in dieser Tabelle, die mir mein ETL-Werkzeug automatisch anlegt,

wird halt auch die Laufzeit mit getrackt. Die Laufzeit kann ich dann halt auch hier einfach abfragen, kriegt diesen Wert zurück, könnte halt auch hier in Critical setzen oder nicht, was dann halt parametrisiert aufgerufen wird,

aus den Konfigurationen heraus. Dann habe ich hier nochmal das Ganze für den Row Count.

Interessant, dass er dasselbe zurückliefert. Irgendwo. Ja, gute Frage, warum da dieselben Werte rauskommen. Vielleicht Zufall.

Vielleicht auch. Keine Ahnung, scheinbar schafft, ist fast, ist gar nicht derselbe Wert, aber sehr identisch. Also er schafft scheinbar eine Reihe pro, ich weiß nicht, ich glaube es sind Millisekunden, die er da anzeigt.

Ja, so viel dazu. Ich wäre damit durch, war ein bisschen sehr schnell. Bleibt viel Zeit für Fragen.

Okay, das klingt gut.

Ach so, ja, ich hätte auch noch ein Fazit.

Ja, was ich so mitgenommen habe aus dem Ganzen, es ließ sich alles recht einfach installieren aus den Paketquellen. Es war recht schnell alles gemacht.

Ja, mit Isingar 2 dann auch eine ansprechende Oberfläche zur Verfügung, mit denen ich denke ich den ein oder anderen dafür begeistern kann, vielleicht mal drauf zu gucken, wenn er Fehler sucht. Ja, durch die direkte Anbindung an Graphite, durch Isingar 2 war das auch ganz schnell erledigt, die Daten da drinnen. Also man muss es halt auch eigentlich nur installieren,

eine Konfigurationsdatei anpassen und dann landen die Daten halt im Graphite drinnen. Ja, ein bisschen Probleme hatte ich so bei dem Graphite-Modul für InSingar Web 2, da habe ich ein bisschen länger gebraucht, bis das dann irgendwie lief und rund lief. Ich glaube aber einfach, ich hatte mich vertan einmal.

Das ist halt so ein bisschen schwierig, weil man muss halt aufpassen, dass die DNS-Auflösungen da stimmen, weil er halt wirklich direkt auf die Vhost-Einstellung im Apache wirklich auf dieses Tool zugreifen kann, um die Graphen zu rendern. Ja, der Verlauf ist über die Diagramme auf jeden Fall gut nachvollziehbar.

Man sieht, was sich tut. Ja, das Problem ist halt nur, wenn man halt sehr kurze ETL-Läufer hat. Also das habe ich auch gemerkt, wo ich dann das Demo-System für heute fertig gemacht habe. Wenn das zu kurz ist, erfasst das halt gar nicht, weil man kann es ja einstellen, wie oft man diese Checks machen möchte.

Aber unter Umständen rutscht das halt irgendwie so ein bisschen da unten drunter durch. Man sieht es da nicht wirklich. Also wenn man sehr kurze Läufe hat, dann wird es einfach nicht erfasst. Man kann natürlich dann diese Rate der Checks hochdrehen.

Das Problem ist aber, also gerade bei diesen Count-Geschichten und komplexeren Abfragen merkt man dann halt, die Checks kosten auch gerade mit diesem MySQL-Query, was wir eben gesehen haben, kosten dann halt auch Zeit und erzeugen zusätzliche Last auf den System. Wenn ich natürlich dann ein sehr hohes Intervall wähle, dann ist das eher kontraproduktiv, wenn mein Monitoring dann meine Datenbank in Beschlag nimmt,

die eigentlich andere Dinge tun sollte. Ja, ansonsten macht es Spaß, damit zu arbeiten. Das ist auch ein gutes Werkzeug. Und ich hoffe, dass wir das dann in einem ein oder anderen Projekt auch einsetzen werden.

So viel dazu. Wenn auch Fragen offen sind, ja damit.