Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

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

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 sollte 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

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.

Manage Elasticsearch, Kibana & icingabeat with Puppet

A while back I’ve already looked into the Elastic Stack 5 Beta release and the beats integration. Time flies and the stable release is here. Blerim announced the icingabeat 1.0.0 release last week, and so I was looking into a smooth integration into a Vagrant box here.

The provisioner uses Puppet, which Puppet modules could be used here? I’m always looking for actively maintained modules, best by upstream projects which share the joy of automated setups of their tools with their community.

 

Elastic and Kibana Puppet Module

The Elastic developers started writing their own Puppet module for Kibana 5.x. Previously I’ve used community modules such as puppet-kibana4 or puppet-kibana5. puppet-elasticsearch already supports 5.x for a while, that works like a charm.

Simple example for a low memory Elasticsearch setup:

class { 'elasticsearch':
  manage_repo  => true,
  repo_version => '5.x',
  java_install => false,
  jvm_options => [
    '-Xms256m',
    '-Xmx256m'
  ],
  require => Class['java']
} ->
elasticsearch::instance { 'elastic-es':
  config => {
    'cluster.name' => 'elastic',
    'network.host' => '127.0.0.1'
  }
}

Note: jvm_options was released in 5.0.0.

 

Default index pattern

If you do not define any default index pattern, Kibana greets you with a fancy message to do so (and I have to admit – i still need an Elastic Stack training to fully understand why). I wanted to automate that, so that Vagrant box users don’t need to care about it. There are several threads around which describe the deployment by sending a PUT request to the Elasticsearch backend.

I’m using a small script here which waits until Elasticsearch is started. If you don’t do that, the REST API calls will fail later on. This is also required for specifying index patterns and importing dashboards. A Puppet exec timeout won’t do the trick here, because we’ll have to loop and check again if the service is available.

$ cat/usr/local/bin/kibana-setup
#!/bin/bash

ES_URL="http://localhost:9200"
TIMEOUT=300

START=$(date +%s)

echo -e "Restart elasticsearch instance"
systemctl restart elasticsearch-elastic-es

echo -e "Checking whether Elasticsearch is listening at $ES_URL"
until $(curl --output /dev/null --silent $ES_URL); do
  NOW=$(date +%s)
  REAL_TIMEOUT=$(( START + TIMEOUT ))
  if [[ "$NOW" -gt "$REAL_TIMEOUT" ]]; then
    echo "Cannot reach Elasticsearch at $ES_URL. Timeout reached."
    exit 1
  fi
  printf '.'
  sleep 1
done

If you would want to specify the default index pattern i.e. for an installed filebeat service, you could something like this:

ES_INDEX_URL="$ES_URL/.kibana/index-pattern/filebeat"
ES_DEFAULT_INDEX_URL="$ES_URL/.kibana/config/5.2.2" #hardcoded program version

curl -XPUT $ES_INDEX_URL -d '{ "title":"filebeat", "timeFieldName":"@timestamp" }'
curl -XPUT $ES_DEFAULT_INDEX_URL -d '{ "defaultIndex":"filebeat" }'

One problem arises: The configuration is stored by Kibana program version. There is no symlink like ‘latest’, but you’ll need to specify ‘.kibana/config/5.2.2’ to make it work. There is a certain requirement for pinning the Kibana version, or finding a programatic way to automatically determine the version.

 

Kibana Version in Puppet

Fortunately the Puppet module allows for specifying a version. Turns out, the class validation doesn’t support package revision known from rpm (“5.2.2-1”). Open source is awesome – you manage to patch it, apply tests and after review your contributed patch gets merged upstream.

Example for Kibana with a pinned package version:

$kibanaVersion = '5.2.2'

class { 'kibana':
  ensure => "$kibanaVersion-1",
  config => {
    'server.port' => 5601,
    'server.host' => '0.0.0.0',
    'kibana.index' => '.kibana',
    'kibana.defaultAppId' => 'discover',
    'logging.silent'               => false,
    'logging.quiet'                => false,
    'logging.verbose'              => false,
    'logging.events'               => "{ log: ['info', 'warning', 'error', 'fatal'], response: '*', error: '*' }",
    'elasticsearch.requestTimeout' => 500000,
  },
  require => Class['java']
}
->
file { 'kibana-setup':
  name => '/usr/local/bin/kibana-setup',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/kibana-setup",
}
->
exec { 'finish-kibana-setup':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/kibana-setup",
  timeout => 3600
}

 

Icingabeat integration

That’s fairly easy, just install the rpm and put a slightly modified icingabeat.yml there.

$icingabeatVersion = '1.0.0'

yum::install { 'icingabeat':
  ensure => present,
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-$icingabeatVersion-x86_64.rpm"
}->
file { '/etc/icingabeat/icingabeat.yml':
  source    => 'puppet:////vagrant/files/etc/icingabeat/icingabeat.yml',
}->
service { 'icingabeat':
  ensure => running
}

I’ve also found the puppet-archive module from Voxpupuli which allows to download and extract the required Kibana dashboards from icingabeat. The import then requires that Elasticsearch is up and running (referencing the kibana setup script again). You’ll notice the reference to the pinned Kibana version for setting the default index pattern via exec resource.

# https://github.com/icinga/icingabeat#dashboards
archive { '/tmp/icingabeat-dashboards.zip':
  ensure => present,
  extract => true,
  extract_path => '/tmp',
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-dashboards-$icingabeatVersion.zip",
  checksum => 'b6de2adf2f10b77bd4e7f9a7fab36b44ed92fa03',
  checksum_type => 'sha1',
  creates => "/tmp/icingabeat-dashboards-$icingabeatVersion",
  cleanup => true,
  require => Package['unzip']
}->
exec { 'icingabeat-kibana-dashboards':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/share/icingabeat/scripts/import_dashboards -dir /tmp/icingabeat-dashboards-$icingabeatVersion -es http://127.0.0.1:9200",
  require => Exec['finish-kibana-setup']
}->
exec { 'icingabeat-kibana-default-index-pattern':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "curl -XPUT http://127.0.0.1:9200/.kibana/config/$kibanaVersion -d '{ \"defaultIndex\":\"icingabeat-*\" }'",
}

The Puppet code is the first working draft, I plan to refactor the upstream code. Look how fancy 🙂

Conclusion

Managing your Elastic Stack setup with Puppet really has become a breeze. I haven’t tackled the many plugins and dashboards available, there’s so much more to explore. Once you’ve integrated icingabeat into your devops stack, how would you build your own dashboards to correlate operations maintenance with Icinga alerts? 🙂

If you’re interested in learning more about Elastic and the awesome Beats integrations, make sure to join OSDC 2017. Monica Sarbu joins us with her talk on “Collecting the right data to monitor your infrastructure”.

PS: Test-drive the integration, finished today 🙂

 

 

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 😉

NETWAYS Web Services: Icinga 2 Master

This entry is part 6 of 7 in the series NETWAYS Web Services

Letzte Woche haben wir bei den NETWAYS Web Services den Icinga 2 Satellite vorgestellt, welcher sich schnell und einfach zur Überwachung von externen Diensten, Anwendungen und Webseiten über das Icinga 2 Clusterprotokoll in die eigene Icinga 2 Umgebung integrieren lässt. Wenn man aber nach einer Standalone-Lösung sucht, die alle Features und die passenden Addons von Icinga 2 gleich mitbringt, kann bei NWS zum Icinga 2 Master greifen.

Der Icinga 2 Master bietet alles, was man für eine eigenständige Icinga 2 Überwachungsumgebung braucht:

Icinga Director

Der Icinga Director vereinfacht die Konfiguration von Hosts und Services. Dazu stellen wir auch einen Satz an vorkonfigurierten Checks zur Verfügung, welche Ihnen die Arbeit mit Icinga 2 deutlich erleichtern.

Icinga Web 2

Mit Icinga Web 2 hat man den perfekten Blick auf die aktuellen Probleme, kann sich je nach Bedarf Dashboards bauen und alle neu im Monitoring aufgenommenen Systeme werden sofort angezeigt.

Graphite und Grafana

Mit den Performancedaten aus Icinga 2, welche über Graphite in Grafana dargestellt und gefiltert werden, können Probleme auf einfache Art und Weise visualisiert werden. Die Metriken werden für 12 Monate aufbewahrt.

Icinga 2 API
Natürlich ermöglichen wir den vollen Zugriff auf die Icinga 2 API, womit Sie mit dem Icinga 2 Master vollautomatisiert arbeiten können.

Externe Überwachung
Mit dem Icinga 2 Master kann man wie beim Icinga 2 Satellite externe Dienste, Anwendungen und Webseiten überwachen, mit dem verfügbaren Addons dann aber auch gleich konfigurieren, verwalten und ermittelten Werte live im Icinga Web 2 und Grafana betrachten. Somit kann man sich eine eigenständige Überwachungsumgebung aufbauen, wenn man z.B. für Kundenprojekte keinen Zugriff auf sein internes Monitoring gewähren und dies sauber trennen will oder man für ein bestimmtes Projekt eine eigene Lösung sucht.

Integration mit meiner eigenen Umgebung
Natürlich kann man mit dem Icinga 2 Master auch über das Icinga 2 Clusterprotokoll im Einsatz befindliche Icinga 2 Agents anbinden. Somit lässt sich der Icinga 2 Master zur kompletten Monitoringumgebung ausbauen, welche dann auch Überwachungen im (kunden-)eigenen Netz fahren kann. Wir bieten hierzu fertige Integrationsskripte für folgende Betriebssysteme:

  • Debian/Ubuntu
  • CentOS/Fedora
  • SuSe/OpenSuSe
  • Windows

Jetzt anmelden und für 30 Tage kostenfrei testen!

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

NETWAYS Web Services: Icinga 2 Satellite

This entry is part 5 of 7 in the series NETWAYS Web Services

Icinga 2 ist bei vielen Unternehmen in allen Größenordnungen im Einsatz und ermöglicht die Überwachung von Servern, Anwendungen, Netzwerkhardware, Diensten, Webseiten uvm.. Allerdings stößt man beim Monitoring von externen Diensten auf ein Problem – es fehlt in den meisten Fällen der Blick von außen. So kann man zwar aus dem eigenen Netz alles überwachen, ob Ihr Kunde aber alles sehen und nutzen kann, lässt sich auf diese Weise nicht 100%-ig sicherstellen.

Praktischerweise verfügt Icinga 2 mit seinem Cluster- und Zonenkonzept über eine erprobte Möglichkeit, Icinga 2 Satelliten in seine eigene Monitoringumgebung einzubauen. Und wenn man externe Dienste überwachen will, muss diese Zone dann auch am besten außerhalb des eigenen Netzwerkes stehen.

Mit unseren NETWAYS Web Services können wir genau dies für Sie anbieten – einen komplett gemanagten Icinga 2 Satelliten.

Icinga 2 Satellite

Welche Checks bieten wir an?

  • Web service checks
    HTTP(S)
  • E-Mail service checks
    IMAP/POP3, SMTP
  • Availability checks
    Ping, ICMP, TCP/UDP
  • Icinga 2
    Icinga 2’s customized protocol

 

Welche Standorte stehen zur Verfügung?

  • US West
    North California
  • Europe
    Nuremberg
  • Asia/Pacific
    Tokyo

 

Mit einem extern bei NWS gehosteten Icinga 2 Satelliten können Sie sicherstellen, dass Ihre Dienste auch immer aus Kundensicht überwacht werden. Jetzt schnell anmelden und 30 Tage kostenfrei testen!

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

AB HEUTE LIVE: NWS – NETWAYS Web Services

Im kleinen Kreis haben wir unsere neue Plattform bereits auf der OSMC gezeigt, ab heute sind wir aber für alle am Start und dürfen mit großen Stolz verkünden: NWS ist live!

Die NETWAYS Web Services (NWS) sind ein SaaS Angebot, welches komplett auf die Bereitstellung von Open Source Anwendungen setzt.

Die Anmeldung und der Start der ersten Anwendung ist in wenigen Minuten erledigt und alle Tools können in den ersten 30 Tagen kostenfrei getestet werden. Mit NWS können Sie sich voll auf Ihr Business konzentrieren – wir übernehmen den kompletten Betrieb der jeweiligen Anwendung.

Hier finden Sie die aktuell verfügbaren Apps:

Icinga 2 Satellite

Ihr persönlicher Icinga 2 Satellite an drei Wunschstandorten: Europa (Nürnberg), USA (Kalifornien) und Asien (Tokyo). Überwachen Sie Ihre Dienste aus Kundensicht und integrieren Sie den Satelliten ganz einfach und sicher in Ihr Icinga 2 Monitoring.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) und einfache Integration in eine bestehende Icinga 2 Installation über das Icinga 2 Clusterprotokoll.

Icinga 2 Master

Der komplette Icinga 2 Stack als eigenständiges System in drei verschiedenen Größen für jeden Einsatzzweck.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) als Standalone-System mit Icinga Web 2, Icinga Director und Grafana. Natürlich ist Icinga 2 API voll nutzbar.

 

Rocket.Chat

Rocket.Chat ist die Open Source Lösung für den Chat (intern und extern), Video-Chat und Screensharing, File-Sharing und als Helpdesk Chat-Lösung für jede Unternehmensgröße.

Einsatzzweck: Unternehmensinterne Kommunikation für agile Teams und als Channel für den einfachen Dialog mit Ihren Kunden.

Nextcloud

Nextcloud ist die Filesync und -share-Lösung für Unternehmen.

Einsatzzweck: Sicheres Filesharing in Ihrem Unternehmen und mit Ihren Kunden und Nutzung einer webbasierten Office Lösung, welche die Bearbeitung von Dokumenten im Team ermöglicht.

More to come

Wir bauen NWS kontinuierlich aus und werden in den nächsten Monaten noch viele spannende Open Source Tools aufnehmen.

Hier die Projekte der nächsten Monate:

 

Sie vermissen eine Anwendung? Wir freuen uns über Ihre Kontaktaufnahme.

Webinar

Sie wollen noch mehr zu den NETWAYS Web Services erfahren? Mein Kollege Christian Stein stellt die Plattform in einem Webinar am 15. März um 10:30h vor.

Jetzt schnell kostenlos anmelden!

Was steckt dahinter?

Wir haben die komplette Umgebung natürlich nur mit Open Source Mitteln gebaut. Wer mehr wissen will, meldet sich umgehend zur OSDC 2017 in Berlin an und lauscht Sebastians Vortrag.

Vielen Dank an dieser Stelle an unser NWS-Team für den tollen Einsatz und wir freuen uns auf Fragen und Feedback rund um unser neues Angebot.

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Ja ist denn schon wieder Webinar Zeit?

Auch in diesem Jahr wollen wir natürlich wieder effektiv mit unseren Webinaren auf Neuheiten im Open Source Bereich, sei es Icinga 2, Ansible, uvm. oder auf Produktneuheiten in unserem Online-Store, wie bspw. die neue Braintower Firmware hinweisen.

Die folgenden Themen und Termine stehen Stand heute schon fest:

Titel Zeitraum Registrierung
Server-Überwachung mit Icinga 2 15. Februar 2017 – 10:30 Uhr Anmelden
Icinga Director: Neues vom Config Tool 02. März 2017 – 10:30 Uhr Anmelden
Braintower: Neuheiten in Firmware 3.5 16. März 2017 – 10:30 Uhr Anmelden
Icinga Web 2: Erstellen und verwalten von Business Prozessen 30. März 2017 – 10:30 Uhr Anmelden
AKCP SP2+: Die Neuheiten und Icinga 2 Integration 27. April 2017 – 10:30 Uhr Anmelden

Selbstverständlich werden die Webinare wieder aufgezeichnet und sind anschließend in unserem Webinar Archiv verfügbar.

Wir freuen uns über eine rege Teilnahme!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".