Damit Sie als Admin stets über alle Parameter Ihrer IT Bescheid wissen, befasst sich IT-Administrator im Juni mit dem Schwerpunkt 'Monitoring'. Darin lesen Sie ... (mehr)

coshsh erzeugt Konfigurationen

Im Output von »coshsh-cook« finden Sie die beiden Settings "classes_dir" und "templates_dir" wieder. Zusätzlich zu den Pfaden, die die Konfigdatei "itadm.cfg" enthält, tauchen hier aber auch ein "classes"- und ein "templates"-Verzeichnis unterhalb von "/omd/sites/itadm/share/coshsh/recipes/default" auf. Diese Erweiterung der beiden Suchpfade ist eine Dreingabe von OMD, sie enthält sozusagen ein Starter-Kit, um Linux- und Windows-Checks zu generieren und diese rudimentäre CMDB in Form von CVS-Dateien lesen zu können.

Der coshsh-cook-Befehl ist zuerst den Suchpfad "classes_dir" durchgegangen und hat sich die dort vorgefundenen Python-Klassen gemerkt. Eine davon befindet sich in der Datei "datasource_csv.py", nennt sich "CsvFile" und steckt hinter der Datasource vom Typ "CSV". Damit kann coshsh nun mit der Verarbeitung starten:

Schritt 1: Die CMDB beziehungsweise der Satz von CSV-Dateien wird geöffnet und die Monitoring-Items werden gelesen. Hier haben Sie die Möglichkeit, zu filtern und Spaltennamen umzubenennen, um einheitliche Python-Dictionaries zu erzeugen. Diese werden in den nächsten beiden Schritten als Argumente an Host- und Application-Konstruktoren übergeben.

Schritt 2: Jeder Datensatz, der einen Host beschreibt, muss mindestens die Felder "host_name", "address" und "alias" besitzen. Damit wird in der Datasource ein Objekt der Klasse "Host" erzeugt und dieses an eine interne Liste angehängt. Dieser Schritt kann tausende von Malen wiederholt werden. Später zeigen wir, wie Sie eigene Datasources schreiben und auch die Python-Statements für diesen Vorgang.

Schritt 3: Datensätze, die Applikationen beschreiben, also alle Linux- und Win-dows-Arten, Oracle, MS SQL, SAP, Apache et cetera, werden ebenfalls in Form von Python-Dictionaries aufbereitet. Diese müssen die Keys "host_name", "type" und "name" besitzen. Type beinhaltet dabei die oben gennannten Arten von Betriebssystemen und Applikationssoftware. Bei Ersteren ist der Name per Konvention "os" und bei Zweiterem lässt sich eine Bezeichnung wählen, die eine Applikation innerhalb eines Hosts eindeutig macht. Für den Typ Oracle/SAP bietet sich die jeweilige SID an, für Apache der Verwendungszweck, etwa "webmail" oder "app_xy_front-end". Zur Not tut es auch ein technisches Label, das in der CMDB intern verwendet wird. Die Erzeugung eines Application-Objekts ist die Spezialität von coshsh.

Schritt 4: Was passiert, wenn aus so einem RedHat-Datensatz wie im Beispiel-CSV ein Objekt erzeugt werden soll? Die Oberklasse "Application" hat Zugriff auf die Liste der Python-Dateien, die zuvor aus dem "classes_dir"-Pfad zusammengestellt wurde. Schauen Sie sich die Datei "os_linux.py" an, so findet sich hier die Funktion "__mi _ident__" ("mi" steht für "Monitoring Item"), die als Eingabeparameter ein Dictionary bekommt und – falls dessen "name"-Attribut den Wert "os" aufweist und dessen "type"-Attribut mit einem regulären Ausdruck bekannter Linux-Pattern übereinstimmt – als Klasse "Linux" zurückgibt. Es zeigt sich, dass genau das auf die Zeile in der Datei "demo_applications.csv" zutrifft. Und das ist an sich das Geheimnis von coshsh: Es lädt zur Laufzeit eine Sammlung von solchen kleinen Python-Modulen, die sich mit Hilfe ihrer "__mi_ident__"-Funktion für zuständig erklären, wenn Eingabe-Records einer Datenquelle bestimmte Kriterien erfüllen.

Den Aufruf des Konstruktors "Applica-tion()" können Sie auch manuell testen, was ein Objekt der Klasse "Linux" liefert:

OMD[itadm]:~$ python
Python 2.7.5 (default, Nov 6 2016)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from coshsh.application import Application
>>> Application.init_classes(['share/coshsh/recipes/default/classes'])
>>> a = Application({ 'host_name': 'test_host', 'name': 'os', 'type': 'redhat' })
>>> a

 

<os_linux.Linux object at 0x7fee26289810>

Wie die "__mi_ident__"-Funktion Linux erkennt und die passende Klasse zurückgibt, ist in Listing 1 "Rückgabe der Klasse in os_linux.py" nachvollziehbar. Sehr wichtig ist in der Linux-Klasse (wie auch in Windows- und allen anderen Klassen, die Sie erstellen) das Attribut "template_ rules". Es beschreibt eine Liste von Templates, die als Vorlage für die zu generierenden CFG-Dateien dient. Wichtig ist an dieser Stelle, dass es sich dabei nicht um die bekannten Nagios-Templates handelt. Vielmehr sind dies Dateien, die aus Text, Code und Variablen-Platzhaltern in der Jinja2-Syntax bestehen. Zu finden sind sie im Unterverzeichnis "templates", das in "itadm.cfg" bereits als Setting "templates_dir" auftaucht. Alternativ, so wie es hier der Fall ist, sucht coshsh zusätzlich im erwähnten "/recipes/default/templates".

Listing 1: Rückgabe der Klasse in "os_linux_py"



def __mi_ident__(params={}):
    if coshsh.util.is_attr("name", params, "os") and coshsh.util.compare_attr("type", params, ".*red\s*hat.*|.*rhel.*|.*sles.*|. *linux.*|.*limux.*|.*debian.*|.*ubuntu.*|.*centos.*"):
       return Linux
class Linux(coshsh.application.Application):
    template_rules = [
       coshsh.templaterule.TemplateRule(need sattr=None, template="os_linux_default"),
       coshsh.templaterule.TemplateRule(need sattr="filesystems", template="os_linux_fs"),
       ]

In den "template_rules" der Klasse "Linux" finden Sie "os_linux_default" und "os_linux_fs". Hier erwartet coshsh, dass es gleichlautende TPL-Dateien im Pfad "templates_dir" gibt. Diese rendert coshsh später unter Verwendung der individuellen Variablen der einzelnen Application-Objekte und schreibt diese als fertige CFG-Dateien in das "dynamic"-Verzeichnis. Für Host-Objekte gibt es das Template "host.tpl".

Templaterule Nummer 1 besagt, dass für jedes Linux-Objekt ein Template namens "os_linux_default" zu rendern ist. Regel 2 beinhaltet eine Bedingung: Wenn das Linux-Objekt ein Attribut namens "filesystems" besitzt (wie dieses zustande kommt, betrachten wir im Folgenden), dann ist zusätzlich ein Template "os_linux_fs" zu rendern.

Ein Auszug aus "os_linux_default" zeigt, dass sich so ein Template aus Text und Variablen zusammensetzt.

{{ application|service("os_ linux_default_check_swap") }} host_name {{ application. host_name }} use os_linux_default,srv-perf check_command check_by_ssh!60!\$_HOSTSSHPATHPREFIX$/lib/nagios/plugins/check_swap -w 15% -c 8%
}

Zurück zum Application-Konstruktor: Nachdem im Beispiel ein Linux-Objekt erzeugt wurde, hängt coshsh dieses an eine interne Liste von Applikationen an. Anschließend wird noch das File "demo_applicationde-tails.csv" gelesen, dessen Eingabe-Records an einen "MonitoringDe- tail()"-Konstruktor übergeben werden. Um die Bedeutung der Spalten "monitoring_type" (und folgende) zu verstehen, schauen Sie sich am besten die Python-Dateien in "share/ coshsh/recipes/ default/classes" an, die mit "detail_" beginnen.

In Schritt 5 hat Coshsh nun eine Reihe von Listen (Hosts, Applications, Details, Contacts, Contactgroups – vergleiche auch Bild), bestehend aus Objekten, die irgendwie zusammenhängen. Im nächsten Schritt ordnet coshsh diese einöander zu: Applications und Hosts haben das gemeinsame Feld "host_name" und Applications und Details werden mittels "host_name", "name" und "type" verlinkt. Elemente, die nirgendwo dazugehören, sondert coshsh mit einer Fehlermeldung aus.

Im Beispiel-CSV gehören zum RedHat-Datensatz zwei Detail-Datensätze vom Typ "FILESYSTEM". Ein Blick in die Datei "share/coshsh/recipes/default/detail_filesystem.py" gibt Hinweise, was hier passiert: "property = "filesystems"" besagt, dass das Linux-Objekt ein Attribut namens "filesystems" erhalten wird, und "property_type = list" bedeutet, dass dieses vom Datentyp "list" sein wird. Die einzelnen Elemente dieser Liste sind dann Objekte der Klasse "MonitoringDetailFilesystem" und haben die Attribute "path", "warning" et cetera. Nachdem coshsh alle diese Monitoring-Details aufgelöst hat und die Host- und Application-Objekte somit reich an Informationen sind, beginnt die Rendering-Phase.

In einer Schleife über die Objekte der Host-Liste nimmt coshsh jeweils ein Objekt und rendert das Jinja2-Template "host.tpl", wobei es Platzhalter wie "{{ host.address }}" durch die konkreten Werte des Objekts ersetzt. Das Host-Objekt bekommt danach ein neues Attribut, das den Text der fertigen Konfigdatei enthält. Genauso wird mit der Applications-Liste verfahren. Hier erkennt coshsh an der jeweiligen Klasse und deren "template_rules", welche TPL-Dateien zu rendern sind. Zur Verdeutlichung ein Auszug aus "os_li-nux_fs.tpl":

{% for fs in application.filesystems %}
 
{{ application|service("os_linux_ fs_check_" + fs.path) }}
        host_name {{ application.
        host_name }}
...
{% if fs.units == "%" %}
        check_command check_by_ssh!60!\$_HOSTSSHPATHPREFIX$/lib/nagios/plugins/check_disk \ -warning {{ fs.warning }}% --critical {{ fs.critical }}% \ --path {{ fs.path }}
...

Sind Sie mit den vorgefertigten Beispiel-Templates unter "$OMD_ROOT/etc/ coshsh/recipes/default/templates" nicht zufrieden, so kopieren Sie diese einfach nach "$OMD_ROOT/etc/coshsh/recipes/ itadm/templates" – also an den Anfang des Suchpfads – und modifizieren sie nach Ihren Anforderungen. Selbstverständlich ist es auch möglich, die ganzen Service-Definitionen in Icinga2-Syntax neu zu schreiben. Und falls Sie sich fragen, wo die Command-Definitionen zu finden sind, die die Linux-Services nutzen: Diese hat "coshsh-prepare-landscape" nach "~/var/ coshsh/configs/itadm/static" kopiert.

Schritt 6: Nachdem nun alle Host- und Application-Objekte auch den Text der jeweiligen Nagios-Konfigdateien enthalten, legt coshsh in dem mit der Konfig-Variablen "objects_dir" spezifizierten Verzeichnis ein Unterverzeichnis namens "dynamic" an. Darunter entsteht dann für jeden Host ein weiteres Unterverzeichnis, das so heißt wie der Host. In dieses schreibt coshsh zunächst die Datei "host.cfg" mit der host-Definition. Es folgen die zum Host gehörenden Applications, wobei für jedes in den jeweiligen "template_rules" angegebene Template eine Datei mit den service-Definitionen erstellt wird. Und auch die Configfiles für Contacts, Contactgroups und Hostgroups werden in eigenen Unterverzeichnissen abgelegt. Falls "dynamic" als git-Repository vorliegt, werden die Unterschiede zum Zustand vor dem "coshsh-cook" in Form von verschwundenen und neu erschienenen Hosts angezeigt und eingecheckt.

Automatisierung

Der hauptsächliche Einsatzzweck von coshsh ist die kontinuierliche Generierung von Konfigurationsdaten im Hintergrund und eine möglichst fehlerfreie, nachvollziehbare Übergabe des Ergebnisses an den laufenden Nagios-Prozess. Dabei dient das Verzeichnis "/var/coshsh/ configs" als Übergabepunkt zwischen Generator und dem Nagios-Prozess.

Schauen Sie sich in "/var/coshsh/configs" um, finden Sie die Verzeichnisse "static" und "dynamic". Ersteres hat mit coshsh an sich nichts zu tun und wird vom Administrator manuell gepflegt. Es enthält die Definitionen, die sich selten oder nie ändern, in erster Linie Timeperiods und Commands. Wir finden hier unter anderem auch das check_ssh_controlmaster-Command wieder, das in "os_linux_ default.tpl" verwendet wurde. Im dynamic-Unterverzeichnis befinden sich alle Dateien, die mit "coshsh-cook" generiert wurden. Beide Verzeichnisse zusammen bilden einen validen Satz an Konfigurationsdateien für Nagios. Um sie nach einem Generiervorgang in Produktion zu bringen, gibt es unter OMD das Kommando »check_git_updates« .

Als Übergabeskript kümmert sich "check_ git_updates" darum, dass die dynamic- und static-Verzeichnisse nach "etc/nagios/conf.d" gelangen. Beim initialen Lauf werden diese per »git clone« angelegt, bei den folgenden Läufen jeweils mit »git pull« aktualisiert. Letzteres passiert aber nur dann, wenn ein Vergleich der Versions-Hashes in den beteiligten git-Repositories anzeigt, dass ein Update nötig ist.

Nach »git pull« wird zunächst mit »nagios -v« geprüft, ob die neue Konfiguration valide ist. Ist dies der Fall, wird sie mit »omd reload nagios« in Produktion genommen. Schlägt die Prüfung hingegen fehl, dann werden die Änderungen mit »git reset« verworfen, sodass im Nagios-Verzeichnis jederzeit nur funktionierende CFG-Dateien vorliegen. In der Logdatei "var/log/check_ git_updates.log" lässt sich nachvollziehen, wann eine Änderung und ein Reload von Nagios stattgefunden hat.

Damit dieser Automatismus in Gang kommt, richten Sie zwei Cronjobs ein:

OMD[itadm]:~$ cat > etc/cron.d/coshsh <<'EOCRON'
MAILTO=""
* * * * * $OMD_ROOT/bin/coshsh-cook --cookbook $OMD_ROOT/etc/coshsh/ conf.d/itadm.cfg --recipe itadm
EOCRON
OMD[itadm]:~$ cat > etc/cron.d/check_git_updates <<'EOCRON'
MAILTO=""
* * * * * $OMD_ROOT/bin/check_ git_updates
EOCRON
OMD[itadm]:~$ omd restart crontab
Removing Crontab...no crontab for itadm
Initializing Crontab...OK

 

OMD[itadm]:~$

Ab jetzt sollten Sie den "localhost" in der Thruk-Gui sehen können. Ergänzen Sie die CSV-Datei um neue Zeilen, werden die entsprechenden Objekte höchstens zwei Minuten später ebenfalls auftauchen. Das ist ja auch der Sinn von coshsh: Wann auch immer jemand in einer CMDB oder Ähnlichem etwas hinzufügt oder entfernt und coshsh beigebracht wurde, damit umzugehen, wird das Monitoring zeitnah und bedienerlos aktualisiert.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023