Riesinger II, Prof. von Markus Frosch. Ein Applaus, bitte.

Ich hoffe, es hören mich alle. Ja, schön anzusehen. Ich möchte heute ein bisschen was über das Riesinger-Projekt erzählen, was wir tun, was es Neues gibt und so weiter. Markus Frosch, der Name, hat ein Kollege schon gesagt. Jetzt vorab, um das Publikum ein bisschen auszufragen. Wer hat denn schon mal von Riesinger gehört?

Wer hat Riesinger schon mal ausprobiert oder im Einsatz? Ok, wunderbar. Worüber ich heute reden will, ist so ein bisschen allgemein, wie unser Riesinger-Plattform momentan ausschaut.

Neuigkeiten aus dem Riesinger-Projekt von diesem Jahr. Riesinger II ist jetzt ganz neu bei uns dabei. Die Entwicklung von Riesinger Web 2 und wieso die nächste Zeit ausschaut, was es Neues geben wird. Kurz zu mir. 84er Jahrgang, arbeite für die Firma Netways als Open-Source-Konsultant.

Bin so in dem Bereich tätig, der eben sich komplett um Riesinger dreht. Monitoring-Lösungen mache ich aber genauso gut. PubMed-Config-Management im Linux bis zum Solaris-Umfeld. Bei Riesinger bin ich hauptsächlich im Webbereich tätig.

Ich helfe dem Webteam ein bisschen beim Testen und Entwickeln von den Geschichten. Liefere viel Feedback zu Problemen und mache nebenbei Debian-Paketierung für Riesinger zum Teil. Deswegen auch aktiv im Debian-Projekt und man wird mich an einer oder anderen Stelle meinen Namen finden.

Was ist Riesinger ganz kurz, nachdem es viele hier schon kennen oder einsetzen, muss ich nicht viel dazu sagen. Riesinger I als Fork aus Nagios entstanden im Jahr 2009. Sind jetzt also schon einige Jahre im Geschäft dabei. Riesinger II, die Neuentwicklung ist komplett neu gestalteter Code.

Dazu später mehr. Und die Prämisse unseres Projekts ist 100% Open-Source zu machen. Ich habe schon gesagt, ich arbeite für Netways. Netways ist federführend hinter Riesinger an der Entwicklung beteiligt. Und wir setzen das bei vielen, vielen unserer Kunden ein. Aber möchten eben keinen Open-Core fahren oder irgendwelche anderen Paid-Lösungen.

Deswegen wir eigentlich nur alles in Open-Source entwickeln. Das Riesinger-Team setzt sich also zu einem Teil aus Netways-Mitarbeitern zusammen. Zum Teil aus Freiwilligen, die von der Außenwelt mitarbeiten. Und wir haben momentan um die 26 Teammitglieder.

Und jetzt sagen wir, die sind mehr oder weniger aktiv. Also wer schon mal in einem Open-Source-Projekt aktiver weiß, wie viel Aktivität teilweise heißen kann. Aber man hört doch immer mal wieder von den Leuten. So einen kurzen Überblick über die Gesichter, die bei uns im Team sind. Ist bunt gemischt. Wir haben jetzt auch aus der Red Hat-Ecke von der Paketierung einige nette Kontakte gekriegt.

Gerade Fedora vom Projekt her. Das ist schön, dass man da auch was hört. Die Riesinger-Plattform hat also momentan so ein bisschen zweigeteiltes Prinzip. Deswegen, ich haue drüber Rede. Also wir haben auf der einen Seite die Riesinger-1-Welt und die Tools und so weiter, die es da schon seit einiger Zeit gibt.

Und entwickeln jetzt dieses Riesinger-2 als Spur daneben. Spur daneben heißt deswegen, weil wir viele Dinge neu angefangen haben. Und versuchen auf dem Sinne zum einen Designfehler, die so ein Nagios oder ein Riesinger-1 hat, besser zu machen als heute.

Und haben das jetzt eben auch für unsere Web-Tools vor. Also für die Frontends, die die Admins und User dann benutzen, um was zu sehen. Nicht zu verachten, der Teil ist Riesinger-Reporting.

Wer sich schon mal mit SLA-Monitoring auseinandergesetzt hat. Also gucken, welcher Service zu wie viel Prozent in einer gewissen Zeit verfügbar ist. Da haben wir einige Beispiele gesammelt, was ein nettes Start-Kit ist, wenn man sich mal damit auseinandersetzen möchte. Die Architektur bei uns dreht sich sehr viel um eine Datenbank.

Man muss sie nicht benutzen, man kann sie benutzen. Diese Datenbank bietet viele Vorteile, gerade was den schnellen Zugriff auf Information angeht, sowohl auf Status als auch auf History. Und deswegen bauen wir es sehr viel darum. Zum Beispiel das Reporting, was ich gerade gesagt habe, dreht sich komplett um diese Datenbank.

Und unsere Web-Tools können Informationen aus dieser Datenbank lesen, aber genauso aus den herkömmlichen Status-Informationen. Was gibt es Neues bei Riesinger? Wir sind dieses Jahr fünf Jahre im Geschäft. Fünf Jahre in aktiver Nagelsfork.

Wir sind immer noch relativ happy mit der Entscheidung, die wir getroffen haben. Es ist zwar nicht ohne so ein Projekt zu betreiben. Wir spüren immer noch leider, dass Riesinger in den USA relativ wenig Leute kennen, aber sind mittlerweile in Europa relativ gut verbreitet.

Was ist bei Riesinger passiert, was Releases angeht? Wir haben von dem alten Riesinger-1-Bereich einige Releases veröffentlicht. Das sind jetzt hauptsächlich Bug-Fix-Releases in dem Fall. Riesinger-2 ist jetzt die stabile Version seit dem 16. Juni draußen.

Das heißt, eine Version, die wir selber sagen, die ist so stabil, dass man sie eigentlich einsetzen kann. Wir haben seitdem viele Feedbacks bekommen. Es gibt mittlerweile zwei minor Releases, die sich hauptsächlich um Bug-Fixes drehen. Kleine Features sind auch dabei, die sich dann Richtung Packaging drehen.

Und da ist das letzte Release jetzt eben vom 7. August. Was auch ich jetzt nicht unerwähnt lassen wollte, ist Monitoring Plugins. Wer hat von Monitoring Plugins gehört? Und was der Unterschied zu Nagios Plugins ist? Okay, nicht alles, dachte ich mir. Nagios Plugins ist so dieses ewige Projekt, das mit Nagios nebenbei lief.

Diese ganzen Plugins, die Skript CheckPing, CheckHTTP und so weiter, ist also ein Projekt, das nicht in Nagios selber mit 100% drin war, sondern ein Seitenprojekt von Nagios damals war. Und viele, viele dieser Maintainer haben das freiwillig gemacht auf Basis.

Es gibt einige Leute, die dann bei OpsU arbeiten. Es gibt ein paar Leute, die von Red Hat, die an diesen Plugins mitgeschraubt haben. Und da gab es dieses Jahr so ein paar wieder mal Trademark-Diskussionen leider um den Namen Nagios. Deswegen die Leute des Teams, wenn wir gezwungen waren, das Plugin umzubernehmen. Also wenn vielleicht die Geschichte vom Monitoring Portal oder von der Monitoring Exchange mitgekriegt hat,

im Endeffekt leider wieder das Gleiche passiert. Es gibt Nagios Plugins weiterhin, sage ich ganz offen. Wird jetzt maintained von der Nagios Enterprises als Firma. Einziger Unterschied ist halt, dass das Team und die Leute, die bisher diese Plugins gemacht haben,

eben nicht mehr in diesem Nagios Plugins Team drin sind. Also ihr könnt euch das gerne angucken. Beides online. Es gibt monitoringplugins.org, es gibt nagiosplugins.org. Es gibt nicht viele Unterschiede davon. Aber man kann sich halt selber entscheiden, was man benutzen möchte. Und wer dem Team von Monitoring Plugins mehr vertraut als jetzt der Firma, die Nagios entwickelt,

dann soll der das Erste nehmen. Das ist eine lange, lange Geschichte. Aber ich wollte es eben sagen, weil es nicht alle kennen. Isingar 2. Isingar 2, ich habe es kurz vorhin gesagt, ist eine Neuentwicklung.

Heißt, wir waren mit der Architektur, die aus Nagios kommt, nie glücklich. Sei es Performance, sei es Codequalität, sei es auch Skalierung schlicht und einfach. Da stößt man irgendwo an seine Grenzen. Und wenn man sich dann auch mit Erweiterungen beschäftigt an andere Plugins,

ist es alles oft sehr, sehr kompliziert. Und wir haben also vor fast zwei Jahren entschieden, dass wir uns überlegen, was Neues zu machen. Neue Codebasis anzufangen. Und diese neue Codebasis ist auch komplett neue Programmiersprache, ist jetzt C++ statt C.

Der Ansatz des ganzen Cores ist, komplett Sweating-Architektur zu bauen. Wer das alte Ding sich mal auseinandergesetzt hat, das ist sehr, sehr monolithisch gebaut. Dadurch nicht erweiterbar. Und wir haben also jetzt eine sehr modulare Architektur. Darunter, die jetzt übrigens auch auf Windows läuft.

Wird wahrscheinlich hier keiner betreiben wollen, aber... Man kann es mit Visual Studio bauen. Ich frage jetzt nur, wer es so will. Bitte? Ja. Wir haben also tatsächlich Windows VMs, die das dann bauen.

Ich habe sie nicht eingerichtet, bin froh, dass ich sie nicht anfassen muss, aber da läuft irgendwas. Einen großen Bruch, der für User spürbar ist, den mussten wir leider tun, das ist Config-Format. Die Ideen sind die gleichen. Also ich habe Host-Objekte, ich habe Service-Objekte, ich definiere mir irgendwie, wie ich benachrichtigt werden muss,

wie ich eskaliert werden muss, wie die Abhängigkeiten des Ganzen sind. Aber man muss in der alten Nagios-Welt sehr, sehr viele Tricks benutzen, um Konfiguration zu erzielen oder die übersichtlich zu gestalten. Und deswegen ist dieser neue Config-Ansatz, ich zeige dann auch ein paar Beispiele,

sehr flexibler gehalten. Leider das Problem davon, man muss sich mit seiner Config tiefer auseinandersetzen. Wer mal von Nagios zu Icinga gewechselt hat, stellt fest, ich kann ja die gleichen Contentfalls benutzen, das geht leider nicht mehr.

Es gibt ein Konvertierungstool, das Tool ist aber im Endeffekt das, was es sein soll. Es kann eine Konfiguration so pasen, wie es Icinga 1 tun würde und daraus eine Logik bauen, die Icinga 2 versteht. Das heißt nicht, dass das besonders schön ist, was da rauskommt. Es ist formatiert, wie man das machen sollte, aber diese ganzen Config-Tricks,

diese Einfachheiten, die wir mit dem neuen Config haben, kann das Ding schlicht und einfach nicht abbilden. Da muss man sich ein bisschen Gedanken machen. Aber gerade die Leute, die ein bisschen Config generieren, aufgrund von Datenbanken, CMDB oder so auch immer, sollten eigentlich wenige Probleme haben.

Eine Core-Komponente von Icinga 2 ist der Cluster-Stack. Wir können jetzt also mehrere Demons zu verschiedenen Servern laufen lassen, die sie miteinander reden können. Sowohl in einem Hochverfügbarkeitsaspekt als auch in einem Skalierungskonzept in verschiedene Zonen nennt sich das bei uns.

Ich zeige es dir noch. Also ich kann meine DMZ ankoppeln und habe nur eine Verbindung zwischen zwei Icinga-Systemen. Und ich kann diese ganzen einzelnen Features, die Icinga hat, ein- und ausschalten, wie ich das möchte. Auch in einem Cluster-Bereich. Die Datenbank-Schnittstellen und auch Live-Status gibt es jetzt nativ im Core.

Gerade die Datenbanken waren in der Nagios Icinga 1-Welt so ein bisschen schwierig anzubinden. Da hatte man einen Demon und der hat irgendwas Magisches gemacht. Das ist jetzt also relativ nativ drin, dadurch auch schneller. Und Live-Status ist einfach deswegen drin, weil es sehr, sehr viele Tools gibt, die auf Live-Status aufbauen,

oder irgendwelche Sachen abfragen, sei es jetzt NUCWIS oder Business Process oder irgendwelche Web-Interfaces wie Struck oder so. Die wollten wir schlicht und einfach supporten und haben deswegen die API nativ bereitgestellt. Komponenten allgemein. Man sieht jetzt das wirklich sehr modular.

Der Checker, wenn ich den Checker deaktiviere, checkt Icinga nichts mehr. Aber ich habe halt so die Möglichkeit, einen Cluster zu bauen, wie ich es möchte und kann sagen, es sind jetzt bestimmte Worker, die führen mir Checks aus und ich habe einen Knoten, der kümmert sich dann um die Datenbank und die Notifizierung. Und ich habe einfach die Möglichkeit, ein bisschen zu puzzeln. Muss es aber auch nicht tun, ich kann es einfach alles auf einem Server laufen lassen.

Compat deswegen, weil wir die alten Klassik-Daten bzw. Status-Daten nicht ganz vernachlässigen wollten. Es gibt also eine Kompatibilitätsschicht, dass Icinga 2 Status-Dat schreiben kann, so wie es Icinga 1 oder Nagios auch tut. Das heißt, man kann auch das ganz alte Webinterface mit Icinga 2 noch benutzen,

das zeige ich dann noch. Oder man kann irgendwelche Tools, die die Status-Dat selber auslesen, einfach beibehalten oder einfach ausgeschrieben. Man muss es nur aktivieren. Live-Status, Perf-Data als einfache Schnittstelle für generische Tools, wie PNP von Nagios etc.

Wir haben ein Graphite-Modul drin, das direkt metrisch nach Graphite pushen kann. Das heißt, man hat wirklich sehr, sehr viele Informationen in Graphite automatisch drin. Das Notification-Modul kümmert sich einfach dafür, Notifications auszuführen. Das heißt, man kann dann auch irgendwelche lustigen Konzepte bauen,

dass der Notification-Server irgendwo steht, wo er den Mesaver erreichen darf und die anderen Systeme nicht. Und eben IDO für MySQL und ProSQL. Da kann man an der Stelle fragen, wer setzt Oracle rein? Ich haue euch nicht, keine Sorge.

Oracle. Oracle-Datenbank. Wir haben also wirklich die Frage gekriegt, ob wir da nicht Oracle supporten könnten, weil es mit Isingar 1 durchaus möglich ist. Interessanterweise kam, glaube ich, eine Anfrage aus Chile oder Argentinien, ich weiß es nicht mehr, ist momentan nicht drin.

Wer das möchte, kann sich gerne melden und für uns programmieren. Ja, Config-Differences, ich habe schon gesagt, die Syntax hat sich ziemlich geändert, ist jetzt vom Layout-Stil so ein bisschen programmatischer gehalten.

Ich glaube, es regnet. Oder das Haus stürzt gleich an, ich hoffe nicht. Aber die grundlagenden Ideen sind die gleichen, also die Objekte, das gibt Host-Service. Einziger Unterschied, diese Kontaktgruppen gibt es jetzt nicht mehr, sondern die heißen jetzt User und Usergruppen.

Hat aber was mit der Notification-Logik zu tun, zeige ich später. Es ist einfach nur so ein Bruch, dass wir halt sagen, das ist kein Kontakt, der notifiziert wird, sondern das ist ein echter User des Systems, mit dem wir irgendwas tun können. Es gibt so etwas Ähnliches wie Makros. Man konnte ja in der Sinker-1-Welt mit diesem Dollar-Wert-Dollar

den Checkplugin mitgeben oder so. Das können wir auch. Ist aber weiterentwickelt, ein Schritt weitergedacht. Und nicht ganz so eindimensional. Es gibt eben zwei Dinge, es gibt globale Makros, die sozusagen programmatisch in die Config geschrieben werden.

Und es gibt Variablen, die dann von Objekten vererbt werden. Und der neue Config-Trick, was eben mit 1 nur sehr schwierig möglich war, ist, wie weiche ich einen Service einem Host zu? Wie definiere ich, was will ich auf diesem Host monitorn? Da gibt es also jetzt sehr, sehr flexible Ansätze dafür.

Das ist jetzt hier ein Beispiel, wie in der alten Welt ein Check-Commando aussieht und ein Service dazu. Und wie das in der neuen Welt aussieht. Ich hoffe, das können alle lesen. Man sieht also auf der linken Seite, ich definiere dann ein Kommando,

da habe ich irgendeine wunderschöne Kommandozeile und da so ein Wert ARC1, ARC2. Ist im Prinzip kein schlechter Ansatz. Man merkt aber dann die Probleme davon, wenn man ein Checkplugin auf verschiedene Arten anfahren möchte. Also beispielsweise jetzt nicht in dem Fall PING.

Schlimmeres Beispiel wäre ein HTTP-Check, wo ich dann unter Umständen noch ein V-Rost-Argument habe, sagen möchte, check doch bitte SSL, checken den Zertifikat und so weiter. Deswegen haben wir gesagt, wir parametrisieren das anders. Und man sieht jetzt eben hier dieses Check-Commando PING common.

Es sagt zum einen, wo er das Plugin findet. Also hinter diesem Plugin hier, das ist ein globales Makro, steht dann dieses Plugin-Pass, UserLib, Neibes Plugins irgendwo. Und was er da ausführen muss. Und diese Argumente, immer jetzt eben, da gibt es dieses Minus-H, dass die Adresse des zu PING-Gerätes aussieht.

Die Warenwerte für die Roundtrip-Time, für Packet-Loss, für Critical. Wie viele Pakete er denn sendet zum Testen und wie der Timeout von diesem Plugin ist. Und ich setze nun also in diesem Check-Commando Variablen, oder was, die die Default-Einstellungen dafür vorsehen. Wenn ich dieses Plugin jetzt praktisch benutzen möchte,

dann ändere ich, setze ich diesen Wert einfach. Ich ändere den. Und dadurch überschreibe ich praktisch die Default-Einstellungen. Das heißt, ich muss jetzt nicht, wenn ich einen ARC1 und einen ARC2 habe, bei jedem Check, bei jedem Server, wo ich das verwende, beide Argumente angeben, sondern ich kann einfach sagen,

ich will jetzt nur die Critical Roundtrip-Time oder so hochsetzen, von diesem PING-Check. Hier sieht man jetzt, wie kann ich einem Host-Server es zuweisen. In der alten Nagios-Welt hat man das meistens über Hostgruppen gemacht.

Das heißt, ich habe irgendeine Hostgruppe gemacht. Das waren meine Linux-Server. Ich habe eine Hostgruppe gemacht, das meine Web-Server waren. Und habe dann darüber das Ganze zugewiesen. Wir haben dem Ganzen jetzt ein bisschen mehr Intelligenz gegeben und können also jetzt anhand von Variablen, von Hostgruppen,

von allmöglichen Attributen, die so ein Host hat, entscheiden, will ich das auf dem Host checken oder eben nicht. Also ich kann einen PING-Check definieren, kann sagen, PING machst du auf allen Hosts, aber nur, wenn die IPv4-Adresse gesetzt ist. Wenn ich jetzt keine V4 habe mehr auf dem Server,

dann wird der Check dann einfach nicht mehr aufgeführt und der ganze Service ist dann sozusagen verschwunden. Das Gleiche kann ich dann machen, wie das oben rechts von euch zu sehen ist, dass ich anhand von einem Host-Namen oder irgendeinem Pattern entscheide, ob ich das zuordne oder dann auch anhand von,

das ist leider, sehe ich gerade auf dem Beispiel nicht drauf, aber ich kann auch diese Variablen hernehmen, wie diese OS-Linux, die da erwähnt ist, und kann sagen, wende mir diesen Check auf alle Systeme an, die als Betriebssystem Linux haben.

Und ich war jetzt zum Beispiel vorletzten Freitag bei Xing im Büro, die testen momentan Xing A2 in ihrer Umgebung. Die haben ein relativ schönes Beispiel, wie man diese Config-Tricks, diese Assign-Regeln nehmen kann. Die haben im Prinzip alle ihre Hosts in einer Datenbank drinstehen. Haben da also lauter Tags, in denen drinsteht,

was das für eine Maschine ist. Das ist jetzt ein Debian, Debian Visi, das ist ein HP-Server oder eine virtuelle Maschine. Also die haben lauter sozusagen kleine Tags, die den Host definieren. Und den kompletten Service-Katalog, den die definieren, sagen die einfach, das ist ein Check, den führst du mir bitte auf ein Debian-System aus, da will ich jetzt Check-up prüfen oder so.

Das ist ein Check, den prüfst du einfach generell auf allen Linux-Systemen etc. Also man hat sich dadurch einfach die Möglichkeit, eine übersichtliche Konfekt zu schreiben, ohne jedes Mal irgendeine Hostgruppe definieren zu müssen dafür. Und wie es eben hier auch steht, man kann dann bei einer Assign-Regel auch sagen,

wo die zu ignorieren ist, wo die halt nicht zutrifft als Gegenargument. Ich habe schon kurz erwähnt, mit Isingar 2 gibt es diese Kontakts- und Kontaktgroups nicht mehr. Es kommt daher, da wir uns gedacht haben,

es funktioniert eigentlich nicht richtig, wie es gerade ist. Früher war es so, ich habe einen Kontakt angelegt, der Kontakt hatte hinterlegt, der möchte per Mail notifiziert werden an seine Mail-Adresse. Das ist aber eigentlich falsch. Sondern ich möchte einen User anlegen, sagen, der hat eine E-Mail-Adresse, der hat eine Pager-Adresse, der hat, was weiß ich, eine Jabber-Adresse,

auf die er benachrichtigt wird. Und möchte dann ein Notification-Objekt sagen, das sagt, wenn für bestimmte Systeme ein Alarm eintritt, dann möchte ich per E-Mail diese User benachrichtigen. Das sieht in der alten Isingar-Nagios-Welt so aus, dass man eben für jeden Notification-Mechanismus,

den man einem User schicken möchte, muss man einen eigenen Kontakt anlegen. Man muss sagen, man hat für den User einen E-Mail-Kontakt, man hat für den User einen SMS-Kontakt. Und jetzt ist es schlicht und einfach so, dass ich eben sage, ich möchte meine Linux-Admins benachrichtigen, wenn ein gewisser Status eintritt, das ein Problem ist, Acknowledgement und so weiter.

Und das definiere ich einfach als Regel auf bestimmte Systeme. Und Eskalations in dem Umfeld ist dann einfach so, dass ich bei einer Eskalation sage, ich habe ein Notification-Objekt, das gilt erst ab einer Stunde. Also wenn der Server für eine Stunde ein Problem hat, dann benachrichtige ich jemand anderes.

Und ich muss einfach nur, wenn ich eine Notification haben will, sozusagen ein Objekt anlegen, das sagen, für welche Systeme möchte ich wen notifizieren? Und das war's.

Isingar-2-Cluster. Noch ganz kurz, bevor wir mal einen Blick auf die Config-Files werfen. Die komplette Kommunikation ist TLS-verschlüsselt. Ist so gedacht, dass man eine eigene CA dafür anlegt für Isingar. Wenn man das möchte, kann man durchaus auch eine Puppet-CA dafür nehmen. Aber im Prinzip braucht eben jedes System ein eigenes Zertifikat, ein eigenes kleinen Zertifikat.

Und die Server autonifizieren sich untereinander komplett über diese Zertifikate. Die Cluster-Kommunikation kann bidirektional erfolgen. Das heißt, ich kann DMZ-Hosts haben, die zum zentralen Isingar-System connecten. Ich kann aber auch ein zentrales System haben, das zu seinen Satelliten connectet. Also sozusagen immer die in beide Richtungen

die Verbindung herstellen kann. Und ich kann in dieser Clustering-Logik Zonen definieren, die zusammengehören. Ich habe per se immer eine Masterzone, in der mein System drin ist. Wenn ich in zweiten Knoten in diese Zone hänge, dann teilen die sich die Aufgaben. Das heißt, 50% von den Checks

wird von den Systemen ausgeführt. Und da kann ich dann beliebige Zonen weiter definieren und kann sagen, das ist jetzt meine DMZ, das ist mein Standort in den USA. Und diese Zonen für sich sind komplett autark. Die haben ihren eigenen Konfliktteil. Aber sie übertragen alle ihre Ergebnisse an die zentrale Instanz.

Die zentrale Instanz sieht alles. Und die Instanz, die irgendwo in den USA steht, sieht halt nur ihre Checks, die da laufen. Ihr könnt das Ganze so machen, dass dort dann nur ein Isingar läuft, das einfach nur checkt und alles zentral meldet. Ihr könnt aber genauso gut dort ein Web-Interface hinstellen, eine eigene Datenbank, die das Ganze lockt. Wo dann die Admins halt immer auf ihre lokale Instanz zugreifen.

Macht keinen Unterschied. Untereinander verteilen die sich die Aufgaben untereinander. Komponenten wie Notification wird ausgehandelt, wer sich gerade darum kümmert. Kann natürlich nur einer machen, sonst kriegt man doppelte Mails. Dinge wie der Checker verteilt schlicht und einfach die Last auf alle Systeme, die das Checker-Modul aktiviert haben.

Und hat dadurch eine relativ harmlose Skalierung. Ja.

Ja. Also von dem Prinzip hat sich nichts geändert. Du wirst trotzdem Remote-Checks irgendwie per SNMP oder Check bei SSH etc. ausführen. Der große Unterschied ist halt einfach, dass du den Maß das skalieren kannst.

Es ist immer noch so gedacht, dass du halt ein Isingar-Monitoring-System hast, das irgendwas prüft, irgendwo, wie auch immer du das haben möchtest. Aber du halt das skalieren kannst. Ist jetzt nichts, was auf jeden User zutrifft. Aber wenn man größere Umgebungen oder dann vor allem verteilte Umgebungen betrachtet, ist das dann deutlich einfacher.

Aber es ist wirklich dann einfach nur ein Isingar-System, das Monitoring ausführt. Genau. Werfen wir mal einen kurzen Blick auf die Konfig. Das ist der interessanteste Teil, glaube ich. Ich habe genauso eine zentrale Isingar-Konfiguration.

Die tut aber nichts anderes als zu sagen, welche Konfigurationsobjekte ich mir einteilen möchte. Bitte?

Ach so, der Beamer war verstellt. Besser? Ich habe die Möglichkeit, Konstanten zu definieren. Also sozusagen diese globalen Makros, die ich irgendwo benutze. Definiert sozusagen in dem Fall das Plugendier, das ich dann bei den ganzen

einzelnen Check-Makros benutze. Das ist auch der Weg, der sozusagen die alte Ressource-CFG ersetzt. Also wenn ich möchte, dass irgendwelche Datenbank-Passwörter nicht in meiner Objektkonfig drin sind oder so, kann ich die einfach als makro global definieren, das Konfig verschützen und dann kann keiner meiner User die Passwörter sehen. Das ist ganz nett an der Stelle.

Diese Konstanten funktionieren auch als Konfig-Werte. Wer sich mal in die Dokumentation von Isingar reinschaut, gibt es eine ganze Latte an Standard-Makros, Standard-Konstanten, die dann irgendwelche Pfade festlegen, das sagen, wo die Status Standard liegen soll und so weiter. Oder zum Beispiel auch den Hostname des Systems, wenn man nicht

den full qualified Domainname nutzen möchte. Das sind alles Konstanten. Einfach mal in der Doku nachschauen. Also diese ganzen, die Fault-Konfig-Werte, die man aus der alten Isingar-Konfig oder Nagios-Konfig kennt, die sind sozusagen jetzt in Konstanten gewandert, die einfach in der Doku stehen. Und die man überschreiben kann, wenn man so möchte.

Aber man muss nicht mehr an all zu vielen Features drehen. Das interessante hier ist jetzt das Feature Enabled und Feature Available-Verzeichnis. Da sind jetzt wie, wie man es aus der Apache-Welt kennt sozusagen alle Module drin mit ihrer Standard-Konfiguration. Und wenn ich die aktivieren möchte, dann kann ich das einfach mit dem Isingar 2 Enable Feature Tool tun.

Und sag dem einfach, aktiviere mir jetzt das Notification-Modul oder deaktiviere es mir. Und kurz hier. Sieht ihr jetzt zum Beispiel bei dem API-Modul, das ist die Komponente, die mit dem Cluster redet, habe ich dann eben auch die Pfade drin, wo er dann sein

Zertifikat und seinen Private Key findet. Aber dort muss ich dann im Regelfall dann nur was drehen, wenn ich irgendwas wirklich ändere. Schon dannmäßig reicht dann so ein leeres Objekt, um die Fault-Werte nehmen möchte.

Noch einen kurzen Blick auf das Cluster-Werfen, das ich jetzt hier habe. Ich habe jetzt hier zwei virtuelle Maschinen. Isingar 2A und Isingar 2B. Das ist in der Isingar-Welt sogenannte Endpoints, Cluster-Knoten. Und die füge ich dann in zwei verschiedene Zonen ein. Ich habe jetzt hier kein HA-Setup, sondern ich habe einfach zwei Zonen,

die miteinander reden, habe eine Master-Zone und eine Checker-Zone, die dann ein bisschen mehr ausführt. Und das zweite System überträgt praktisch einfach alle Daten und das Hauptsystem. Auf einem Host

in der Zone, der den Checker aktiv hat. Einem der Endpoints. Also die Endpoints führen die Checks aus, nur das Gesamtergebnis wird dann an den Master übertragen.

Also es ging darum, wo denn die Checks ausgeführt werden, ob die auf dem Master oder auf dem Endpoint ausgeführt werden. Also sozusagen immer das Endpoint oder eine ist dafür zuständig, den Check durchzuführen und alles andere wird dann über die Cluster-Schnittstelle übertragen.

Aber im Endeffekt, wenn ich jetzt einfach sage, ich habe zwei Isinga-Systeme, ich habe ein Hauptsystem, also jetzt meine Isinga 2a wäre, ich habe an dem Z-System Isinga 2b, ist im Prinzip das, die ganze Konfig, die ich brauche, um diese beiden Systeme zu verbinden.

Also es geht, die Frage war, ob ich die Checker so konfigurieren kann, dass der Status nur schlecht ist,

wenn beide Checker feststellen, er ist schlecht. Das ist also nicht so, sondern es wird einfach einer der Checker, aufgrund von dem Hasch-Algorithmus, dafür zuständig sein, diesen Check auszuführen. Das kommt im Prinzip das Ergebnis immer vom gleichen Server. Wenn man da eben so Netzwerkszenarien hat, ich kenne das durchaus von Kunden,

dann muss man das Problem anders lösen. Im Prinzip ist es ja ein instabiles Netz. Aber im Endeffekt, diese zwei Zonen, ich könnte jetzt auch in diese Checker-Zone noch einen zusätzlichen Endpoint reinsetzen, der dann einfach dort zum Loadbalancing ausführt und hätte die so verbunden.

Und die Instanzen versuchen einfach untereinander zu connecten, je nachdem wer es zuerst versucht. Die Konfiguration hier befindet sich jetzt in zwei verschiedenen Verzeichnungen. Es gibt zum einen das Zones-D-Verzeichnis, das enthält eine Objekt-Konfiguration

für diese Zone. Und es gibt das Conf-D-Verzeichnis, das enthält die kompletten globalen Settings. Beispielsweise meine User, die ich habe, Kommandos, die ich benutze, Gruppen, Notification-Regeln und so weiter. Dann wollen wir mal kurz hier in Notifications reingucken.

Das ist jetzt ein Beispiel hier, wie ich eine Notification auf Hosts anwende. Ich sage nämlich, oder auf Hosts und Services, ich sage, ich möchte per E-Mail notifiziert werden, weil ein Host ein Problem hat, der die Variable SLA auf 24.7 hat. Dadurch kann meine ganzen Dev-Maschinen und sonstige Maschinen, die ich habe, tatsächlich einfach einen anderen

SLA-Wert und höre nichts von ihnen. Sondern sie ist halt im Web-Interface. User-Gruppe eSinker-Admins ist einfach nur dafür da, um zu sagen, welche User und daraufhin kriegen die eine Mail, wenn sie halt ein Mail-Attribut gesetzt haben.

User-Definition. Und wenn wir jetzt mal einen Blick in die Checker-Zone werfen,

sehe ich jetzt hier zum Beispiel eine Konfiguration, wie ich E-Sinker 2b, also dem Host,

monitorte ich selber. Und ich habe jetzt hier einen Service, den ich einfach direkt diesem Host designe, weil es ein spezieller Check ist. Das sind jetzt hier Beispiele davon. Cluster eSinker sind Internet-Checks, die sozusagen den Cluster-Zustand, Monitoren des Systems. Und ich hatte das Demo

gerade auf. Und Plugins können verschiedener Arten angegeben werden. Hier oben haben wir jetzt zum Beispiel Check-Commandos gesetzt, wo ich jetzt inline sagen kann, führe mir einen Echo-Befehl aus. Oder führe mir einen Skript aus, das ich irgendwo habe. Check-Commando MySQL

ist jetzt hier parametrisiert, sieht man. Das heißt, ich habe an der Stelle Standardwerte für Database, für Username und für Password. Kann das natürlich ändern, wenn ich das möchte. Bisschen tiefer, wo das verwendet wird.

Und verwende jetzt praktisch in der Stelle einfach das MySQL Check-Commando. Sage, das ist in den Service-Gruppen

Datenbank drin. Zu Groups ist jetzt hier nicht die Host-Groups, sondern die Datenbank. Und sage, Assigne mir das wo ich ein Template habe, das MySQL Demo-Host heißt. Und wenn ich das jetzt möchte, könnte ich jetzt praktisch hier sagen,

ich hätte jetzt sozusagen die Default-Werte des Checks überschrieben. Ich muss mich nicht mehr darum kümmern, welche Reihenfolge die Argumente sind, sondern die müssen einfach angegeben werden und fertig.

Also, wen das genauer interessiert, wie diese Config aussieht, in der Dokumentation sind unglaublich viele Beispiele, wie diese Objekte unter anderem funktionieren.

Den letzten Teil habe ich nicht verstanden. Die Frage war, wenn ein Argument leer ist,

was macht er dann? Es gibt zwei grundsätzliche Möglichkeiten. Es hat auch was damit zu tun, wie Check-Plugins funktionieren. Die meisten Check-Plugins sind so gepolt, dass wenn ein Host-Argument leer ist, also beispielsweise beim Check-HTTP- minus H für den V-Host und minus I für die IP-Adresse

des Systems, da jetzt sozusagen die IP leer lässt, dann nimmt er einfach sein Default. Deswegen setzt man im Check-Kommando das auch immer in einfache Anführungszeichen, dass du sozusagen ein leeres Argument hast und das Check-Kommando muss einfach verstehen, was ein leeres Argument ist. Machen nicht alle, aber das funktioniert

mit allen Monitoring-Plugins, die ich bisher gesehen habe, nur ganz wenige nicht. Das heißt, du hast einfach ein Minus-H-Soament, der da drin steht. Eine Sache zeige ich noch. Es gibt einen

Wir haben einen ganzen Katalog von Check-Plugins mitgeliefert. Die sind also installiert, sobald man sich das Paket installiert und findet dann, sagen wir kurz, RTTP, findet ihr jetzt also für diese ganzen Standard-Monitoring- und Agios-Plugins hier Beispiele. Hier ist jetzt auch ein schönes Beispiel für diese SSL-Variable.

Das ist ja einfach ein Schalter und kein Wert dahinter. Hier haben wir einen Trick gemacht. Wenn du die Variable HTTPSSL setzt, dann wird der Schalter Minus-S mitgegeben.

Hier sind ganz viele Beispiele dabei. Diese Standard-Objekt- Checks findet man alle im Source-Tree. Die Konfiguration, die ich hier habe, ist in unserer Vagrant-Box enthalten. Bei unserem Git kann man sich einfach auschecken, Vagrant up und hat eine wunderschöne Testform zum Spielen.

Das war Absturz. Und hat praktisch auch wunderschöne Beispiele dafür. Und alle anderen fragen wir irgendwelche besonderen Parameter, welche Standard- Attribute so ein Objekt einfach hat. Findet man alles in den Docs von Islinger.

So. Nächster Punkt. Wie fange ich mit Islinger 2 an? Auf docs.islinger.org slash Islinger 2 ist die komplette Dokumentation. Islinger 2, wunderschöner Web-Viewer hoffentlich. Für euch

die kompletten Befehle von wo kriege ich das her, aus welchen Repositories, wie muss ich es mir installieren, wie sieht die Konfiguration aus, welche Objekte gibt es. Gibt es alles in den Docs? Wenn irgendwas fehlt oder ihr falsch findet, bitte Ticket aufmachen. Wir haben einen Haufen Aufwand darin investiert, Pakete zu bauen. Es gibt einen

Build-Server von uns auf Jenkins-Basis, der sowohl für Release-Versionen als auch für Snapshots Pakete baut und veröffentlicht. Es gibt mittlerweile auch Nativ für Debian-Pakete, also so eine offizielle aus dem Debian-Projekt. Wir sind mit Islinger 2 Nativ in Jessie drin. Wir werden es hoffentlich auch in den Stable-Release schaffen.

Visi gibt Backports und es ist vom Debian-Projekt auch offizielle Release-Pakete. Wer Ubuntu einsetzt, bitte nicht Universe benutzen, sondern die PPAs von Formora ist leider nicht hier. Alexander Wirth, auch aus dem Debian-Projekt. OpenSuse, habe ich gesehen, hat es jetzt

Bild-Server offiziell drin. Ob das jetzt in den OpenSuse-Release kommt, weiß ich nicht ehrlich gesagt. Aber da gibt es auf jeden Fall eine zuverlässige Quelle. Und in Fedora werden wir wahrscheinlich noch 1-2 Monate brauchen, bis es da was im neuen Release gibt.

Islinger Web 2. Hier ist die Frage, warum noch ein Web-Interface? Wir haben also in der alten Welt ein Klassik-Interface, was aus den Nagios CGI entstanden ist. Es ist halt noch da. Es gibt unglaublich viele Leute, die es benutzen,

weiß ich, weil es einfach einfach ist, es funktioniert. Es gibt in Islinger Web 1, Web-Interface, das für den Standard-User ziemlich groß ist. Es ist ziemlich monolithisch, es ist ziemlich langsam teilweise. Funktioniert auf der Datenbank.

Keiner versteht die Konfiguration, leider. Wir haben gesehen, es gibt irgendwie Probleme. Wir haben zum einen die Klassik-Welt, die hört irgendwann auf zu funktionieren. Wenn ich dann so, sage ich mal, 3.000 Hosts mit 7.000 Services drin habe, dann ist das Ding langsam. Man merkt es nicht so oft,

wenn man Glück hat, durch einen guten Rechner läuft es, aber es ist deutlich langsam, als es sein könnte. Und das Islinger Web ist auf der anderen Seite ist ein System, das für den Einsteiger-User zu groß ist, zu kompliziert, zu unübersichtlich und einfach viel zu schwer einzurichten ist.

Es gibt ein Islinger-Mobile-Interface, so als Webseite gedacht, also keine App, sondern eine Webseite. Das haben wir vor 3, 4 Jahren angefangen, hat seitdem keiner mehr angefasst. Und es gibt andere Interfaces, Struck zum Beispiel. Wir haben einfach versucht,

die Probleme von unseren eigenen Interfaces, dass es kein Mobile-Interface gibt, dass es ein langsames Web-Interface gibt. Und dass der alte Islinger Klassiker, der ist auch nicht so schön. Es gibt auch den einen oder anderen CVE-Leiter, den wir fixen mussten. Wir haben versucht, etwas Besseres daraus zu machen. Daraus ist Islinger Web 2 entstanden.

Ist auch komplett neu entwickelt. Ich habe vorhin gehört, vom vorigen Vortrag, wo ich immer da war, über PAP wird oft gelästert. Wir haben es in PAP gemacht. Ich hoffe, du hast uns nicht dafür.

Aber mit der Idee dahinter, es möglichst kompakt zu gestalten, sodass man auch damit arbeiten kann. Wir haben versucht, ordentliche PAP-Objekte zu machen, eine ordentliche Klassenbasis für PAP zu schaffen, die man selber programmatisch verwenden kann, um sich sein eigenes Dashboard zu basteln. Und ein Web-Interface zu machen,

das schnell ist, einfach und für jeden benutzbar ist. Sowohl für den kleinen Mann, der seinen eigenen Server, der irgendwo bei 25.000 Systeme damit überwachen will. Und wir unterstützen mehrere Backends.

Wir unterstützen sowohl die Status-Dat, also wirklich plane, Raspberry Pi, Minibox, tut nichts. Funktioniert das. Wir können mit Live-Status reden. Theoretisch auch mit Islinger 1 auf Live-Status, genauso weiterhin. Wir unterstützen die IDO als Datenquelle, weil das unser,

das einfachste ist, wenn man wirklich große Systeme hat, das in der Datenbank auswählbar zu haben. Und wir können diese Backends auch als Failover benutzen. Also ich kann meine Datenbank als Standardziel definieren, und wenn die nicht mehr funktioniert, dann habe ich Live-Status. Und kann mich erst mal darum kümmern, die Datenbank mit das laufen zu bringen. Und, wie man so schön sagt,

ein responsive Interface. Ohne groß Parlava, werfen wir einen kurzen Blick auf die Demo. Ich hoffe, das ist nicht wieder abgeschnitten. Ich muss dazu sagen, Islinger 2 ist noch nicht fertig.

Es ist in Entwicklung. Wir möchten dieses Jahr noch einen Release machen damit. Einen stabilen Release, der funktioniert. Und sind momentan noch sehr stark am Arbeiten daran. Grundsätzlich funktioniert es. Man kann sich das installieren. Es gibt auch die ersten Snapshot-Pakete jetzt dafür. Man kann es sich aus dem Git relativ einfach installieren.

Und auch damit experimentieren. Ich habe also hier ein Dashboard, wo ich meine ganzen Probleme sehe. Ich sehe, wann Status sich erholt hat von Systemen. Ich sehe, welche Hostdown sind. Und kann in diesem Interface sehr einfach hin und her klicken. Das Ganze ist sehr kompakt.

Ich kann hier hin und her schalten. Ich kann mir die Services eines Systems anzeigen. Also die Idee hinter dem ganzen Interface ist einfach schnell zu sein und eine gute Übersichtlichkeit zu bekommen. Sieht dann auch bei einem einfachen Kontext,

wo man auch Copy- Pasten raus kann. Sieht hier schön den Check-Output. Kann hier direkt Kommandos machen. Hat die Möglichkeit, den Check genau mit einem Klick auszuführen. Also kein Formular, das sinnlos ist. Kein Force-Check mit Zeitstempel.

Sondern einfach Klick. Wir haben dann doch noch Formular gebraucht für Acknowledgements. Weil man muss ja noch irgendwie sein Senf dazu abgeben. Aber an sich kann ich hier mich durch meine komplette Monitoring-Landschaft klicken. Wir experimentieren momentan auch ein bisschen so mit, wie ein Dashboard funktionieren könnte. Was würde ich gerne sehen,

um zu wissen, wie sieht meine Umgebung aus? Da ist noch ein bisschen was am Bauen. Es gibt zum Beispiel dann solche Ansätze, hier so eine Service-Matrix zu bauen. Es sieht jetzt nicht so spektakulär aus auf dem Interface. Aber stellt euch das mal vor, ihr habt eine sehr große Landschaft und ihr habt irgendeine Störung. Klickt auf die Service-Matrix und seht, dass fünf Server

den gleichen Service auf Rot haben. Also ganz nett. Und man kann auch diese ganzen Ansichten, ihr seht das oben in der URL, da hängen Parameter hinten dran, die kann ich ändern. Also ich kann jetzt zum Beispiel auch hier diese Service-Matrix, mache ich jetzt den Parameter weg. Dann sehe ich das für alle.

Ich sehe dann auch, wo meine Services verteilt sind auf den Maschinen. Und ich kann dann hier auch filtern nach bestimmten Argumenten. Ganz einfach. Ganz einfach URL.

Die Benutzerverwaltung sieht momentan in drei Formen vor. Man kann per LWAP authentifizieren. Man kann sich auch die LWAP-Gruppen reinholen. Da arbeiten wir noch dran. Es gibt eine Datenbank, wo man einfach die User reinlegt. Und man wird auch, das ist noch in Entwicklung, die User einfach im EE-Gatei anlegen können.

Oder man schaltet irgendwas per Patchy davor. Die Frage war, wie ich die Sichten

einschränken kann. Das wird so in etwa ein Mix sein aus der Isingar 1 Klassikwelt. Und dem wegen, wie es in Isingar Web 1 machen kann. Also im Endeffekt wird es sein, dass man einer User-Gruppe in dem Web-Interface sagt, was ich sehen darf. Beispielsweise, dass man eben dann auch matcht, wo bin ich denn Kontakt davon, wo kriege ich

irgendwie Notifications. Oder dann einfach halt Regeln setzen kann, und diese User-Gruppe darf bestimmte Host-Gruppen sehen. Also da ist der Ansatz relativ flexibel. Wer sich das mal mit Isingar Web 1 angeschaut hat, da ist es eigentlich recht nett. Problem ist, dass die API dahinter so komplex ist,

dass das entwickeln ultra hässlich ist. Aber für den User funktioniert es sehr gut. Aber da gibt es eben auch verschiedenste Ansprüche, wie das funktioniert. Weil, wenn Sie möchten, das Leute dann anhand von variablen Aufhängen oder Host-Gruppen oder so machen. Aber ich kenne durchaus viele Firmen, die machen gar keine Einschränkungen. Die limitieren einfach, wer darf sich

in Isingar einloggen, und das war's. Also ich kenne eine Bank, da kann sich die komplette IT einloggen und sieht alles. Es sollten eigentlich auch keine sensitiven Daten drin stehen. Ich sage sollte. Was in dem Web-Interface hier noch recht nett ist, muss mich ein bisschen sputen,

dass es so ein bisschen Wir haben also versucht, die Historie ein bisschen brauchbarer darzustellen. Ich habe da irgendeinen Lok, das wird so ein bisschen gepasst, aber ich muss mich trotzdem anstrengen, das Ganze zu lesen. Sondern wir haben versucht, es so darzustellen, dass man auf einen Blick sieht, was ist mit dem System passiert. Und mir auch jetzt bei dem

Service Check im die Historie visualisieren kann. Dass ich auch in einem Blick sehe, das hat sich jetzt der State geändert, da wurde eine Notification verschickt, das ist auf Warning auf Unknown, auf Critical gegangen. Dass man das relativ nett sieht und dann halt entweder mit einem Zeitstamm

dahinterlegt ist, oder wie hier oben dann mit, das ist halt 50 Sekunden auf Unknown. Also visuell, dass man das Ganze relativ schnell versteht. Es gibt auch hier so ein paar Experimente, eine Timeline darzustellen, das sieht jetzt in meiner VM eigentlich total unspektakulär aus. Aber dass ich sozusagen für mein

komplettes Monitoring-System sehe, was sind da Events, zu welchen Zeiten passiert und wie viele. Also wie gesagt, da findet sehr viel Experimentierbarkeit statt. von den System-Sachen ist Single Web 2 so gemacht, dass man eigentlich keine Datenbank braucht dafür.

Sondern die komplette Konfiguration des Systems, sei es welche Menüelemente es gibt, sei es welche Module aktiv sind und so weiter. Das ist alles auf File-System, ist alles in Anyfiles hinterlegt. Die kann man von Hand bearbeiten, die kann man hier über das Web-Interface bearbeiten. Also ich kann dann hier auch

meine Authentication einstellen, habe in dem Fall jetzt Ressourcen, die dann die Datenbankverbindungen für User in dem Fall festlegen, die die IDO festlegen. Also der ganze Ansatz davon ist, die ich leicht versteht und leicht bearbeiten kann.

Das Web-Interface hat das mit dem Cluster nicht viel zu tun. Das sind dann Punkt-D-Verteilen.

Okay, die Frage war, wie ich Konfig verteile. Das habe ich nur kurz auf die Konsole. Das ganze ist so gedacht,

dass ich Konfiguration zentral erzeuge und dann auf andere Systeme verteile. Da gibt es bei diesem API-Listener, bei dieser Komponente gibt es eine Accept-Konfig. Das heißt, es gibt ein System, das liest die Konfiguration aus und pusht sie über die Cluster-Schnittstellen nach alle anderen Systeme. Also das Confd-Verzeichnis landet dann alle

des Zonenverzeichnisses in den entsprechenden Zonenendpoints und dadurch kann ich Konfig zentral erzeugen. Du musst nur einen Kern reloaden und der pusht das um alle anderen weiter. Das funktioniert sehr, sehr schön. Bei dem Webinterface ist es eben so, dass ich einfach hergehen kann und mir ein zentrales Webinterface

aufsetze. Das holt sich dann per Live-Status oder per Datenbank die ganzen Daten, die halt das zentrale System hat her. Oder ich setze mir ein zweites Webinterface in meinem Standort in den USA auf und der liest dann entweder nur Live-Status, weil ich keine Datenbank dort brauche mit History oder ich schreibe dann dort noch eine IDO raus, die aber nur in dieser USA-Zone praktisch drin hängt.

Das ist relativ harmlos. Wir haben es auch relativ leicht gemacht, da modular ranzusetzen. Also man muss ein bisschen PHP verstehen und dafür die Objektlogik von dem ganzen System verfolgen. Aber man kann da relativ einfach mit PHP und ein bisschen

HTML-Template Sachen reinskripten. Das war uns der große Ansatz, dass Aldi Sinkerweb 1 ein mega Framework, das keiner versteht. Und ich brauche im Prinzip hier nur ein paar PHP-Klassen, schreibende Funktionen und die gibt mir irgendwas per HTML aus.

Ansonsten, alle URLs, die man aufruft, sind alle über die über die Uhrzeile sichtbar. Man sieht dann auch hier, hat man dann so eine Trennung von zwei Spalten mit einem Hash-Ausrufezeichen. Man kann jetzt im Prinzip einfach hier diesen vorderen Teil nehmen und hat dann nur die rechte Spalte.

Also man kann sehr, sehr schön mit URLs arbeiten. Was gibt's noch? Eine wunderschönes Tool für Leute, die die Bash mögen oder sonstige Shells. Ist auch noch nicht fertig, aber ich kann

auch über die Kommandozeile mit Isingas Web 2 arbeiten. Ganz wichtig, das ist ein CLI-Tool, das nicht von Isingas 2 ist, sondern von Webinterface. Es soll aber dazu gedacht sein, dass man sowohl Daten auslesen kann aus dem Interface, als auch dann später Kommandos darüber absenden kann. Also einfach ein

Acknowledgement auf der Kommandozeile setze und mich nicht darum kümmern muss, wie ich siege jetzt. Das kannst du im Prinzip überall dort machen, wo auch ein Webinterface laufen kann.

Das Ganze ist die CLI sozusagen ein extra Application neben dem Webinterface, das die gleichen Objekte benutzt und die gleiche

Konfigurationslogik. Das heißt, die Ressourcen, welche Instanzen es gibt, ob Datenbank, Live-Status, wo hin er Kommando schreiben muss, ob in eine einfache lokale Pipe oder über SSH, das ist alles in dieser Konfig hinterlegt. Und wenn du dir das dann auf deiner lokalen Workstation einrichtest, dass der das dann per SSH auf den anderen System rüber schaufelt,

geht das. Kann die ...

Ihr seht, nicht fertig. Das ist was für Mordsch. Alle zwei

Sekunden. Also wenn ihr da noch Ideen habt, sagt Bescheid. Schaut euch das an, was wir haben. Und zum Schluss noch, Zukunft von Isingar 1. Das Projekt wird nicht sterben. Wir haben allein selber das Interesse, weil wir

viele, viele auch Kunden und User haben, die Isingar einfach noch benutzen werden, auch in den nächsten Monaten und wahrscheinlich auch noch Jahren. Deswegen wird das ganze Projekt nicht einfach sterben, sondern wir werden einfach versuchen, weiterhin Bugfixes zu betreiben, Probleme zu fixen, vielleicht das eine oder andere kleine Feature reinzubringen, je nachdem, was so kommt. Aber es wird sicherlich irgendwann auslaufen.

Muss man klipp und klar sehen, aber wir sprechen halt nicht davon von einem Jahr, sondern vielleicht von zwei, drei Jahren, dass das Ganze noch irgendwie laufen wird. Isingar 2 kommt in der nächsten Woche, Isingar 2.1 raus, als erstes Feature Release, nach dem Hauptrelease.

Da geht es hauptsächlich um Verbesserungen im Cluster, die so über einen Bugfix hinausgehen. Ein bisschen Locking, viel Dokumentation, die aber schon öffentlich im Netz ist sozusagen. Und was so für die Zukunft geplant ist, ist ganz viel in Richtung Add-ons reinzubauen. Logiken, die in der alten Nagelswelt sehr kompliziert waren, sozusagen jetzt

zentral in das System aufzunehmen, wie Business Process. Ein besserer Agent steht auch auf der Agenda. Wer da Ideen hat, Wünsche, es gibt einen Bug, bitte kommentieren. Und wir haben mittlerweile mit sehr vielen Leuten gesprochen, die mittlerweile auch Plugins und Module für Ansible, Chef etc.

schreiben. Wer da Interesse hat oder wer da irgendwas hat, bitte bei mir melden. Es gibt schon einiges, wer da Interesse hat. Also unsere Roadmaps sind im Internet. Unser DevTracker ist komplett offen, von jedem lesbar. Und es gibt einen Haufen URLs, wo man Informationen über SYNGA findet.

Wer jetzt noch Fragen hat, wir sind, glaube ich, mit der Zeit fast rum. Ja, Fragen, ja. Also deine Frage zielst

hauptsächlich auf Konfiguration, Interaktivverarbeiten. Also wir haben uns am Anfang die Frage gestellt, wie machen wir die Konfiguration?

Wie machen wir die Konfiguration so, dass du nur über den API damit redest oder machen wir die Konfiguration in Textfiles? Und wir haben uns halt eben deswegen vor Textfiles entschieden, weil jeder dann damit arbeiten kann. Und für deinen Zweck würde ich halt vorschlagen, dass du dir irgendwie überlegst, wie generiere ich meine Config-Daten an? Oder zumindest den Host-Teil davon, dass du dir den irgendwie

rausgenerierst aus was? Sei es aus einer Datenbank, die du selber machst und da halt damit arbeitest. Weil wir haben keinen guten Ansatz gefunden, um so eine wirkliche komplette Config-API in die Singer 2 abzubilden. Was eventuell kommen kann in Zukunft ist, dass wir sagen, wir haben eine API, über die du das machen kannst,

die dir dann aber nichts anderes tut, als dann ein Textfile rauszuschreiben. Also im Endeffekt die Cluster-Config funktioniert auch so, dass das echte Config-Files sind, bloß dass die halt so dann gemerged in einem File übertragen werden. Und das Zielsystem passt die dann. Da gibt es ein extra Alib-Verzeichnis, wo dann diese Config-Files drin liegen

und im Endeffekt wird es auf die Schiene rauslaufen. Also das ist zwar eine API hast, um es anzulegen, aber im Endeffekt ist es dann genauso Textfile. Ja.

Deine Frage war, Isingar Web 2 mit Isingar 1 laufen zu lassen. Ist überhaupt kein Problem, geht es über Statustart. Man muss also, mal kurz, solange ich noch nicht rausgekehrt werde.

Das ist natürlich jetzt kein Statustart. Ich kann hier eine Statustart-Ressource anlegen mit Fahrt zu Statustart und Cache. Und wenn das Webinterface die findet und lesen darf, funktioniert es genauer.

Gearman in Isingar 2 wird es nicht geben. Brauchst keine Worker mit Isingar 2.

Also Isingar 2 ist von der Architektur in diesem Demon so, dass du beliebig viele Checks ausführen kannst. Wir haben experimentiert mit Checkintervallen von einer Sekunde. Dein Limit ist an der Stelle eigentlich nur die Gesamtrechendeistung des Systems, die Checks auszuführen parallel.

Und dann kannst du weitere Systeme verteilen. Aber der Core an sich hat praktisch keinen Bottleneck mehr vom Schedulow oder so. Also wer sich mal mit Isingar 1 oder Nagels tiefer auseinandergesetzt hat, der macht da ganz böse Dinge, um Checks wegzuforgen. Und diesen ganzen Overhead mit Klonen und hin und her, das gibt es nicht mehr.

Sondern das ist alles geswettet und die ganzen Checks sind alle über V4 Gras gestartet, also sehr sehr schnell. Das mit dem Check auf einem anderen System auszuführen, das ist die Zonenlogik. Oder dass du eben einen DMZ-Host oder einen Standort-Host definierst, da ist ein Isingar 2 installiert,

der redet mit dem Master-System, bekommt vom Master-System die Konfiguration, aber checkt halt nur für das, wo das der Zustand ist. Und das Master-System sieht alles. Genau. Der nächste Kollege steht schon hier.

Er, wer noch Fragen hat, gerne vorne oder draußen. Ansonsten vielen Dank für die Aufmerksamkeit.