Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II

This entry is part 10 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

In Weiterführung vom letzten Post dieser Serie, beschäftigen wir uns zuerst damit dem Icinga-Server eine CA hinzuzufügen. Dies erledigt die Deklaration der Klasse icinga2::pki::ca. Sie erzeugt auch noch gleich ein Zertifikat für den eigenen Server.
Das ist auch der Grund, warum im Folgenden der Parameter pki des Features API mit none belegt werden muss, da genau dies verhindert, dass nochmals versucht wird ein Zertifikat zu generieren. Dieser Wert für pki ist also nur sinnvoll für Hosts mit einer Icinga-2-CA.

class profile::icinga2::server {
  ...
  #
  # CA / API
  #
  include ::icinga2::pki::ca
  class { '::icinga2::feature::api':
    pki             => 'none',
    accept_commands => true,
  }

Als nächstes widmen wir uns dem Feature IDO, welches die IDO-DB befüllt, hier eine MySQL-Datenbank, die ebenfalls per Puppet verwaltet werden soll und sich auch dem gleichen Server befindet. Hierfür ist zusätzlich das MySQL-Puppetmodule erforderlich. Das Datenbank-Schema kann vom Icinga2-Modul automatisch angelegt werden. Hierfür ist dann zu den üblichen Berechtigungen auch CREATE für den Benutzer, den auch Icinga für den Zugriff verwendet, erforderlich, da auch dieser zum initalen Erzeugen der Tabellen vom Icinga2-Modul verwendet wird.
In Bezug auf die Reihenfolge der Abarbeitung unserer Ressourcen, muss nur dafür Sorge getragen werden, dass die Datenbank für die IDO vor dem IDO-Feature dran kommt.
Für den zu verwenden Benutzernamen, das zugehörige Passwort und den eigentlichen Datenbanknamen fügen wir der Profilklasse Parameter hinzu. Im Gegensatz zum Datenbank- und Benutzernamen, die beide als Default icinga2 gesetzt bekommen, ist das Passwort als Parameter vom Endbenutzer immer selbst anzugeben.

class profile::icinga2::server(
  String   $ido_db_pass,
  String   $ido_db_name  = 'icinga2',
  String   $ido_db_user  = 'icinga2',
) {
  case $::osfamily {
    'redhat': {
      ...
      package { [ 'nagios-plugins-all', 'icinga2', 'icinga2-ido-mysql' ]:
        ensure => installed,
        before => User['icinga'],
      }
      ...
    }
    ...
  }
  #
  # Icinga 2
  #
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
  #
  # IDO database
  #
  include ::mysql::server
  mysql::db { $ido_db_name:
    user     => $ido_db_user,
    password => $ido_db_pass,
    host     => '127.0.0.1',
    grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
    before   => Class['icinga2::feature::idomysql']
  }
  class{ '::icinga2::feature::idomysql':
    user          => $ido_db_user,
    password      => $ido_db_pass,
    database      => $ido_db_name,
    import_schema => true,
  }

Auf RedHat-Systemen musste, wie in vorherigen Teil zu sehen war, da Paketmanagement aus dem eigentlichen Icinga-Modul herausgezogen werden, um den Benutzer icinga zwischen Paketinstallation und Icinga-Klasse verwalten zu können. Das bezieht sich nun ebenfalls auf das Paket icinga2-ido-mysql, das für das IDO-Feature erforderlich ist. Debianbasierte Systeme sind hiervon nicht betroffen.

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

This entry is part 9 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Es ist nun nahzu schon ein Jahr her, dass in dieser Blogserie ein Artikel erschien. Zeit diese Serie fortzusetzen, auch weil wir für diese Jahr noch den Release 2.0.0 des Moduls puppet-icinga2 planen. In den kommenden Artikeln möchte ich sukezessive eine Profil-Klasse entwickeln, die einen Icinga-2-Server inklusive Plugins, IDO, Api und Icinga Web 2 installiert und konfiguriert. Als weitere Anforderung soll dies erfolgreich auf RedHat- wie auch Debian-Systemen durchgeführt werden können. Getestet wurde der Code auf Debian-9 (stretch) und CentOS-7.
Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels Posix Capabilities. Damit stellt uns Debian nicht vor größere Herausforderungen, die Plugins für RedHat-Systeme erfordern jedoch, dass der Aufrufende Benutzer Mitglied der Gruppe nagios sein muss. Um dies Anforderung zu realisieren, muss der Benutzer icinga der Gruppe nagios hinzugefügt werden, dass bei Puppet heißt, er ist via User-Resource zu verwalten. Am besten überlässt man das Anlegen vom Benutzer icinga weiterhin dem Paket icinga2, damit werden solche Eigenschaften wie UID oder das Home-Verzeichnis dem Paketverantwortlichen überlassen, d.h. aber auch die Paketinstallation muss vor der User-Resource und die wiederum vor der Klasse icinga2 abgearbeitet werden. Der Service, der von der Klasse verwaltet wird, darf erst gestartet werden, wenn der Benutzer schon korrekt konfiguriert ist. Andernfalls würde Icinga als Prozess weiterhin unter einem Benutzer laufen, der zum Startzeitpunkt von seiner Zugehörigkeit zur Gruppe nagios noch nichts wusste.
Zusätzlich muss auch die Gruppe nagios vor der User-Resource vorhanden sein, was sichergestellt ist, wenn vorher das Paket nagios-plugins-all installiert ist.

class profile::icinga2::server {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      $manage_package = false
      $manage_repo    = false
      package { [ 'nagios-plugins-all', 'icinga2' ]:
        ensure => installed,
        before => User['icinga'],
      }
      user { 'icinga':
        groups => [ 'nagios' ],
        before => Class['icinga2']
      }
    } # RedHat
    'debian': {
      $manage_package = true
      $manage_repo    = true
      package { 'monitoring-plugins':
        ensure => installed,
      }
    } # Debian
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  } # case
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
}

Die Plugins befinden sich bei RedHat in einem zusätzlichen Repository, dem EPEL-Repository, das in der dedizierten Profilklasse profile::repo::epel verwaltet wird. Gleiches gilt für das Icinga-Repo mit der Klasse profile::repo::icinga, was auf RedHat für die gesonderte Paketinstalltion vorhanden sein muss und damit nicht, wie unter Debian, der Klasse icinga2 überlassen werden kann.

class profile::repo::epel {
  yumrepo { 'epel':
    descr => "Extra Packages for Enterprise Linux ${::operatingsystemmajrelease} - \$basearch",
    mirrorlist => "https://mirrors.fedoraproject.org/metalink?repo=epel-${::operatingsystemmajrelease}&arch=\$basearch",
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => "http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-${::operatingsystemmajrelease}",
  }
}
class profile::repo::icinga {
  yumrepo { 'ICINGA-release':
    descr => 'ICINGA (stable release for epel)',
    baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => 'http://packages.icinga.org/icinga.key',
  }
}
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.

Going to OSMC? Join OSCAMP! Program is now online


Want to be a Master of Puppet? – Join OSCAMP! Open Source Camp is a brand new series of events giving Open Source projects a platform to present themselves to the community. OSCAMPs second edition is on Puppet. The one-day event comprises expert presentations and tech tutorials, insights into latest developments, how-tos and future trends.
We are very happy to announce this year’s program! Come and listen to the trailblazing ideas and works of…

  • Walter Gildersleeve – Puppet
  • Tim Meusel – GoDaddy
  • Martin Alfke – example42
  • Kris Buytaert – Inuits
  • … and many more

To see the program visit Open Source Camp website.
Taking place on November 8, the camp directly follows OSMC‘s lecture program. Extend your stay in Nuremberg and get in touch with the Open Source enthusiasts behind Puppet. Benefit from their extensive know-how, learn, discuss and discover new grounds! Register now!
Get to know all the important Puppet facts and faces!
#OSCAMP | November 8, 2018 | Nuremberg
 

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Learn more and get inspired: OSMC Workshops!


OSMC, November 5: One day, four experts, four chances to gain knowlegde and come closer to being an expert yourself. The Workshops at OSMC are perfect opportunities for learning, gaining new friendships and bringing helpful and valuable information back to your business. Choose the one that suits your monitoring requirements best:

Prometheus

Prometheus brings monitoring to another level, when everything is about metrics and graphes. It puts the data first, and takes advantage of multiple service discovery systems. This workshop will dive into its ecosystem and teach you how to get the best out of it. Be ready to discover a new and very effective approach to monitoring.

Ansible

This workshop leads you to your very first automated deployment. Starting with the basic concept how Ansible works and how it will support you at your daily tasks. In this session we will guide you step by step to your first playbook and application deployment.

Icinga 2 / Puppet

This workshop is an advanced workshop to show how a distributed Icinga 2 environment is managed by Puppet. We will build a distributed Icinga 2 setup with puppet-icinga2 module using the role/profile concept. Additionally we will spend some time to discuss zones and endpoints in Icinga 2 and also some advanced puppet features used by previous mentioned puppet module.

Graylog

This workshop is a beginners guide to central log management. After talking about fundamental elements of central log management with Graylog we will start to setup a Graylog system from scratch to ingest, and filter and visual individual data.
All courses will take place on November 5th, from 10 am to 5 pm, at the conference venue. To promote a comprehensive training success, the number of participants is limited. Workshops are held in German, Prometheus in English. Attendance requires the purchase of an OSMC & Workshop ticket.
More on osmc.de/workshops/
 

OSMC | November 5 – 8, 2018 | Nuremberg

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Icinga2 GitLab Health Check

GitLab
Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).
Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.
Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.
Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):
GitLab Status
D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:
https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb
Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.
Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.
Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.
Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:
Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24
Stefan Gundel
Stefan Gundel
Senior Systems Engineer

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging


 
„Das @netways Blog kann man auch generell einfach mal empfehlen: https://www.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.
Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!
Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!
CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!
Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.
Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.
Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.
Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.
Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.