Mit coshsh Nagios automatisieren (1)

Datensammler

Die freie Software coshsh erlaubt die Automatisierung von Nagios, indem sie aus beliebigen Rohdaten durch Normalisierung und Regelsätze Nagios-Konfigurationsdateien erzeugt. Wir zeigen die Installation und Inbetriebnahme sowie die notwendigen Schritte, um Daten für die Nagios-Konfiguration aufzubereiten.
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)

Bei immer größeren Serverlandschaften, mehr Automatisierung und mehr Standardisierung bietet es sich natürlich an, auch beim Monitoring jegliche Handarbeit auf ein Minimum zu reduzieren und bedienerlose Prozesse zu etablieren. So soll die Aufnahme von Servern und sonstigen Komponenten in die Überwachung zukünftig nicht mehr auf Zuruf passieren.

Coshsh verstehen

Der Ansatz, durch Autodiscovery das Monitoring auf einem aktuellen Stand zu halten, ist dabei ebenfalls kontraproduktiv, da die Scan-Ergebnisse nicht zwischen Test- und Produktivsystemen unterscheiden, nur mit einheitlichen Passwörtern beziehungsweise SNMP-Communities umgehen können, Applikationen nicht finden, sobald sie keine Default-Ports benutzen, und so weiter. Der Aufwand zur Bereinigung und nachträglichen Einsortierung macht so jegliche Einsparungen zunichte.

Coshsh [1] verfolgt einen anderen Ansatz: Der Ausgangspunkt ist die besagte Inventarisierung, eine CMDB oder ähnliche Datenbasis, die IT-Systeme über die ganze Lebensdauer dokumentiert. Was hier als produktionsrelevant gekennzeichnet ist, wird von coshsh mit Hilfe festgelegter Regeln in Nagios-Konfigurationsdateien überführt. Die Aufgabe von Monitoring-Administratoren beschränkt sich dann auf das einmalige Erstellen solcher Regeln. Voraussetzung ist, dass die gewünschten Services einmal vordefiniert wurden. Coshsh reißt keine Wundertüte auf, wie es besagte Autodiscovery-Tools machen, sondern erfordert eine eindeutige Entscheidung darüber, welche Applikationen mit welchen Services gecheckt werden sollen. Das Monitoring soll dem Wissen über die eingesetzte Unternehmens-IT folgen – und nicht umgekehrt!

Coshsh ist mehr ein Framework denn ein geschlossenes Produkt: Seine Komponenten, die sich beliebig anpassen und ergänzen lassen, sind Python-Klassen und Jinja2-Templates. Eine GUI bringt das Tool nicht mit, die Bedienoberfläche von coshsh ist die CMDB. Die Arbeit mit dem Werkzeug wird erleichtert durch das Verständnis einiger Grundbegriffe:

- Datasource: Auf der Eingabeseite handelt es sich hierbei um eine Python-Klasse, die je nach Gegebenheiten im Unternehmen individuell zu erstellen ist. Die Datasource beinhaltet Code, der beispielsweise eine Datenbank öffnet – also das Inventarisierungstool anzapft, um an Informationen über Hosts und Applikationen zu gelangen.

- Host: Wie aus Nagios bekannt, handelt es sich hierbei um Server, Netzwerkgeräte, Drucker, Storage et cetera.

- Applikation: Eine Applikation gibt es in Nagios nicht als Konfigurationsobjekt. Auf der Eingabeseite von coshsh sollen die Verantwortlichen Inventardaten pflegen. Es wäre zu viel verlangt, müssten sie sich mit Begriffen wie "max_check_ attempts" oder "check_command, check_ period" herumschlagen. Auch der Begriff Service wird hier noch nicht verwendet. Applikationen sind etwa "Oracle 12", "JBoss", "Netweaver 7.x" oder selbstentwickelte Software. Auch "Red Hat 7", "IOS 12", "Juniper JunOS" – also Betriebssysteme und Firmware – fallen darunter. Zu jeder Applikation, die coshsh verarbeiten soll, gehört eine Python-Klasse, die Sie anlegen müssen. Das funktioniert aber auch ohne Programmierkenntnisse, es handelt sich um Grundgerüste. Aufgabe dieser spezifischen Application-Klassen ist es, auf die zugehörigen Jinja2-Template-Dateien zu verweisen.

- Template: Nicht zu verwechseln mit dem Begriff "Template" aus der Nagios-Welt. Ein coshsh-Template ist eine Datei mit der Endung "TPL", die vorgefertigte Nagios-Servicedefinitionen enthält. Allerdings sind diese noch unvollständig. Sie enthalten Variablen, if/else-Konstrukte und Schleifen in Jinja2-Syntax. Services auszuwählen und Templates zu formulieren, ist die verbliebene Arbeit eines Monitoring-Administrators. Aus Templates werden später Nagios-Configfiles. Hier findet der Übergang von der fachlichen Applikation in eine Sammlung von Nagios-Services statt.

- Recipe (also ein "Rezept"): Beschreibt, welche Datasources, Application-Classes und Templates herangezogen werden, um eine Nagios-Konfiguration zu bauen. Oder besser gesagt zu "kochen", denn die Konfig-Datei, die die Recipes enthält, wird Cookbook genannt.

Schematische Darstellung der Funktionsweise von coshsh.

Coshsh installieren

Grundsätzlich können Sie coshsh mit einem Python-Paketmanager installieren, also per pip install coshsh. Damit steht Ihnen das Kommando coshsh-cook zur Verfügung und alles, was Sie benötigen, um Konfigurationen zu erzeugen. Die empfohlene Vorgehensweise ist allerdings, das Monitoring-Framework OMD Labs Edition [2] zu installieren. Dieses enthält neben dem coshsh-Basispaket noch weitere nützliche Dateien und Verzeichnisse, was den Einstieg sehr erleichtert. Die folgenden Anleitungen setzen daher die OMD-Umgebung voraus. Diese ist schnell aufgesetzt [3], Sie benötigen lediglich ein einziges RPM- oder DEB-Paket.

Anschließend erzeugen Sie eine sogenannte OMD-Site, also eine Laufzeitumgebung mit eigener Benutzerkennung, die alle gängigen Monitoring-Werkzeuge enthält. Als Site-Benutzer (wir nutzen im Folgenden die Site "itadm") rufen Sie dann das Kommando »coshsh-prepare-landscape« auf, das einige Vorarbeiten für den Einsatz von coshsh vornimmt:

# omd create itadm
# su - itadm
OMD[itadm]:~$ share/coshsh/contrib/coshsh-prepare-landscape

Der coshsh-prepare-landscape-Befehl erzeugt das Verzeichnis, in das später die generierten Konfigdateien geschrieben werden, und legt einige häufig benutzte Command-Definitionen sowie Service-Templates an. In den Beispieldateien werden wir es mit Service-Dependencies zu tun haben, die Wildcards verwenden. Deshalb müssen Sie abschließend noch in der Datei "etc/nagios/nagios.d/ misc.cfg" die Variable "use_regexp_matching" auf den Wert "1" setzen. Nach einem »omd config set CORE nagios; omd Start« kann es dann mit coshsh losgehen.

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite