coshsh

coshsh
automatische Konfiggenerierung
Gerhard Laußer, ConSol

13.09.16 www.consol.de
Aussprache
2

Wo gibt‘s coshsh?
• Ist in der OMD-Labs-Edition enthalten. labs.consol.de/omd
• pip install coshsh (pypi.python.org)
• git clone github.com/lausser/coshsh
3

Wie entsteht eine Konfiguration?
• Vom Inventar zur Konfiguration
• Ticket-getrieben: "neuer Server ist da, kannst du den mal eintragen?"
• 1-Mann-Firma, Monitoring-Admin = Sysadmin
• Scan + Script
• …
4

13.09.16 www.consol.de5
Was ist coshsh?
Ein Framework, mit dem beliebige Datenquellen angezapft werden können, um
bedienerlos und automatisiert Nagios-Konfigurationsdateien zu erzeugen.
Datenquellen können sein
• CSV-Dateien
• ODF- und Excel-Sheets
• Datenbank von Monitoring-Selbstbedienungsportalen auf Basis von z.B.
Sharepoint oder Oracle-APEX
• Sharepoint-Applikation
• CMDB

Datenquellen enthalten:
• Hosts
so wie bei Nagios. Name und Adresse. Optional Standort, Modell, Abteilung,
• Applikationen
nicht wie bei Nagios. Typ und Name der Applikation / Software.
Das Betriebssystem, die Firmware gelten ebenfalls als Applikation.
Win2008R2, Cisco IOS, Red Hat, OnTap, Tomcat, Oracle, DB2, Netweaver, HPJD, …
Zusätzliche Randinformationen wie Login, Port, Url, Tablespaces, …
Jemand, der die Datenquellen pflegt, muss/will nichts über die Funktionsweise von
Nagios mit seinen Services wissen. Der will seinen Rechner ins Rack schrauben,
Windows installieren und ein paar Angaben in der CMDB einpflegen oder seine
Serverliste ergänzen.
Es gibt Regeln, wie Host- und Applikationsobjekte in Nagios-Hosts und -Services
transformiert werden. Dafür ist der Nagios-Spezialist zuständig.

Was ist coshsh nicht?
• Eine Konfigurations-GUI
Viel zu kompliziert. Warum sollte ein Windows-Admin oder DBA sich mit
max_check_attempts & co herumschlagen, wenn er einfach einen neuen Server
oder einen neuen Tablespace ins Monitoring bringen will?
• Und wenn es bereits eine CMDB o.ä. gibt, warum nicht gleich diese nutzen?

Was ist coshsh nicht?
• Ein Inventory-Scanner
Server im Wert von Millionen und keine Kontrolle?
Irgendwo muss doch festgehalten sein:
Was will ich in welchem Umfang monitoren?
Was ist mit dem (externen) Betreiberteam vereinbart?
Folge ich einem Plan oder reisse ich eine Wundertüte auf?
Es kann doch nicht sein, dass mir ein Tool sagen muss, was an IT rumsteht und
mir vorschreibt, wie das zu überwachen ist?
Unterscheidet ein Auto-Inventarisierer zwischen Test und Prod?
Schneller Anfangserfolg, danach manuelle Konfiguration.

Inventory-Scan oder Plan?
• Bottom up - Inventory-Scan sammelt so viel wie möglich:
• Jeden Dreck schwemmt‘s nach oben, ob man will oder nicht
• Neuentdeckungen landen beim Monitoring-Admin
• Neue Objekte sind im Monitoring, wenn ein Inventory läuft.
• Inventory findet Geräte, die sich derzeit in der Aufbauphase befinden.
• Passwörter müssen nachgepflegt werden (nach dem Login-Alarme gekommen sind)
• Spezielle URLs müssen nachgepflegt werden. Nur Port 80/443 zu finden ist ein Witz.
• Top down - es wird nur das gemonitort, was vorgegeben wird:
• Monitoring-Admin ist nur involviert, wenn Fehler passieren und zur Weiterentwicklung
• Neue Objekte sind im Monitoring, sobald der Eigentümer das Startsignal gibt
• Die Verantwortung für Aufnahme ins und Löschen aus dem Monitoring liegt allein beim Systemeigner.
• Relevant ist, was in der CMDB steht, sonst nichts.
9

Was ist coshsh?
• coshsh ist ein Generator für hoch standardisierte Umgebungen, der die Pflege des
IT-Bestands von der Pflege des Monitorings trennt.
• coshsh sorgt dafür, dass in einer PaaS/SaaS-Umgebung neue Services und VMs
nach der Registrierung in kürzester Zeit und bedienerlos ins Monitoring
aufgenommen werden.
*.cfg
Filer
Windows
Oracl
e

Klasse, z.B. os_ontap.py
Für jede Sorte von Applikation legt man eine Klasse an. Diese erklärt sich für zuständig, wenn ein
passender Eintrag aus der Datasource kommt, z.B. das Betriebssystem eines Filers:
def __mi_ident__(params={}):
if compare_attr("type", params,".*ontap.*|.*netapp.*"):
return ONTAP
class ONTAP(Application):
template_rules = [
TemplateRule(needsattr=None,
template="os_ontap_default",
),
TemplateRule(needsattr="volumes",
template="os_ontap_fs",
),
]

Template, z.B. os_ontap_default.tpl
Eine "fast" fertige Konfigurationsdatei, die mit den realen Werten der Applikation versorgt wird.
{{ application|service("os_ontap_default_check_hw")}}
host_name {{ application.host_name}}
use os_ontap_default
check_command check_naf_v2!$HOSTADDRESS$!60!
{{ application.loginsnmpv2.community }}!
environment
}
{{ application|service("os_ontap_default_check_disks") }}
host_name {{ application.host_name }}
use os_ontap_default,srv-pnp
{{ application.loginsnmpv2.community }}!
disk,failed
}
{{ application|service("os_ontap_default_check_cpu") }}
……

Template, z.B. os_ontap_fs.tpl
In der Klasse stand: TemplateRule(needsattr="volumes", template="os_ontap_fs")
{% for volume in application.volumes %}
{{ application|service("os_ontap_fs_check_vol_"+ volume.name)}}
host_name {{ application.host_name}}
use os_ontap_fs,srvpnp
check_interval 15
{{ application.loginsnmpv2.community}}!
vol_data,{{ volume.name }},
{{ volume.warning}}{{ volume.units}},
{{ volume.critical }}{{ volume.units }}
}
{% endfor %}

Installation
$ mkdir generator
$ cd generator
$ git pull https://github.com/lausser/coshsh.git
$ mkdir recipes
$ mkdir recipes/yns/templates
$ mkdir recipes/yns/classes
$ mkdir recipes/yns/data
$ mkdir etc
$ vi etc/coshsh.cfg
$ export PATH=$PATH:$HOME/generator/coshsh/bin
oder
$ pip install coshsh
oder
OMD-Labs-Edition

Konfiguration
etc/coshsh.cfg
Die "CMDB" ist das CSV-File: $HOME/generator/recipes/yns/data/officepcs_hosts.csv
[datasource_officepcs]
type = csv
dir = %HOME%/generator/recipes/yns/data
[recipe_nsmuc]
objects_dir = %HOME%/siteconfigs/office
datasources = officepcs
host_name,address,type,os,hardware,virtual,notification_period,location,department
ynspc001,192.168.10.101,pc,Dell Optiplex GX700,ps,7x24,Empfang,Administration
ynspc002,192.168.10.102,pc,Acer veriton M290,ps,7x24,Kasse,Administration

Wir kochen Hosts
Das Kochrezept für nsmuc lautet:
• Man nehme die Datasource officepcs, also CSV-Dateien namens officepcs_* aus dem Verzeichnis
recipes/yns/data
• Man nehme Classes und Templates (hier: host.py, host.tpl)
• Man rühre um und fülle alles in siteconfigs/office
$ coshsh/bin/coshsh-cook --cookbook etc/coshsh.cfg --recipe nsmuc
2013-10-19 23:24:13,409 - INFO - recipe nsmuc init
...
2013-10-19 23:24:13,565 - INFO - load template host
2013-10-19 23:24:13,565 - INFO - load items to datarecipient_coshsh_default
2013-10-19 23:24:13,565 - INFO - recipe datarecipient_coshsh_default remove
dynamic_dir coshsh/bin/../coshsh/../../siteconfigs/office/dynamic
2013-10-19 23:24:13,565 - INFO - recipient datarecipient_coshsh_default dynamic_dir
coshsh/bin/../coshsh/../../siteconfigs/office/dynamic
2013-10-19 23:24:13,565 - INFO - number of files before: 0 hosts, 0 applications
2013-10-19 23:24:13,565 - INFO - number of files after: 2 hosts, 0 applications

Es ist angerichtet
$ find siteconfigs/
siteconfigs/
siteconfigs/office
siteconfigs/office/dynamic
siteconfigs/office/dynamic/hostgroups
siteconfigs/office/dynamic/hosts
siteconfigs/office/dynamic/hosts/ynspc001
siteconfigs/office/dynamic/hosts/ynspc001/host.cfg
$ cat siteconfigs/office/dynamic/hosts/ynspc001/host.cfg
define host {
use generic-host
host_name ynspc001
address 192.168.10.101
alias ynspc001
notification_period 7x24
check_command check_host_alive
notification_options d,u,r
_SSH_PORT 22
}

Jetzt noch Applikationen dazu…
Die „CMDB“ wird erweitert um eine neue Datei
recipes/yns/data/officepcs_applications.csv
host_name,name,type,component,version,check_period
ynspc001,os,Windows,,2008R2,7x24
$ coshsh-cook --cookbook etc/coshsh.cfg --recipe nsmuc
2013-10-20 00:43:33,767 - INFO - recipe nsmuc init
...
2013-10-20 00:43:33,959 - INFO - number of files before: 2 hosts, 0 applications
2013-10-20 00:43:33,960 - INFO - number of files after: 2 hosts, 2 applications

2 hosts, 2 applications
$ find siteconfigs
siteconfigs/
siteconfigs/office
siteconfigs/office/dynamic
siteconfigs/office/dynamic/hostgroups
siteconfigs/office/dynamic/hosts
siteconfigs/office/dynamic/hosts/ynspc001/os_windows_default.cfg
siteconfigs/office/dynamic/hosts/ynspc002/os_windows_default.cfg

Applikationen - Betriebssystem
Jeder Host bekommt eine Applikation mit dem Namen "os" und dem Typ "Windows", "Linux" [,
"IOS", "ESX", "OnTAP",...]
Für jeden Typ muss eine Klasse angezogen werden. Deren TemplateRules bestimmen dann,
welche tpl-Dateien in Nagios-Konfigfiles umgewandelt werden.
Woher weiss coshsh, dass dafür eine Windows-Klasse zuständig ist?
$ cat recipes/yns/data/officepcs_applications.csv
host_name,name,type,component,version,check_period

os_windows.py
Bei coshsh sind Klassen und Templates für Windows und Linux dabei.
Die liegen in coshsh/recipes/default/{classes,templates}. (Eigene Sachen liegen später in recipes/)
Wenn aus der Datasource irgendwas rauskommt, dessen type-Feld mit .*windows.* matcht, mach
ein Objekt der Klasse Windows draus
from application import Application
from templaterule import TemplateRule
from util import compare_attr
def __mi_ident__(params={}):
if compare_attr("type", params, ".*windows.*"):
return Windows
class Windows(Application):
template_rules = [
TemplateRule(needsattr=None, template="os_windows_default"),
TemplateRule(needsattr="filesystems", template="os_windows_fs"),
]

os_windows_default.tpl
Wenn es ein Objekt der Klasse Windows gibt, besagt die erste TemplateRule:
Nimm os_windows_default.tpl und ersetze darin die Platzhalter durch Werte aus den jeweiligen
Zeile im CSV-File.
os_windows_*.tpl und os_linux_*.tpl liegen coshsh bei. Sie sind in
coshsh/recipes/default/templates
{{ application|service("os_windows_default_check_nsclient") }}
use os_windows_default
check_command check_nrpe_arg!60!checkUpTime!
MinWarn=5m MinCrit=1m
}
{{ application|service("os_windows_default_check_cpu") }}
use os_windows_default,srv-pnp
max_check_attempts 10
check_command check_nrpe_arg!60!checkCPU!
warn=80 crit=90 time=5m time=1m time=30s
}

os_windows_default.cfg
Daraus wird dann:
$ cat siteconfigs/office/dynamic/hosts/ynspc001/os_windows_default.cfg
define service {
service_description os_windows_default_check_nsclient
host_name ynspc001
use os_windows_default
check_command check_nrpe_arg!60!checkUpTime!
MinWarn=5m MinCrit=1m
}
define service {
service_description os_windows_default_check_cpu
host_name ynspc001
use os_windows_default,srv-pnp
max_check_attempts 10
check_command check_nrpe_arg!60!checkCPU!
warn=80 crit=90 time=5m time=1m time=30s
}

Applikationsdetails
So ein Windows-System hat auch Filesysteme. Die definiert man über sog. Details. Diese dienen dazu,
alle möglichen Zusatzinformationen zu einer Applikation zu liefern.
• Windows/Unix-Applikationen bekommen Filesysteme
• OnTap-Applikationen bekommen Volumes, Community
• IOS-Applikationen bekommen Interfaces, Community
• Apache-Applikationen bekommen URLs
• Oracle-Applikationen bekommen Tablespaces, User, Passwort
• ...
$ cat recipes/yns/data/officepcs_applicationdetails.csv
host_name,application_name,application_type,monitoring_type,monitoring_0,monitoring_1,
...
ynspc001,os,Windows,FILESYSTEM,C,20,10,,,
ynspc001,os,Windows,FILESYSTEM,D,20,10,,,
ynspc001,os,Windows,FILESYSTEM,F,10,5,,,
ynspc002,os,Windows,FILESYSTEM,C,25,10,,,

os_windows_fs.tpl
Der Monitoring-Type „FILESYSTEM“ bewirkt, dass das Applikations- bzw. Windows-Objekt ein
Attribut namens „filesystems“ bekommt. Dieses ist eine Liste von Filesystem-Objekten,
welche ihrerseits Attribute „path“, „warning“, „critical“ und „units“ (default: %) haben.
Wir erinnern uns an
TemplateRule(needsattr="filesystems", template="os_windows_fs"),
$ more coshsh/recipes/default/templates/os_windows_fs.tpl
{# fs.path fs.warning fs.critical fs.units #}
{% for fs in application.filesystems %}
{{ application|service("os_windows_fs_check_" + fs.path) }}
use os_windows,srv-pnp
check_interval 15
check_command check_nrpe_arg!60!CheckDriveSize!ShowAll
MinWarnFree={{ fs.warning }}{{ fs.units }}
MinCritFree={{ fs.critical }}{{ fs.units }}
Drive={{ fs.path }}:
}
{% endfor %}

Applikationsdetails
coshsh bringt von Haus aus ein paar Details mit
Will man die mitgelieferten Klassen und Templates modifizieren, kopiert man sie von
coshsh/recipes/default/{classes,templates} nach recipes/yns/classes/{classes,templates}
Das gilt für Windows, Linux und die Details. Zwecks eigener Anpassungen reicht es auch, nur ein
tpl-File zu kopieren und die Klasse zu belassen. In coshsh.cfg muss beim Recipe-Abschnitt
noch classes_dir und templates_dir angegeben werden. coshsh/recipes/default wird aber
immer noch durchsucht.
$ cd coshsh/recipes/default/classes $ ls detail*
detail_access.py detail_loginsnmpv2.py detail_socket.py
detail_datastore.py detail_loginsnmpv3.py detail_tablespace.py
detail_depth.py detail_nagiosconf.py detail_tag.py
detail_filesystem.py detail_nagios.py detail_url.py
detail_interface.py detail_port.py detail_volume.py
detail_keyvalues.py detail_process.py detail_login.py
detail_role.py

Datasource_xxxx Adapter zur CMDB
Im default-classes-Verzeichnis liegt datasource_csv.py
Diese Datei enthält den Code, um die vorhin gezeigten CSV-Dateien auszulesen und die
gefundenen Hosts und Applikationen in Python-Objekte zu verwandeln.
def __ds_ident__(params={}):
if compare_attr("type", params, "csv"):
return CsvFile
…
class CsvFile(Datasource):
def __init__(self, **kwargs):
superclass = super(self.__class__, self)
superclass.__init__(**kwargs)
# Parameter aus dem [datasource]-Abschnitt
self.name = kwargs["name"]
self.dir = kwargs["dir"]
self.objects = {}
…

Datasource_xxxx Adapter zur CMDB
def open(self):
logger.info('open datasource %s' % self.name)
if not os.path.exists(self.dir):
logger.error('csv dir %s does not exist' % self.dir)
raise DatasourceNotAvailable
def read(self, filter=None, objects={}, force=False, **kwargs):
for row in hostscsv:
h = Host(row)
self.add('hosts', h)
h.hostgroups.append(
"dept_" + row["departement".lower())
h.hostgroups.append(
"loc_" + row["location"].lower())
…
for row in applicationscsv:
a = Application(row)
self.add('applications', a)
…

Eigene Datasource anbinden
Am besten fängt man mit vorhandenem Code an
• cp coshsh/recipes/default/classes/datasource_csvfile.py recipes/yns/classes
• Umbenennen in datasource_xyxy.py
• Die Funktion __ds_ident__ so anpassen, dass der eigene Typ erkannt wird
• In coshsh.cfg im [datasource]-Abschnitt type=xyxy angeben.
Es stehen ein paar Exceptions zur Verfügung, mit denen die Generierung kontrolliert
abgebrochen werden kann:
• DatasourceNotReady
Die Datenbasis wird momentan aktualisiert, es könnte Ungereimtheiten geben.
• DatasourceNotCurrent
Seit der letzten Generierung wurde die Datenbasis nicht verändert. Generierung ist nicht
nötig. (Dazu muss man eine Handshaketabelle mit Zeitstempeln implementieren)
• DatasourceNotAvailable
Die Datenbasis ist nicht verfügbar. Würde man weitergenerieren, könnten hinten 0 Hosts
rauskommen.

Empfohlene Konfiguration
Zur Erinnerung:
[recipe_nsmuc]
In objects_dir bzw. dessen Unterverzeichnis „dynamic“ landen die Konfigfiles.
Wenn das ein Git-Repository ist, werden die Änderungen mit commit eingecheckt.
[recipe_nsmuc]
max_delta = 90
Notbremse! Ändert sich die Zahl der Hosts/Applikationen um mehr als 90%, wird eine Warnung
ausgegeben. Wurde coshsh-cook mit --safe-output aufgerufen, wird ein git-reset ausgeführt.

Wo ist coshsh im Einsatz?
• Landeshauptstadt München
Ursprünglich an eine neue CMDB angebunden. Bis zur Inbetriebnahme der CMDB wird mit
ODS-Calc-Sheets gearbeitet.
• Automobilbauer XYZ
OS-Monitoring – Serverdaten werden aus der CMDB gelesen.
PaaS / Linux-VM auf Knopfdruck – Serverdaten kommen kontinuierlich aus der Admin-DB.
SaaS / DB-VM auf Knopfdruck – Postgres-Monitoring wird kontinuierlich generiert.
Monitoring-Selfservice-Portal – Applikationsmonitore werden aus einer APEX-DB generiert.
• Discounter XYZ
Ca. 220 Standorte pflegen ihren IT-Bestand in einer zentralen Sharepoint-Applikation. Die MS
SQL-DB wird minütlich gelesen. Änderungen gelangen durch git-Replikation innerhalb von 2
Minuten an die entspr. Lokationen.
• Schweizer Nahrungsmittelverarbeitungsmaschinenhersteller

Demo
Beispiel: DBA trägt seine
Oracle-Instanzen und Tablespaces
in einem Excel-Online-Sheet ein.
Coshsh sorgt dafür, daß diese
automatisch im Monitoring auftauchen.

http://labs.consol.de/nagios/coshsh
Fragen?

coshsh

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à coshsh

Similaire à coshsh (20)

coshsh