Seite wählen

NETWAYS Blog

OSMC 2021 | Still directing the director… and more!

OSMC 2021 has brought many insights into latest monitoring trends and we’re still amazed about that great on-site event last autmn. We’re happy to had a big amount of international attendees, 28 top-level speakers and not to forget our much valued sponsors on bord – in short: we’re grateful for everyone who made OSMC 2021 a special and an exciting event once again!

For all of you who would like to listen to last year’s experts sessions as a follow-up, I’ve created this blog series. It reminds you bi-weekly of one of our OSMC lectures including its video recording.

Today it’s all about Daniel Uhlmann and Sebastian Gumprich with their talk Still directing the director… and more!“ Daniel and Sebastian tell you how they automated the monitoring of their services using their self-written Ansible collections.

Enjoy their lecture!

 

YouTube player

 

OSMC 2022 is just around the corner! Get one of our last tickets for the event and join us from November 14-16.

We’re looking forward to meeting you all again this autumn in Nuremberg.

Stay tuned!

Katja Kotschenreuther
Katja Kotschenreuther
Manager Marketing

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Manager Marketing kümmert sie sich hauptsächlich um das Marketing für die Konferenzen stackconf und OSMC sowie unsere Trainings. Zudem unterstützt sie das Icinga Team mit verschiedenen Social Media Kampagnen und der Bewerbung der Icinga Camps. Sie ist SEO-Verantwortliche für all unsere Websites und sehr viel in unserem Blog unterwegs. In ihrer Freizeit reist sie gerne, bastelt, backt und engagiert sich bei Foodsharing. Im Sommer kümmert sie sich außerdem um ihren viel zu großen Gemüseanbau.

ServiceNow Data Asset Import mit dem Director

Hallo Liebe Leser dieses Blogs,

nach einer weile der Abwesenheit hab ich heute die Freude ihnen etwas näher bringen zu dürfen.
Da viele unserer Kunden inzwischen auch ServiceNow verwenden und diese auch als Assetmanagement / CMDB verwenden.

Kommt doch die Frage auf wie man gegebenenfalls hier die Daten abfragen kann um Sie in den Director zu importieren um daraus dann Hosts/Services zur Überwachung zu formen.Ich versuche in diesem kleinen Blogpost zumindest einen Ansatzpunkt hierzu aufzuzeigen. Viele verwenden in diesem Fall ja ServiceNow als SaaS, aber es gibt auch Kunden welche es als On Prem einsetzen.
Aber fangen wir an 🙂 in diesem Fall ist der Anlaufpunkt hier die ServiceNow API, wer hätte es gedacht.
In diesem Fall ziehe ich mal die folgende API (Link) zur rate:

Hier wird die ‚cmdb-instance‘ in welcher die CMDB Daten landen dokumentiert. Es ist aber zu bedenken, dass die Instanz natürlich abweichen kann daher ist dies bitte nicht direkt 1:1 zu übernehmen.
Wir feuern per curl gegen die ServiceNow API, die folgende Abfrage… in Hoffnung, dass wir valides JSON zurückerhalten mit all unseren Objekten.


curl -k -s -S -i -u 'servicenow_apiuser:servicenow_apiuserpassword' -H 'Accept: application/json' -H 'X-HTTP-Method-Override: GET' -X POST 'https://instance.servicenow.com/api/now/cmdb/instance/cmdb_ci_linux_server'

und wir erhalten als Antwort das folgende JSON:


{
"result": {
...
"attributes": {
"firewall_status": "Intranet",
"os_address_width": "",
"sys_updated_on": "2020-07-08 11:16:51",
"sys_created_by": "glide.maint",
"warranty_expiration": "",
"ram": "2048",
"cpu_name": "",
"cpu_speed": "2800",
"classification": "Production",
"disk_space": "40",
"dns_domain": "",
"assigned": "2020-01-04 07:00:00",
"floppy": "",
...
"sys_class_name": "cmdb_ci_linux_server",
...
"cpu_count": "1",
...
"os_version": "2.6.9-22.0.1.ELsmp",
"serial_number": "",
"attributes": "",
...
"form_factor": "",
"cpu_core_count": "",
"sys_updated_by": "system",
"sys_created_on": "2008-10-26 17:17:28",
...
"name": "PS LinuxApp01",
"default_gateway": "",
"chassis_type": "",
"sys_id": "3a290cc60a0a0bb400000bdb386af1cf",
"po_number": "",
"checked_in": "",
...
"comments": "",
"os": "Linux Red Hat",
"sys_mod_count": "24",
"monitor": "false",
"model_id": {
"display_value": "Iris 5875",
"link": "https://instance.servicenow.com/api/now/table/cmdb_model/5f5fbcc3c0a8010e00f3b27814f3b96b",
"value": "5f5fbcc3c0a8010e00f3b27814f3b96b"
},
"ip_address": "192.168.178.1",
"duplicate_of": "",
"location": {
"display_value": "Somewhere Street, Someplace, State",
},
"category": "Do not migrate to asset",
"fault_count": "0",
"host_name": "",
"lease_id": ""
},
}

Den Output schreiben wir als Datei raus, so dass wir hier als Beipiel eine Datei haben, mit der wir weiterarbeiten können. Als Beispiel nennen wir diese servicenow.json
(Exclaimer) Ich habe das JSON hier als Beispiel mal extrem zusammengekürzt, damit wir thementechnisch nicht zu weit Abdriften.
Anyway, aber damit lässt sich arbeiten.
Damit wir mit diesem JSON arbeiten können, verwenden wir das Tool ‚jq‘, um relevante key/value Paare herauszufiltern.
Ich habe hier mal den folgenden ‚jq‘ Aufruf verwendet:


jq -j '.result.attributes.os,",",.result.attributes.ip_address,",",.result.attributes.classification,",",.result.attributes.sys_class_name,",",.result.attributes.name,",",.result.attributes.location.display_value,","' servicenow.json

Der somit gewonnene Output ist der folgende, bitte beachtet die ‚,‘ Kommata. Die meisten werden schon ahnen worauf ich gleich hinaus will.
Zurück zu dem nun mit ‚jq‘ aufbereiteteb Output, dieser ist der folgende:


Linux Red Hat,192.168.178.1,Production,cmdb_ci_linux_server,PS LinuxApp01,Somewhere Street, Someplace, State,

Mit etwas Bash Scripting kann man das schön automatisieren und hat am Ende dieses Vorgangs eine CSV Datei, die man hervorragend im Director per Fileshipper weiterverarbeiten kann.
Das mit dem CSV ist eine Geschmacksfrage, denn man kann auch direkt JSON per Fileshipper importieren … ich würde aber dazu tendieren, die Datenmenge durch etwas vorfiltern zu verkleinern. So eine Filterung, wie gesehen, kann auch per ‚jq‘ erfolgen, so dass man ein kleineres JSON File erhält.
Wer wissen möchte, wie man mit dem Director einen Fileshipper-Import durchführt, dem sei der Blogpost meines Kollegen Johannes empfohlen.

Blogpost Director Fileshipper Import

Das war schon mein kleines Intermezzo wie ServiceNow-Data-Assets per Fileshipper in den Director zu importiert sind.
Bis zum nächsten Mal

Mit freundlichem Gruß
David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Icinga Installation mit Director in 10 Minuten

Herausforderung angenommen. Helfen wird mir der Icinga-Installer und das Director-Installations-Paket aus unserem Extras-Repository. Das hier folgende Beispiel werde ich auf einem RHEL8 durchführen, ist aber auch für Debian und Ubuntu zu adaptieren, da der Installer als auch der Director als Pakete zur Verfügung stehen.

Neben dem angesprochen Extras-Repository für Icinga-Addons wird ein Puppet-Agent benötigt, der Installer ist Puppet-basiert und benötigt keinen zentralen Puppet-Server.


$ dnf install -y https://yum.puppet.com/puppet6/puppet6-release-el-8.noarch.rpm
$ dnf install -y https://packages.netways.de/extras/epel/8/noarch/netways-extras-release/netways-extras-release-8-1.el8.netways.noarch.rpm
$ dnf install -y icinga-installer

Der Installer kann nun out-of-a-box verwendet werden, er installiert einen Icinga-Server inkl. Icinga Web 2 mit Apache und FPM, der benötigten Datenbanken des gewählten Typs und das Business-Prozess-Modul.


$ icinga-installer -S server-ido-mysql

Soll anstatt MariaDB ein PostgreSQL zum Einsatz kommen, ist als Szenario (Option -S) server-ido-pgsql anzugeben. Jetzt wird die Installation und Konfiguration je nach Internetanbindung einige Zeit in Anspruch nehmen. Zuerst werden automatisch zusätzlich das Icinga- und das NETWAYS-Plugins-Repository eingebunden, auf RHEL-basierten Systemen auch noch EPEL. Aus diesen werden alle benötigten Pakete bezogen.

Der Installer wäre auch in der Lage eigene, lokale oder generell alternative Repositories anzusteuern, spränge aber den Rahmen dieses Posts. Es sei nur verraten, mit der Option -i wechselt man für den Installer in den interaktiven Modus.

Nach Abschluss kann Icinga wie üblich mittels /icingaweb2 auf Port 80 (HTTP) erreicht werden. Der initial eingerichtet Admin-Account ist der Benutzer icingaadmin mit dem Password icinga.

Der Director muss z.Z. noch per Hand installiert und konfiguriert werden. Eine Integration in den Installer ist für die kommende Version geplant. Somit muss auch die Datenbank, hier MySQL, per Hand angelegt werden.


$ dnf install -y icingaweb2-module-director
$ mysql -e "CREATE DATABASE director CHARACTER SET 'utf8';
CREATE USER director@localhost IDENTIFIED BY 'some-password';
GRANT ALL ON director.* TO director@localhost;"

Abschließend ist dann nur noch der schon aktivierte Director in der Weboberfläche wie gehabt zu konfigurieren und für den Director erforderliche Daemon icinga-director zu starten. Fertig.


$ systemctl start icinga-director
$ systemctl enable icinga-director

Plugins sind gesondert zu installieren. Eine kleine Vielzahl kann zusätzlich zu den Standard-Monitoring-Plugins über das bereits eingebunden Plugins-Repo installiert werden. Diese Plugins tragen alle netways als Präfix im Paketnamen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

User aus LDAP in Icinga Director Importieren

Ich hatte das Vergnügen mich etwas mit dem Icinga Director zu beschäftigen dabei war eine der Aufgabenstellungen die User aus unserem LDAP in den Director zu Importieren. Im Folgenden werde ich erläutern, welche Schritte notwendig sind, um dies zu tun. Dabei ist zu beachten, dass jede LDAP-Umgebung anders aussieht und diese nicht ganz genau für jede passen.

Zuerst legen wir im Backend an, woher der Director sich die Daten ziehen soll. Das tun wir in der resources.ini, welche unter /etc/icingaweb2/ liegt.
Dort fügen wir das Untenstehende ein und passen die Daten an unsere LDAP-Umgebung an.

[ActiveDirectory]
type = "ldap"
hostname = "example.com“
port = "389"
encryption = "starttls"
root_dn = "dc=example,dc=com"
bind_dn = "cn=serviceuser,ou=users,dc=example,dc=com"
bind_pw = "password"
timeout = "5"

Wenn das geschafft ist, wechseln wir zu Icinga Web 2 und gehen dort auf Configuration > Application > Resources und klicken dort auf ActiveDirectory um unsere Konfiguration zu überprüfen. Dort steht dann das, was wir gerade in die ressources.ini eingetragen haben. Natürlich kann dies auch gleich hier grafisch konfiguriert werden, aber der nächste Schritt muss eh auf der Kommandozeile erfolgen.

Die Vertrauenstellung zu Certificate Authority (CA) des Active Directory funktioniert überall ein bisschen anders:
Auf CentOS sind die LDAP-Clienttools gegen OpenSSL und Mozilla NSS gelinkt, heißt sie nutzen den zentralen Truststore und man kann die eigene CA folgendermaßen hinzufügen:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

Möchte man den zentralen Truststore nicht nutzen, kann man in der ldap.conf den Pfad unter TLS_CACERTDIR abändern und die Methode c_hash nutzen:

# cd $(grep TLS_CACERTDIR /etc/openldap/ldap.conf | cut -f2 -d" ")
# cp /tmp/ca.pem .
# ln -s ca.pem $(/etc/pki/tls/misc/c_hash ca.pem | cut -f1 -d" ")

Alternativ dazu kann auch eine Datei mit allen zu vertrauenden Zertifikaten genutzt werden, wozu die Konfiguration auf TLS_CACERT geändert werden muss.

# vi /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ca.pem

Dies ist beispielsweise bei Ubuntu, wo die LDAP-Clients gegen GnuTLS gelinkt sind, der Standard und man kann das CA-Zertifikat an die Datei:

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Wenn das geschafft ist und man die Daten Quelle hinzu gefügt hat, muss man noch den PHP-FPM-Service neustarten via systemctl restart rh-php73-php-fpm.service. Ab jetzt wechselt man in das web und konfiguriert von dort aus weiter.

Danach wechseln wir auf den Icinga Director, und gehen zu „Import Data Sources“, dort fügt man dann eine neue Datenquelle hinzu. Diese könnten so aussehen:

Add import source

Hier noch zur Erklärung des LDAP-Filters:
(memberof=CN=icinga,OU=Groups,DC=example,DC=com)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*)
Hinter memberof steht der Distingushed Name einer Gruppe, in der alle gewünschten benutzer enthalten sind, die userAccountControl steht für gesperrte Benutzer und wird entsprechend durch das ! negiert und da wir per Mail benachrichtigen wollen muss auch das Attribute mail gesetzt sein.

Zum Schluss wieder auf Add drücken und dann ist auch schon die Import Source erstellt.

Um die Daten noch anzupassen können Modifiers unter Icinga Director > Automation > Import source > Modifiers hinzugefügt werden. In unserem Fall wollen wir die Gruppenmitgliedschaft in den Abteilungen in einem einfacheren Format.


 

Zunächst wechseln wir in Icinga Director > Users > Contacts > User Templates > Add um ein Template zu erstellen bevor wir mit der Sync Rule beginnen können.
Hier sind ein paar Felder wichtig, welche geändert werden sollten, wenn man nicht den Default von Icinga 2 übernehmen möchte. Das sind folgende:

 

Dann auf Add drücken und dann sollte auf der linken Seite „User aus LDAP – not in use – ” stehen.

Als nächstes oben in der Tabliste zu Groups wechseln und dort dann Usergruppen anlegen. (Beispielsweise jede Abteilung als eigene Gruppe o. ä. )

 

Danach wieder links auf Icinga Director > Synchronize > Add, dort muss dann ein Rule name, Object Type, Update Policy sowie Purge eingestellt werden. Zum Schluss wieder Add drücken.

Damit ergibt sich folgende Liste an Properties für den User.

Jetzt noch die Properties setzen diese sind wieder in der Tablist zu finden. Hier müssen folgende Eigenschaften für jede Property gesetzt werden:

Jetzt muss nur Import und Synchronisation einmal gelaufen sein und das wars. Schon sind alle Benutzer aus dem LDAP in Icinga und können ggf. benachrichtigt werden.

Nathaniel Donahue
Nathaniel Donahue
Technical Service Manager

Nathaniel hat 2022 seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS erfolgreich abgeschlossen. Seitdem unterstützt er sein Team im Bereich Operations vor allem beim Betriebsconsulting. In seiner Freizeit ist Nathaniel gerne unterwegs mit Freunden oder reist in der Gegend herum. Ansonsten schnappt er sich gerne mal sein Fahrrad oder geht Schwimmen.

Komm‘ nach Nürnberg für Deinen Icinga 2 Deep Dive!

Du hast bereits den Einsteigerkurs „Icinga 2 Fundamentals“ bei uns belegt bzw. besitzt Monitoring-Grundkenntnisse? Sehr gut. Nun möchtest Du Dein Fachwissen auf diesem Gebiet weiter vertiefen, Dir weitere praktische Kenntnisse aneignen? Perfekt! Dann ist der Icinga Director Workshop genau das Richtige für Dich!
Am 20. und 21. Oktober 2020 erwartet Dich von jeweils 9 – 17 Uhr in Nürnberg eine geballte Ladung an:

  • Grundlagenwissen zu Hostobjekten, Vorlagen für Hosts und Services, Verwendung von Apply-Regeln, Service Sets uvm.
  • Installation und Konfiguration des Directors und einer Beispiel-Umgebung, bestehend aus Icinga Master, Satellite und Agenten auf Linux und Windows zur Überwachung
  • Automatischer Import aus verschiedenen Quellen: Dateiebene und SQL-Datenbank

Nach dem zweitägigen Workshop bist Du also fit darin, Deine Icinga Konfiguration mit Hilfe des webbasierten graphischen Userinterface zu erstellen. Außerdem meisterst Du die Automatisierung von Aufgaben mit dem Icinga Director. Klingt nicht nur super, das ist es auch! Und das beste ist: Wir teilen nicht nur unser versiertes Fachwissen mit Dir, sondern auch Kekse – also sei dabei! Hier geht’s zur Anmeldung. Solltest Du nicht aus Nürnberg kommen und Hilfe bei der Suche nach einer passenden Unterkunft für diesen Zeitraum benötigen, dann unterstützen wir Dich gerne – melde dich einfach bei uns!

Neben dem Icinga Director Workshop stehen in den kommenden Monaten auch noch weitere Trainings aus anderen Fachbereichen an:

 

MONITORING TRAININGS
Icinga Schulung (Fundamentals) | Online | 1.-4. Dezember 2020 | 9-17 Uhr
Icinga 2 Advanced | Nürnberg | 8.-10. Dezember 2020 | 9 – 17 Uhr

 

LOGGING & METRICS TRAININGS
Graylog Schulung | Nürnberg | 27.-28. Oktober 2020 | 9 – 17 Uhr
Elastic Stack Schulung | München | 24.-26. November 2020 | 9 – 17 Uhr

 

ADMINISTRATION TRAININGS
Linux Schulung (Basics) | Nürnberg | 27.-29. Oktober 2020 | 9 – 17 Uhr
PostgreSQL Schulung (Fundamentals) | Nürnberg | 1.-3. Dezember 2020 | 9 – 17 Uhr
PostgreSQL Advanced | Nürnberg | 15.-18. Dezember 2020 | 9 – 17 Uhr

 

AUTOMATION TRAININGS

Ansible Schulung | Online | 13.-15. Oktober 2020 | 9 – 17 Uhr

Ansible Tower | Online | 16. Oktober | 9 – 17 Uhr
Puppet Schulung (Fundamentals) | Online | 20.-22. Oktober | 9 – 17 Uhr

Foreman Schulung | Nürnberg | 1.-2. Dezember | 9 – 17 Uhr
Terraform Schulung | Online | 8.-9. Dezember 2020 | 9 – 17 Uhr

 

DEVELOPMENT TRAININGS
GitLab Schulung (Fundamentals) | Online | 27.-28. Oktober 2020 & Nürnberg | 15.-16. Dezember 2020 | 9 – 17 Uhr

 

Wir bieten Trainings an, die sowohl online, als auch vor Ort stattfinden. Also, egal, ob virtuell oder IRL – wir freuen uns auf Dich und den gemeinsamen Austausch!