Apply Service for im Icinga Director

Mit den Icinga 2 Apply Rules ist es spielend einfach möglich Services zu erstellen. Möchte man mehrere, gleiche Services erstellen (z. B. mehrere Port-Checks oder SNMP-Counteer) kommt Apply For zum Einsatz.

Im Zusammenhang mit dem Icinga Director erhalten wir ab und an Fragen zur Konfiguration von Apply For und sehr oft stellt sich dabei heraus das die Erklärung dieser Konfiguration per E-Mail oder Telefon sehr umständlich ist. Daher habe ich ein kleines Video für euch vorbereitet.

 

Schönes Wochenende! 🙂

Tobias Redel

Autor: Tobias Redel

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Icinga 2 – Monitoring automatisiert mit Puppet: “Icinga 2”-Agent

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

Nachdem Lennart sich bereits mit vielen Aspekte des Moduls befasst hat, will ich dieses Mal auf die Installation von Icinga 2 als Agenten eingehen. Neben einem generellen Einstieg mit zu beachtenden Konfigurationsoptionen, will ich hierbei auf die verschiedenen Möglichkeiten für die benötigten Zertifikate und Anbindung an die übergeordnete Zone eingehen.

Puppet-Icinga2

Die Installation und Feature-Konfiguration erfolgt wie Lennart dies in den ersten beiden Teilen der Serie beschrieben hat. Hierbei möchte ich beim Agent sicherstellen, dass keine lokale Konfiguration angezogen wird, da ich für die Verteilung der CheckCommands die Konfigurationssynchronisation von Icinga 2 nutzen möchte. Alternativ können diese zwar auch über Puppet verteilt werden, da ja auch die Plugins installiert werden müssen, aber in den meisten Umgebungen trenne ich an dieser Stelle Konfiguration der Monitoring-Infrastruktur von der eigentlichen Monitoring-Konfiguration. Der Start meines Agenten-Profils sieht also meist so aus:

  class { 'icinga2':
    confd       => false,
    manage_repo => true,
    features    => ['checker','mainlog'],
  }

(more…)

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 4: Konfiguration II

Heute werden wir uns die Define Resource icinga2::object::host zum konfigurieren eines Host-Objekts anschauen und auch Services via apply-Regeln an diesen Host binden.

::icinga2::object::host { 'NodeName':
  target  => '/etc/icinga2/example.d/my_hosts.conf',
  import  => [ 'generic-host' ],
  address => '127.0.0.1',
}

Generell kann bei Objekten mit target angegeben werden in welche Datei sie geschrieben werden. Auch lässt sich mit dem Parameter order Einfluss auf die Reihenfolge der einzelnen Objekte in der jeweiligen Datei nehmen. Der Defaultwert für Host-Objekte ist 50, möchte man nun ein weiteres Host-Objekt davor einfügen, ist bei diesem order auf einen Wert kleiner 50 zu setzen. Das funktioniert mit anderen Objekttypen auf die gleiche Weise. So werden z.B. Hostgruppen oder Services mit einer order von 55 bzw. 60 standardmäßig hinter Hosts einsortiert. Um das mittels import eingebundene Template generic-host vor dem Host in die Datei zu schreiben muss im folgenden Codebeispiel order explizit gesetzt werden, da auch ein Host-Template aus icinga2::object::host erzeugt wird und damit den Defaultwert 50 hat.

::icinga2::object::host { 'generic-host':
  template           => true,
  target             => '/etc/icinga2/example.d/my_hosts.conf',
  order              => '47',
  check_interval     => '1m',
  retry_interval     => 30,
  max_check_attempts => 3,
  check_command      => 'hostalive',
}

Der Titel, also der Name des Objektes, und Werte aller Attribute werden durch einen einfachen Parser ausgewertet. So werden Zahlen als solche erkannt, auch wenn sie in Puppet als String geschrieben sind. Das gilt auch für Zeitabstände wie 1h, 1m oder 1s. Auch Konstanten werden erkannt, dadurch wird NodeName als solche erkannt und in der Icinga-Konfiguration nicht gequotet als Konstanten geschrieben. Die erzeugte Konfigurationsdatei sieht dann wie folgt aus:

template Host "generic-host" {
  check_interval = 1m
  retry_interval = 30
  max_check_attempts = 3
  check_command = "hostalive"
}

object Host NodeName {
  import "generic-host"
  address = "127.0.0.1"
}

Ein einzelnes Service-Objekt wird äquivalent erstellt. Möchte man jedoch mittels Apply den Service mehreren Hosts zuordnen geht dies mit Puppet ebenfalls, der Parameter apply muss hier lediglich auch true gesetzt werden.

::icinga2::object::service { 'ping4':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => true,
  import        => [ 'generic-service' ],
  check_command => 'ping4',
  assign        => [ 'host.address' ],
}

Die Assign- bzw. Ignore-Ausdrücke werden über die Parameter assign bzw. ignore definiert. Die Werte müssen als Array zugewiesen werden. Aus den einzelnen Elemente werden jeweils Assign- bzw. Ignore-Ausdrücke erzeugt.

apply Service "ping4" to Host {
  import "generic-service"

  check_command = "ping4"
  assign where host.address
}

Custom-Attribute können in beliebiger Anzahl dem Parameter vars als Dictionary-Elemente zugewiesen werden. So erzeugt dieser zusätzlich Puppet-Code für das oben beschriebene Host-Objekt,

  vars => {
    os     => 'Linux',
    disks  => {
      'disk /' => {
        disk_partition => '/',
      },
    },

die folgenden Zeilen Icinga-Konfiguration:

  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }

Der Parser kann auch komplexere Ausdrücke korrekt bearbeiten, wie in assign des folgenden Services ssh.

::icinga2::object::service { 'ssh':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => true,
  import        => [ 'generic-service' ],
  check_command => 'ssh',
  assign        => [ '(host.address || host.address6) && host.vars.os == Linux' ],
}

Attribute aus dem Host-Kontext wie auch die Operatoren werden korrekt erkannt, das Wort Linux ist nicht bekannt und damit gequotet dargestellt. Alle bekannten Wörter werden ohne Quotes geschrieben. Bekannte Wörter sind neben dem Objekt-Titel, alle Objekt-Attribute, Custom-Attribute, die Konstanten der Icinga-Instanz und eine in icinga2::params::globals definierte Liste.

apply Service "ssh" to Host {
  import "generic-service"

  check_command = "ssh"
  assign where (host.address || host.address6) && host.vars.os == "Linux"
}

Um nun via Puppet auch die folgende Konfiguration modellieren zu können,

apply Service for (fs => config in host.vars.disks) to Host {
  import "generic-service"

  check_command = "disk"
  vars = vars + config
}

Hierzu setzt man den Parameters apply auf einen String, der dem Zuweisungsteil einer Icinga-Foreach-Schleife für Services entspricht. Wichtig hier zu beachten ist, das fs und config nun auch bekannte Wörter sind und nicht gequotet werden. Nähme man anstatt fs z.B. disk, hätte das zur Folge, das die Zeile check_command, mit disk ohne Quotes geschrieben wird. Damit ist dann aber leider die Konfiguration nicht korrekt, die Validierung schlägt fehl und ein Neustart von Icinga wird nicht ausgeführt.

::icinga2::object::service { 'disk':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => 'fs => config in host.vars.disks',
  import        => [ 'generic-service' ],
  check_command => 'disk',
  vars          => 'vars + config',
}

Zu den bisher erschienen Artikel dieser Serie geht es hier.

Lennart Betz

Autor: Lennart Betz

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.

Monthly Snap May < GitLab CE, Icinga 2, NWS, OSDC, Ubuntu, Graphite, Puppet, SuiteCRM

In May, Achim started with GitLab CE, while Florian presented Vanilla.
Then, Lennart wrote the fifth part of his Icinga Best Practices and Isabel told us about the MultiTech MTD-H5-2.0.
Martin K. continued with external monitoring of websites and services with Icinga 2 while Julia gave a triple hurray to our OSDC-sponsors. Stefan G. gave an insight in his „Mission Loadbalancer Upgrade“ and Blerim tested Ruby applications with RSpec and WebMock.
Lennart published part 3 and 4 of „Icinga 2 – Automated Monitoring with Puppet“, Martin K. showed the benefits of our SuiteCRM Hosting while Marius G. told us the upcoming death of Ubuntu Unity.
May went on with the OSDC in Berlin and the reports from Isabel, Julia, Michi and Dirk.
Then Thomas Widhalm continued with the Carbon Relay for Graphite and Christian wrote about the Icinga 2 Satellite in NWS.
Towards the end of May, Christian announced some new webinars and Gabriel gave an insight in his work at NETWAYS!

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Incredible Icinga Camp Bangalore

Anfang Mai war es so weit: Für mich ging’s ab nach Indien – genauer gesagt nach Bangalore, das eigentlich seit 2014 Bengaluru heißt und das IT-Zentrum des Landes darstellt. Dort fand im Rahmen der diesjährigen rootconf das erste Icinga Camp überhaupt in Indien statt.

Bereits bei Gesprächen mit Teilnehmern auf der zweitägigen rootconf zeichnete sich reges Interesse an Icinga und natürlich insbesondere Icinga 2 ab. Nicht zuletzt trug auch Bernd mit seinem Vortrag “State of the open source monitoring landscape” im Premiumslot direkt nach der Begrüßung im Hauptsaal der rootconf einen großen Teil dazu bei.

Am 13. Mai, Samstag dem Tag nach der rootconf, war es nun an der Zeit für das zusammen mit HasGeek veranstaltete Icinga Camp in der Thought Factory der Axis Bank. Obowohl (oder vielleicht auch “weil”) der Samstag in Indien eigentlich ein Arbeitstag ist, hatten es viele Interessierte auf das Camp geschafft. Nach Begrüßung und einer kurzen Einführung in den aktuellen Entwicklungsstand von Icinga durch Bernd übernahm Aditya Raj von Snapdeal, einem sehr großen Onlineshopbetreiber in Indien, und gab einen Einblick wie der Einsatz von Icinga 2 dort mittels SaltStack automatisiert wurde.

Nach einer kurzen Kaffepause verdeutlichte Hariram Hari von Fortidm Technologies die Erwartungshaltung aus Großunternehmenssicht an eine Monitoringlösung wie Icinga, bevor dann Toshaan Bharvani von VanTosh detailliert drauf einging wie Icinga 2 mit Ansible provisioniert werden kann. Es folgte zur Stärkung die Mittagspause und dann war auch meine Vortragspremiere gekommen. Mit vielen Slides zeigte ich die vielen Integrations- bzw. Erweiterungsmöglichkeiten von Icinga 2 mit anderen Tools auf.

Roy Peter von Bluejeans Network referierte über die Einsatzmöglichkeiten der Icinga 2 API und zeigte hier insbesondere die automatische Aufnahme neuer AWS Nodes in das Monitoringsystem. Im anschließenden Vortrag ging Bernd noch genauer auf den Director ein, bevor das Camp durch eine offene Runde mit sehr viel Beteiligung einen würdigen Abschluss fand.

Insgesamt bestätigte das Icinga Camp und v.a. die vielen Wortmeldungen nach den Vorträgen (mal wieder) die Verbreitung und das Potenzial von Icinga auch außerhalb der sonst gewohnten Kundschaft von NETWAYS.

Für mich war Bangalore als sog. “Silicon Valley” von Indien eine Chance die ich gerne wahr genommen habe und persönliches Highlight, an das ich mich sicher lange erinnern werde.

PS: Natürlich sind in gewohnter Manier auch wieder Slides und Bilder des Icinga Camps online verfügbar.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Flexible and easy log management with Graylog

This week we had the pleasure to welcome Jan Doberstein from Graylog. On Monday our consulting team and myself attended a Graylog workshop held by Jan. Since many of us are already familiar with log management (e.g. Elastic Stack), we’ve skipped the basics and got a deep-dive into the Graylog stack.

You’ll need Elasticsearch, MongoDB and Graylog Server running on your instance and then you are good to go. MongoDB is mainly used for caching and sessions but also as user storage e.g. for dashboards and more. Graylog Server provides a REST API and web interface.

 

Configuration and Inputs

Once you’ve everything up and running, open your browser and log into Graylog. The default entry page greets you with additional tips and tricks. Graylog is all about usability – you are advised to create inputs to send in data from remote. Everything can be configured via the web interface, or the REST API. Jan also told us that some more advanced settings are only available via the REST API.

 

If you need more input plugins, you can search the marketplace and install the required one. Or you’ll create your own. By default Graylog supports GELF, Beats, Syslog, Kafka, AMQP, HTTP.

One thing I also learned during our workshop: Graylog also supports Elastic Beats as input. This allows even more possibilities to integrate existing setups with Icingabeat, filebeat, winlogbeat and more.

 

Authentication

Graylog supports “internal auth” (manual user creation), sessions/tokens and also LDAP/AD. You can configure and test that via the web interface. One thing to note: The LDAP library doesn’t support nested groups for now. You can create and assign specific roles with restrictions. Even multiple providers and their order can be specified.

 

Streams and Alerts

Incoming messages can be routed into so-called “streams”. You can inspect an existing message and create a rule set based on these details. That way you can for example route your Icinga 2 notification events into Graylog and correlate events in defined streams.

Alerts can be defined based on existing streams. The idea is to check for a specific message count and apply threshold rules. Alerts can also be reset after a defined grace period. If you dig deeper, you’ll also recognise the alert notifications which could be Email or HTTP. We’ve also discussed an alert handling which connects to the Icinga 2 API similar to the Logstash Icinga output. Keep your fingers crossed.

 

Dashboards

You can add stream message counters, histograms and more to your own dashboards. Refresh settings and fullscreen mode are available too. You can export and share these dashboards. If you are looking for automated deployments, those dashboards can be imported via the REST API too.

 

Roadmap

Graylog 2.3 is currently in alpha stages and will be released in Summer 2017. We’ve also learned that it will introduce Elasticsearch 5 as backend. This enables Graylog to use the HTTP API instead of “simulating” a cluster node at the moment. The upcoming release also adds support for lookup tables.

 

Try it

I’ve been fixing a bug inside the Icinga 2 GelfWriter feature lately and was looking for a quick test environment. Turns out that the Graylog project offers Docker compose scripts to bring up a fully running instance. I’ve slightly modified the docker-compose.yml to export the default GELF TCP input port 12201 on localhost.

vim docker-compose.yml

version: '2'
services:
mongo:
image: "mongo:3"
elasticsearch:
image: "elasticsearch:2"
command: "elasticsearch -Des.cluster.name='graylog'"
graylog:
image: graylog2/server:2.2.1-1
environment:
GRAYLOG_PASSWORD_SECRET: somepasswordpepper
GRAYLOG_ROOT_PASSWORD_SHA2: 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
GRAYLOG_WEB_ENDPOINT_URI: http://127.0.0.1:9000/api
depends_on:
- mongo
- elasticsearch
ports:
- "9000:9000"
- "12201:12201"


docker-compose up

 

Navigate to http://localhost:9000/system/inputs (admin/admin) and add additional inputs, like “Gelf TCP”.
I just enabled the “gelf” feature in Icinga 2 and pointed it to port 12201. As you can see, there’s some data running into. All screenshots above have been taken from that demo too 😉

 

More?

Jan continued the week with our official two day Graylog training. From a personal view I am really happy to welcome Graylog to our technology stack. I’ve been talking about Graylog with Bernd Ahlers at OSMC 2014 and now am even more excited about the newest additions in v2.x. Hopefully Jan joins us for OSMC 2017, Call for Papers is already open 🙂

My colleagues are already building Graylog clusters and more integrations. Get in touch if you need help with integrating Graylog into your infrastructure stack 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉