Seite wählen

NETWAYS Blog

Ice, Ice – Icinga 2 / Puppet – Baby!

von | Aug 14, 2018 | , , , , ,


Bis vor Kurzem liefen in den Büros die Klimaanlagen oder – wie bei uns – die Tisch- und Standventilatoren auf Hochtouren, um ein halbwegs erträgliches Arbeiten zu ermöglichen. Ach ja: Sommer…  Allmählich normalisieren sich die Temperaturen ja wieder. Letztens las ich auf Twitter gar: „24 Grad nach Gewitter. Kann man schon Glühwein?“ Damit ihr trotz des Sommers und allem, was er mit sich bringt – Rekordhitze oder Glühweindurst, einen kühlen Kopf bewahrt, hier ein kurzer Hinweis: Bald ist wieder Winter! Und dann gibt es von uns ein kleines Geschenk: Am 18./19. Dezember findet die erste Ausgabe unseres neuen Icinga 2 / Puppet Workshops statt. Anmelden könnt ihr euch schon jetzt.

Icinga 2 / Puppet ist ein Workshop für Fortgeschrittene.

Ihr lernt, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert.
Das heißt:

  • Hands-on! Am Ende wisst ihr, wie ihr ein solches Setup mit dem Icinga-2-Puppet-Modul einrichtet, wozu ihr das Role/Profile-Konzept braucht und habt das Ganze selbst einmal durchgespielt. Daneben werdet ihr über Zones und Endpoints diskutieren und euch fortgeschrittene Modul-Funktionen ansehen.
  • Für Fortgeschrittene: Der Workshop richtet sich an erfahrene Administratoren, die bereits Vorwissen mit beiden Projekten haben.
Hier noch einmal die Workshop-Inhalte in der Übersicht
  • Icinga 2 Master mit Icinga Web 2 installieren
  • Einrichten mehrerer Icinga 2 Agenten auf verschiedenen Plattformen (einschließlich Windows)
  • Verwenden einer dedizierten Zertifizierungsstelle, um eingehende Zertifikatsanforderungen automatisch zu signieren
  • Integration eines Icinga 2 Satelliten
  • Aufbau eines halbautomatischen Monitorings von Hosts mit Facts und PuppetDB
  • Verwenden von Git mit r10k für die automatische Bereitstellung unserer Puppet-Module in dynamischen Puppet-Umgebungen

Workshop-Leiter ist Lennart Betz, Open Source Trainer, Senior Consultant bei NETWAYS, Entwickler des Icinga-2-Puppet-Moduls und Autor des Buches „Icinga 2. Ein praktischer Einstieg ins Monitoring.“ Ihr seid neugierig geworden, euch aber nicht sicher, ob ihr das entsprechende Vorwissen mitbringt? Dann checkt doch mal die Inhalte unserer „Fundamentals for Puppet“ und „Icinga 2“-Schulungen, die wir allen Einsteigern ins Thema empfehlen.
Einen kleinen Vorgeschmack, was euch erwartet, bekommt ihr in unserer Blogserie:

Icinga 2 automatisieren mit Puppet

Alle Infos auf netways.de/trainings

Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen

von | Aug 18, 2017 | , , ,

Vor einiger Zeit trat der Wunsch auf mit dem aktuellen Icinga-2-Modul für Puppet beliebe Objekte aus Hiera heraus zu erzeugen. Zum Beispiel aus folgender Hiera-Datei sollen ein Host-Objekt und zwei Service-Objekte gebaut werden.

---
monitoring::object:
  'icinga2::object::host':
    centos7.localdomain:
      address: 127.0.0.1
      vars:
        os: Linux
  'icinga2::object::service':
    ping4:
      check_command: ping4
      apply: true
      assign:
        - host.address
    ssh:
      check_command: ssh
      apply: true
      assign:
        - host.address && host.vars.os == Linux

In Puppet 4 lässt sich dies nun sehr einfach mit zwei Schleifen realisieren:

class { 'icinga2':
  manage_repo => true,
}
$default = lookup('monitoring::default')
lookup('monitoring::object').each |String $object_type, Hash $content| {
  $content.each |String $object_name, Hash $object_config| {
    ensure_resource(
      $object_type,
      $object_name,
      deep_merge($default[$type], $object_config))
  }
}

Hierbei sind sogar für jeden Objekt-Type auch noch Defaults in Hiera gesetzt, z.B. in einer Datei common.yaml, die immer gelesen wird.

---
monitoring::default:
  'icinga2::object::host':
    import:
      - generic-host
    target: /etc/icinga2/conf.d/hosts.conf
  'icinga2::object::service':
    import:
      - generic-service
    target: /etc/icinga2/conf.d/services.conf

Dieses Verfahren ist mit dem selben Code auf Objekte mit allen möglichen Objekt-Typen erweiterbar. Passt man den Funktionsaufruf von lookup entsprechend an, kann auch über die Hiera-Struktur gemerged werden.

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.
Lies mehr von Lennart und triff unser Team

Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features

von | Apr 28, 2017 | ,

Heute steht der Blog um des Icinga Puppet-Modul ganz im Zeichen der Icinga-2-Features. Features lassen sich entweder über die main class aktivieren und via Hiera parametrisieren oder dediziert mittels einer eigenen Klasse deklarieren.

include ::mysql::server
include ::icinga2
mysql::db { 'icinga':
  user     => 'icinga',
  password => 'secret',
  host     => 'localhost',
  grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
  before   => Class['::icinga2']
}

Da die Klasse icinga2 auch über einen Parameter features verfügt über den die angegeben Features aktiviert werden, kann auch dieser Parameter nach Hiera ausgelagert werden. Nachfolgend wird für die MySQL-IDO-Anbindung das Passwort gesetzt und veranlasst, dass erstmalig das DB-Schema importiert wird. Alle anderen Parameter für das Feature idomysql, sowie alle für mainlog und checker sind die entsprechenden Default-Werte.

---
icinga2::features:
  - checker
  - notification
  - mainlog
  - idomysql
icinga2::feature::idomysql::password: secret
icinga2::feature::idomysql::import_schema: true

Das selbe erreicht man ebenfalls unter Verwendung der direkten Deklaration:

class { '::icinga2::feature::idomysql':
  password      => 'secret',
  import_schema => true,
}

Etwas anders verhält es sich, wenn man die Feature checker, notification oder mainlog explizit deklarieren möchte. Da diese die standardmäßig aktivierten Features sind, muss das entsprechende Feature vorher deaktiviert werden bzw. nur die anderen im Parameter features angegeben werden:

class { '::icinga2':
  features => [ 'checker', 'notification' ],
}
class { '::icinga2::feature::mainlog':
  severity => 'notice',
}

Der Weg über die Konfiguration über Hiera ist da doch wirklich eleganter. Die Deklaration ist übersichtlich

include ::icinga2

und auch in Hiera ist nicht viel zu hinterlegen:

---
icinga2::feature::manilog::severity: notice
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.
Lies mehr von Lennart und triff unser Team

Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

von | Mrz 31, 2017 | , , , ,


Der erste Release vom Rewrite des Puppetmoduls zu Icinga 2 liegt nun auch schon einige Monate zurück und somit wird es Zeit sich im Zuge einer Blog-Serie genauer damit zu befassen. Zu beziehen ist das Module entweder über die Puppet Forge oder via GitHub.
Zu Beginn steht natürlich immer erstmal die „Installation“ bzw. weil Puppet deklarativ arbeitet, die Beschreibung installiert zu sein. Schon hier zeigt sich das Modul flexibel und kann vom Benutzer angepasst benutzt werden. So greift Puppet bei einer einfachen Deklaration ohne Parameter auf die auf dem System konfigurierten Repositories zurück. Es bietet jedoch auch die Möglichkeit für die unterstützten Plattformen RedHat, Debian, Ubuntu und Suse, die automatisch Einbindung der offiziellen Icinga-Repositories auf packages.icinga.com.

class { '::icinga2':
  manage_repo => true,
}

Betreibt man selbst ein internes Repository, z.B. als Spiegel des offiziellen, muss dieses vor der Deklaration der Klasse ::icinga2 erfolgen. Beispielhaft hier für RedHat-Systeme:

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',
}
->
class { '::icinga2': }

Ein Problem beim Einsatz in verteilten Umgebungen und vor allem durch die Benutzung von Icinga als Agent ist die Software-Verwaltung. So sollten keine Instanzen miteinander kommunizieren, die zwei Major Releases auseinander liegen, z.B. 2.6.x mit 2.5.x sollte noch ok sein, 2.6er mit 2.4.x und früher jedoch nicht. Besser ist jedoch die Benutzung ausschließlich von 2.6er Versionen. Setzt man hierfür kein Software-Management-Tool ein, kann Puppet helfen. Voraussetzung sollte jedoch ein Repository-Spiegel sein, den man nur zu gegebenen Zeitpunkten synchronisiert.

package { 'icinga2':
  ensure => latest,
}
->
class { '::icinga2':
  manage_package => false,
}

Damit wird bei jedem Puppetlauf dafür gesorgt, das die neuste Version installiert ist. Welche das ist, steuert man über den „händischen“ Repo-Sync. Sind für einzelne Features zusätzliche Pakte erforderlich, müssen dann auch diese durch eigene Package-Resources verwaltet werden. Betroffen sind hier außer auf Windows oder FreeBSD die Features idomysql und idopgsql.
Auch das Handling des Icinga Services kann angeschaltet werden. Standardmäßig zieht jede Änderung an einer mit Puppet verwalteten Konfigurationsdatei einen Reload des icinga-Prozesses nach sich. Vor Version 1.2.0 von puppet-icinga2 wird allerdings noch ein Neustart ausgelöst. Für den Fall, dass lediglich zu bestimmten Zeiten eine neue Konfiguration eingelesen werden soll, kann man wie folgt vorgehen:

schedule { 'everyday':
  range  => '2 - 4',
  period => daily,
  repeat => 1,
}
class { '::icinga2':
  manage_service => false,
}
~>
service { 'icinga2':
  ensure => running,
  enable => true,
  schedule => 'everyday',
}

Zu bedenken ist hier nur der Nachteil, dass auch nur zwischen 2 und 4 nachts der Dienst wieder gestartet wird, falls er nicht laufen sollte. Aber dafür gibt es ja das Monitoring. Abschließend für heute kann nicht unerwähnt bleiben: Auch um benötigte Plugins darf sich der Benutzer selbst kümmern. Hierbei ist die Reihenfolge, ob erst die Plugins und dann Icinga oder umgekehrt, unerheblich.

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.
Lies mehr von Lennart und triff unser Team

Trainings

Web Services

Events