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):

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

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.

Lies mehr von Stefan und triff unser Team

Icinga 2 Best Practice Teil 2: Konfiguration synchronisieren

Im heutigen Teil 2 dieser Serie, befassen wir uns mit Konfiguration und deren Synchronisation zwischen Icinga 2 Instanzen in verteilten Umgebungen. Hierbei ist eine solche verteilte Umgebung schon gegeben, wenn der Agent zum Einsatz kommt, also immer wenn Endpoints und Zones beteiligt sind. In Teil 1 wurde Tipps zur Konfiguration der Verbindungsdaten gegeben, heute vertiefen wir, was auf dem Agenten passiert und was dort zusätzlich zum Icinga 2 Core benötigt wird.
Zuerst werden die jeweiligen Plugins auf den Agenten benötigt, seien es für Linux die Monitoring-Plugins oder auf der Windows-Seite die nativen aus dem Icinga-Projekt oder die Plugins vom NSClient++. Bei Icinga, auch in der neuen Version 2, ist das Objekt vom Typ CheckCommand das Bindeglied zwischen Host- bzw. Service-Objekt und dem konfigurierten Plugin, was zur Statusermittlung aufzurufen ist. Wobei ein lokal auszuführender Host-Check üblicherweise nicht Praxisrelevant ist. Das CheckCommand beschreibt wie das Plugin aufzurufen ist, den Ort im Dateisystem wie auch mit welchen Optionen das Plugin ausgeführt wird.

object CheckCommand "mem" {
  command = [ PluginContribDir + "/check_mem.pl" ]
  arguments = {
    "-u" = {
      set_if = "$mem_used$"
      description = "Check USED memory"
    }
...

Für die Pfadangabe zum Plugin ist immer die Verwendung einer Konstanten zu empfehlen, da sich der Ort von Plattform zu Plattform unterscheiden kann und eine Konstante ist für jede Instanz und damit für jeden Agenten gesondert setzbar. Standardmäßig sollten Konstanten in constants.conf im Icinga-Konfigurationsverzeichnis definiert werden.
Beim Plugin check_mem.pl im obigen Beispiel handelt es sich nicht um eines vom Monitoring-Plugin-Projekt, sondern um eines was gesondert auf den Agenten zu installieren ist. Ausserdem benötigen die Icinga-Instanzen der Agenten obige Definition. Für das CheckCommand mem wird diese schon in der ITL (Icinga Template Library) mit geliefert und muss nicht selbst erstellt werden. Auf den jeweiligen Agenten ist lediglich die Definition in icinga2.conf als include einzubinden. Sie befindet sich im PluginContrib-Bereich der ITL.

include <plugins>
include <plugins-contrib>

In plugins hingegen befinden sich die Definitionen zu Plugins aus dem Monitoring-Projekt. Bei Windows empfiehlt sich die Definitionen der nativen (windows-plugins) bzw. NSClient++-Plugins (nscp) einzubinden.
Was aber nun, wenn man nun für ein Plugin selbst ein CheckCommand-Objekt anlegen muss? Es jeweils auf allen Agenten in die ITL legen? Nein, der ITL-Bereich ist ausschließlich für vom Projekt gepflegte Objekte, eigene würden beim nächsten Update wieder verschwinden. Ausserdem ist eine zusätzliche Pflege von sich ändernden Konfigurationsdateien für jeden Agenten nicht erstrebenswert. Hier kommen nun globale Zonen ins Spiel, die einem Konfiguration auf beliebige Endpoints synchronisieren und automatisch laden.

object Zone "linux-commands" {
  global = true
}
object Zone "windows-commands" {
  global = true
}

Im Gegensatz zum Server bzw. Master und Satelliten-Systemen, ist auf den Windows- und Linux-Agenten nur die entsprechende Zone in der zones.conf einzutragen. In beiden werden auch wirklich nur CheckCommands hinterlegt, Services und Templates werden in der Regel nicht auf Agenten benötigt und sind damit Informationen die besser nicht leicht zugänglich sowie zentral gehalten werden.
Windows kennt leider keinen graceful restart bzw. reload wie Unixsysteme und somit ist hier die Trennung sinnvoll, da Windows einen Stop des Dienstes und nachgelagertem Start nur ausführen muss, wenn es wirklich nötig ist.
Teil 3 dieser Reihe wird sich dann mit praktischen Definition von Services beschäftigen und wie diese ausschließlich aus den zugehörigen Host-Objekten parametresiert werden.

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