NETWAYS Blog

Ja, 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 🙂