Weekly Snap: LConf 1.3.0, DevOpsDays-Berlin & Gource

weekly snap27 – 31 May ended the month with an LConf release, DevOpsDays, Git animations and a worthy cause to support in Uganda.
Bernd reported back from DevOpsDays in Berlin, raving about the ignite talks on the first day and evening speakers drink-up event.
Meanwhile, Michael released LConf 1.3.0, the LDAP-based configuration addon for Icinga and Nagios, boasting a bunch of new features and simplified packaging.
Lastly, Thilo discovered Gource Git animations as Vanessa pulled on our heartstrings to help orphans in Uganda through donations to the ‘Kindern eine Chance’ (Children a Chance) NGO.

Besser spät als nie …

LConf_LogoJa, es ist schon fast zu spät für einen Blogpost vor dem wohlverdienten Wochenende, aber Icinga 1.9 als Core Release Manager steht an, sowie auch Icinga2 vorankommen muss. Aber es gibt da noch ein Tool, was sich aktiv in der Entwicklung befindet – LConf.
Nicht zu verwechseln mit LConf für Icinga Web, dem schönen Web Interface mit komfortablen Features wie Drag&Drop. LConf ist ja eigentlich für einen grossen Kunden entwickelt worden, und erfreut sich seither wachsender Beliebtheit (was wohl auch daran liegt, dass man damit schöne Icinga Distributed Setups bauen kann, aber dazu später mehr).
Es gibt nun schon eine Weile das Release 1.3.0rc und neben den schon angesprochenen Performance Verbesserungen (und Templates in die Vererbung miteinbeziehen zu können) gibts noch einige Veränderungen, Fixes und Features die seither eingeflossen sind:

  • der Export der Konfiguration aus dem LDAP Baum kann nun (optional) durch Child Prozesse parallelisiert und damit beschleunigt werden. Der Defaultwert sind 2 Prozesse um den Monitoringserver nicht allzusehr zu stressen. Soll heissen, wenn man 24 Cores zur Verfügung hat, und LConf Export 12 Childs erlaubt, lässt sich ein 13000 Service Export auch mal ums 2,5fache verringern. Das ist also insbesondere in grossen Umgebungen interessant, und bringt neben der verminderten Anzahl an LDAP Abfragen im Vergleich zu 1.2 einen erheblichen Geschwindigkeitsvorteil.
  • beim Export lassen sich benutzerdefinierte Scripts ausführen. Dies wird zB dazu verwendet, um für jeden Host/Service eine Custom Variable mit der LDAP DN zu setzen, um dann später vom Service im Icinga Monitoring direkt in die LConf Baum Konfiguration zu springen. Diese Idee kann man aber noch weiterspinnen und eigene Custom Variablen und andere Attribute exportieren. Sinn macht das insbesondere für verteilte Umgebungen, wo man beispielsweise anhand von Servicenamensmustern dann Standortmuster erkennt und diese als Customvariable abspeichert. Neben der Scripts die die Slave Konfiguration beinflussen, gibt es jetzt auch eine mid-master.pl die lediglich die Master Konfiguration manipuliert (zB dort alle Checks als passiv setzt, o.ä.)
  • LConfSlaveSync als Checkresultsammler kann nun übrigens auch direkt das Icinga Checkresult Spooldir schreiben, um blockiert somit nicht die External Command Pipe. Die Option directIO ist auch in Zukunft so gesetzt.
  • Custom Variablen können nun verwendet werden, um dynamische Objektnamen zu generieren. Also beispielsweise wird die Service Custom Variable “_PORT 1337” aus “http_$_SERVICEPORT$” den sprechenden Namen “http_1337” erzeugen. Was man da dank Vererbung im LDAP Baum dann alles anstellen kann….
  • der gewisse Mehrwert, den Software haben muss – Pakete die einfaches Installieren/Upgraden erlauben. Dementsprechend haben wir in schon in Kundenprojekten Pakete für LConf gebaut (und tun das auch (auf Anfrage) für all unsere Addons), und gleichzeitig auch notwendige Änderungen an der LConf Struktur vorgenommen. So sind etwa alle Scripts in bin/ installiert, während die Perl Module in lib/ ihren Platz finden, var/ und tmp/ dienen dem Export als Ablage und in etc/ findet sich die Konfiguration wieder. Die meisten Optionen sind nun via configure Parameter einstellbar – ich halte das ähnlich wie bei meinen Icinga RPMs – wenns mich nervt, bau ichs passend Upstream richtig. Das heisst also nun folgerichtig – auch LConf Pakete sind in Vorbereitung (auch LConf für Icinga Web ist entsprechend angepasst worden). 
  • Alle bisherigen Änderungen sind in doc/UPGRADING dokumentiert. Das betrifft auch Änderungen im Vergleich zur 1.3.0 RC.  alle Tester bitte vor der Installation konsultieren. Achja, wir unterwerfen uns gitflow, weswegen der brandaktuelle Entwicklungszweig auch immer im GIT Branch next (als Snapshot) zu finden ist 🙂

Die alles umfassende Frage – wann kommts denn nun? Nun, bald. Ob Juni realistisch ist, wage ich mal zu bezweifeln, aber die Hoffnung stirbt ja bekanntlich zuletzt. Feedback und Tester sind natürtlich jederzeit willkommen, um den Entwicklungsprozess zu beschleunigen! 😉
Für all jene die bis jetzt durchgehalten haben, noch ein kleines Anschauungsbeispiel wie man LConf in verteilten Umgebungen ebenso implementieren kann.
Folgendes Beispiel erkennt anhand des Musters “denu” dass die deutsche Location “Nuernberg” als Customvariable zu setzen ist, sofern der Hostname darauf passt. Um später auch die Services danach zu filtern, wird diese Customvariable direkt im Anschluss auch an diese vererbt. Das Script wird als mid.pl im Order custom/ abgelegt (kann via configure –with-export-script-dir angepasst werden).

sub CustomMid {
    my $changes = {
        'denu' => {
            '_LOCATION' => 'Nuernberg'
        }
    };
    my $CLIENTS = shift;
    foreach my $client (keys %{$CLIENTS}) {
        foreach my $hostChange (keys %{$changes}) {
            if ($CLIENTS->{$client}->{cn} =~ /$hostChange/) {
                foreach my $cv (keys %{$changes->{$hostChange}}) {
                    $CLIENTS->{$client}->{lconfhostcustomvar}->{$cv} = $changes->{$hostChange}->{$cv};
                }
            }
        }
        foreach my $cv (keys %{$CLIENTS->{$client}->{lconfhostcustomvar}}) {
            foreach my $service (keys %{$CLIENTS->{$client}->{SERVICES}}) {
                $CLIENTS->{$client}->{SERVICES}->{$service}->{lconfservicecustomvar}->{$cv} = $CLIENTS->{$client}->{lconfhostcustomvar}->{$cv};
            }
        }
    }
}

Diese Custom Variable könnte man nun als Auswahlkriterium sehen, dass auf dem Icinga Slave in Nürnberg all diese Host und Service Checks durchgeführt werden sollen (natürlich könnte man das auch via LCONF->EXPORT->MODIFY lösen, aber dieser Ansatz hier erlaubt freiere Baumstrukturen, die ich lieber mag 😉 ). Hier gibts lediglich ein Problem – LConfSlaveExport kann die Konfiguration nicht anhand von Attributsmustern für die Slaves aufsplitten. Also haben wir uns etwas neues überlegt – LConfSlaveExportRules übernimmt an dieser Stelle.
Folgende Konfiguration in etc/config.pm stellt sicher, dass alle Services mit dem Muster Nürnberg nur an den Slave Satelliten “satelite1.icinga” exportiert werden. Neben den obligatorischen Einstellungen ‘rules’ und ‘targets’ kann man mittels ‘settings’ auch beinflussen, ob Parents und/oder Dependencies auf diesem Slave zum Tragen kommen sollen. Die Erfahrung hat gezeigt, dass zerschnittene Slavekonfiguration nicht für derartige Dinge taugt, und die Logik nur am Monitoring Master sinnvoll einzusetzen ist.

$cfg->{slaveexportrules} = {
   'rules' => {
       'service-rule1' => {
           'object' => 'lconfservice',
           'attribute' => 'lconfservicecustomvar',
           'pattern' => 'Nuernberg'
       },
},
   'targets' => {
       'satelite1.icinga' => {
           'targetDir' => '/etc/icinga/lconf',
           'rulemap' => 'service-rule1'
       },
   },
   'settings' => {
       'slaveexportparents' => 0,
       'slaveexportdependencies' => 0,
   },
};

Der Aufruf in LConfDeploy.sh könnte dann etwa so aussehen (anstatt der Verteilung durch LConfSlaveExport)

(cd $LCONFBINPATH ; $SUDOCOMMAND /usr/bin/LConfSlaveExportRules.pl -v )

Achja, die Custom Variablen kann man in Icinga Web übrigens auch für erweiterte Filter und ebenso Berechtigungen verwenden. Aber dazu ein andermal mehr.
Wie man LConf insbesondere in komplexen verteilten Umgebungen sinnvoll einsetzt, darüber wissen unsere Spezialisten im Consulting bestens Bescheid. Aber auch Schulungen mit dem optimalen Wissenstransfer sind hier nicht zu verachten, denn viele Dinge die LConf kann, zeigt und lernt man am besten persönlich 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Weekly Snap: LConf 1.3, InGraph, Auto Discovery & Devops

22 – 26 October released LConf 1.3, introduced the InGraph web interface, and contributed an article on auto discovery and an opinion on devops.
Most exciting of all, Jannis released the faster, better and prettier LConf 1.3 for Icinga and Nagios LDAP based configuration.
Also from our dev team, Alexander gave us part 2 of the ultimate guide to InGraph, with a little tour of the features in the user interface as Marcus reflected on his apprenticeship in systems integration.
On events, Eva thanked the sponsors that helped make OSMC possible while Bernd reported back from the Nuernberg Web Week that we supported.
Bernd finished a busy week with an article contribution to Admin Magazine on auto discovery (available both in German and English) as well as his opinion on what devops is and isn’t.