Coshsh - Generationen von Konfigurationen

Transkript

1 Coshsh - Generationen von Konfigurationen Gerhard Laußer ConSol* Software GmbH

2 2

3 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 Sharepoint-Applikation CMDB Datenbank von Monitoring-Selbstbedienungsportalen 3

4 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. 4

5 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? 5

6 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. 6

7 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. Filer Oracle Windows *.cfg 7

8 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", ), ] 8

9 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 check_command check_naf_v2!$hostaddress$!60!\ {{ application.loginsnmpv2.community }}!\ disk,failed } {{ application service("os_ontap_default_check_cpu") }} 9

10 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 check_command } {% endfor %} check_naf_v2!$hostaddress$!60!\ {{ application.loginsnmpv2.community}}!\ vol_data,{{ volume.name }},\ {{ volume.warning}}{{ volume.units}},\ {{ volume.critical }}{{ volume.units }} 10

11 Installation $ mkdir generator $ cd generator $ git pull $ 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 11

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

13 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 :24:13,409 - INFO - recipe nsmuc init :24:13,565 - INFO - load template host :24:13,565 - INFO - load items to datarecipient_coshsh_default :24:13,565 - INFO - recipe datarecipient_coshsh_default remove dynamic_dir coshsh/bin/../coshsh/../../siteconfigs/office/dynamic :24:13,565 - INFO - recipient datarecipient_coshsh_default dynamic_dir coshsh/bin/../coshsh/../../siteconfigs/office/dynamic :24:13,565 - INFO - number of files before: 0 hosts, 0 applications :24:13,565 - INFO - number of files after: 2 hosts, 0 applications 13

14 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 siteconfigs/office/dynamic/hosts/ynspc002 siteconfigs/office/dynamic/hosts/ynspc002/host.cfg $ cat siteconfigs/office/dynamic/hosts/ynspc001/host.cfg define host { use generic-host host_name ynspc001 address alias ynspc001 notification_period 7x24 check_command check_host_alive notification_options d,u,r _SSH_PORT 22 } 14

15 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 ynspc002,os,windows,,2008r2,7x24 $ coshsh-cook --cookbook etc/coshsh.cfg --recipe nsmuc :43:33,767 - INFO - recipe nsmuc init :43:33,959 - INFO - number of files before: 2 hosts, 0 applications :43:33,960 - INFO - number of files after: 2 hosts, 2 applications

16 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 siteconfigs/office/dynamic/hosts/ynspc001/host.cfg siteconfigs/office/dynamic/hosts/ynspc001/os_windows_default.cfg siteconfigs/office/dynamic/hosts/ynspc002 siteconfigs/office/dynamic/hosts/ynspc002/host.cfg siteconfigs/office/dynamic/hosts/ynspc002/os_windows_default.cfg 16

17 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. $ cat recipes/yns/data/officepcs_applications.csv host_name,name,type,component,version,check_period ynspc001,os,windows,,2008r2,7x24 ynspc002,os,windows,,2008r2,7x24 Woher weiss coshsh, dass dafür eine Windows-Klasse zuständig ist? 17

18 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/) 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"), ] Wenn aus der Datasource irgendwas rauskommt, dessen type-feld mit.*windows.* matcht, mach ein Objekt der Klasse Windows draus 18

19 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") }} host_name {{ application.host_name }} use os_windows_default check_command check_nrpe_arg!60!checkuptime!\ MinWarn=5m MinCrit=1m } {{ application service("os_windows_default_check_cpu") }} host_name {{ application.host_name }} 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 } 19

20 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 } 20

21 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,,, 21

22 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) }} host_name {{ application.host_name }} 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 %} 22

23 Applikationsdetails coshsh bringt von Haus aus ein paar Details mit $ 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 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. 23

24 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 = {} 24

25 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)

26 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. 26

27 Empfohlene Konfiguration Zur Erinnerung: [recipe_nsmuc] objects_dir = %HOME%/siteconfigs/office 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 objects_dir = %HOME%/siteconfigs/office 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.

28 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. 200 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. Bank XYZ Querbeet-IT wird in Excel gepflegt. Je ein Sheet für Hosts, Apps, Details, Contacts Bank XYZ End-to-End-Monitoring verschiedener Applikationen von weltweiten Standorten aus. 28

29 (ist erst in Entstehung begriffen) Fragen? 29