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.

Selbstentwickelte Anwendungen überwachen

Die Basis

Bei selbstentwickelten Anwendungen stellt sich häufig die Frage wie sich diese im Monitoringsystem überwachen lassen.
Häufig läuft es dann darauf hinaus das einzelne Komponenten der Anwendung überwacht werden. Der Webserver, die Datenbank, eventuell der Applicationserver oder die Messagequeue die von der Anwendung benötigt wird. Das alles ist ein Solides Grundgerüst auf dem sich aufbauen lässt.

Die Anwendung verrät Ihren Status

In einer agilen (Web-)Plattform ist es aber hilfreich wenn die Anwendung etwas über ihren Status verrät. Welches Softwarelease ist ausgerollt und passt die Version des Datenbank Schemas zu dieser Version? Erreicht der Server seine Failover Systeme und sind diese OK?
Die Software kann aber noch mehr über sich verraten. Wie ist der Gesamtstatus der Software? Dieser ist nur OK wenn alle einzelnen Prüfungen OK sind.
Wünschen sich Entwickler oder Admins bestimmte Infos auf einer Infoseite oder einer API, lassen sich diese häufig recht einfach implementieren.
Hier das Beispiel einer möglichen API Ausgabe:

{
  "health": {
    "status": "OK"
  },
  "checks": [
    {
      "version": "1.0.1"
    },
    {
      "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
    },
    {
      "nodeid": "node2"
    }
  ],
  "cluster": [
    {
      "node1": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    },
    {
      "node2": [
        {
          "status": "MAINTENANCE"
        },
        {
          "version": "1.0.1"
        },
        {
          "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
        }
      ]
    },
    {
      "node3": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    }
  ]
}

Die Informationen im Monitoring nutzen

Im Monitoring lassen sich einzelne Werte zum Beispiel mit check_http auswerten, indem man auf den zu erwartenden String prüft. Mit check_multi lassen sich diese Infos dann mit anderen Checks verknüpfen. Die Kollegen in der Rufbereitschaft freuen sich über weitere Anhaltspunkte, wo das Problem zu suchen ist.

Hilfe bei der Automatisierung

Diese Infos sind zum Beispiel bei Continuous Delivery Szenarien enorm hilfreich. Das CI System kann prüfen ob der Rollout der ersten Knotens erfolgreich war und diesen dann z.B. über einen API Call wieder als Live markieren, das Monitoring System beendet die Downtime und der Loadbalancer nimmt den Knoten wieder in die Verteilung.

Braintower SMS Gateway – Icinga Plugin verfügbar!

icinga_logo_200x69Trotz Weihnachten und dem bevorstehenden Jahreswechsel sind wir natürlich nicht untätig und stehts dabei unser Portfolio an Plugins weiter auszubauen. Heute möchte ich die Gelegenheit nutzen, um zum Jahresende ein nützliches Plugin für die Überwachung unserer Braintower Geräte mit Icinga vorzustellen.
Das kleine Python-Plugin bedient sich dabei der Statusseite des Gateways und liefert unter anderem Informationen über die Failed-Queue, die Signalstärke sowie die Uptime.
Will man das Gateways überwachen, ruft man das Plugin einfach mit folgenden Parametern auf:

./check_braintower -H 192.168.1.1 --signal-warning -85 --signal-critical -90

Die Werte der Parameter muss natürlich jeder auf seine Bedürfnisse anpassen 🙂
Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:

BRAINTOWER OK - que: 0 failed: 0 signal: -83db total: 0 state: Idle load: 0;0.03;0.05 time: 1451320254 disk free: 647569408 uptime: 9 min, 0 users

Selbstverständlich kann man nicht nur die Signalstärke überwachen, sondern eine Vielzahl von Parametern. Mit –help erhält man hier eine schöne Erklärung über die Möglichkeiten:

usage: check_braintower [-h] -H HOSTNAME [-T TIMEOUT] [-Q QUEUE] [-F FAIL] [--signal-warning SIGNAL_WARNING] [--signal-critical SIGNAL_CRITICAL]

optional arguments:

-h, –help show this help message and exit
-H HOSTNAME, –hostname HOSTNAME The host address of the SMS Gateway
-T TIMEOUT, –timeout TIMEOUT Seconds before connection times out (default 10)
-Q QUEUE, –queue QUEUE The warning threshold for the amount of queued SMS (default 1)
-F FAIL, –fail FAIL The critical threshold for failed SMS (default 1)
–signal-warning SIGNAL_WARNING The warning threshold for the minimum signal strength (in db, default 0)
–signal-critical SIGNAL_CRITICAL The critical threshold for the minimum signal strength (in db, default 0)

 
Wer das Plugin ausprobieren möchte, kann dies natürlich gerne tun – wir freuen uns über Feedback! Verfügbar ist es auf Icinga Exchange und in unserem NETWAYS Git.

Christian Stein
Christian Stein
Lead Senior Account Manager

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".

Druckermonitoring mit SNMP

Bis zum Paperless Office wird vermutlich noch einige Zeit vergehen und solange sammeln sich in den Firmennetzwerken noch verschiedenste Druckermodelle an. Da ist es nur eine logische Konsequenz das der pflichtbewusste Sysadmin diese auch im Monitoringsystem haben möchte. Immerhin bieten die Printer doch von Seitenzahlen über Tonerständen bis hin zu Hardwarezuständen zahlreiche Abfragewerte.
Glücklicherweise sind die meisten professionellen Druckersysteme bereits von Haus aus per SNMP ansprechbar und stellen die vom Hersteller in der Management Information Base (MIB) hinterlegten Informationen zur Verfügung. Im Normalfall erhält man also bereits bei Ausführung des folgenden Befehls schon sehr viele Rückgabeinformationen:

~# snmpwalk -v 2c -c public PRINTER.mydomain.de

Natürlich ist es mit zusätzlicher Parametrisierung  möglich die Ausgabe auf die relevanten Informationen einzugrenzen. Hier beispielhaft der Aufruf für die Anzahl der gedruckten Seiten:

~# snmpwalk -v 2c -c public PRINTER.mydomain.de 1.3.6.1.2.1.43.10.2.1.4.1.1
SNMPv2-SMI::mib-2.43.10.2.1.4.1.1 = INTEGER: 2185

Solche Informationen lassen sich nun mit check_snmp ordnungsgemäß in Nagios bzw. Icinga integrieren. Um sich die mühsame Suche nach den gewünschten Objekten (OID’s) zu ersparen kann auch auf bereits bestehende Plugins zurückgegriffen werden. Eine guten Anlaufpunkt stellt check_hpjd aus den Standard Nagios Plugins dar. Das Plugin gibt Basisinformationen aus, funktioniert aber leider nicht mit jedem Druckermodell.
Alternativ stehen u.a. bei www.monitoringexchange.org noch zahlreiche weitere Plugins zur Verfügung. So lassen sich auch mit check_printer_info.pl Basisinformationen wie Modell, Seriennummer oder Gesamtseitenanzahl abfragen. Detailliertere Möglichkeiten bietet beispielsweise das in PHP geschriebene Plugin check_printer.php. Damit sammelt man nun sämtliche Counter-, Toner-, Papier-, Hardware- und Druckerteilinformationen ein. Zudem ist eine Ausgabe aller wichtigen Druckermeldungen möglich, was dem Druckeradmin viel Freude bereiten dürfte…

printermonitoring

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin 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. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Twitter Development – Replies und Mentions

twitter-tUm mit anderen Benutzern und deren Tweets zu interagieren gibt es bei Twitter so genannte Replies bzw. Mentions. Der Begriff Mention ist seit März 2009 in Gebrauch. Twitter reagierte auf die Tatsache, dass häufig mehr als ein Benutzer pro Nachricht angesprochen wurde, z.B. sitze im Zug mit @BenutzerA und @BenutzerB. Verbunden damit ist der Hinweis auf den anderen Benutzer somit auch nicht mehr am Anfang der Nachricht und erfordert das Parsing der ganzen Mitteilung.
Für Nutzer besteht der Vorteil von Mentions darin, auch die Nachrichten zu verfolgen, die nicht ausschließlich an sie gerichtet sind aber inhaltlich beziehen. Da die Ermittlung in der API quasi fertig ist, kombiniere ich in folgendem Beispiel zwei API-Calls um die ermittelte Tweets mit Nutzer- und Profilinformationen anzureichern.

package org.netways.api.twitter;
import java.util.List;
import twitter4j.Status;
import twitter4j.Twitter;
import twitter4j.TwitterException;
public class TwitterFunctions {
Twitter twitter;
public TwitterFunctions(String user, String password) {
twitter = new Twitter(user, password);
}
public List getMentions() throws TwitterException {
List mentions = twitter.getMentions();
return mentions;
}
public Status getStatus(long id) throws TwitterException {
Status status = twitter.showStatus(id);
return status;
}
}

Mit den ermittelten Mentions suchen wir danach die Ursprungsnachricht:

package org.netways.api.twitter;
import java.util.Iterator;
import java.util.List;
import twitter4j.Status;
import twitter4j.TwitterException;
import twitter4j.User;
public class TwitterApi {
/**
* @param args
*/
public static void main(String[] args) {
try {
TwitterFunctions tf = new TwitterFunctions("netways", "password");
Status status;
User user;
List statusList = tf.getMentions();
Iterator it = statusList.iterator();
while(it.hasNext()) {
status = it.next();
user = status.getUser();
System.out.println("Sender: " + user.getName());
System.out.println("Screen: " + user.getScreenName());
System.out.println("Location: " + user.getLocation());
System.out.println("Message: " + status.getInReplyToStatusId());
try {
System.out.println("Original: " + tf.getStatus(status.getInReplyToStatusId()).getText());
} catch(TwitterException te) {
System.err.println(te.toString());
}
System.out.println("Text: " + status.getText() + "\n");
}
} catch (Exception e) {
System.err.println(e.toString());
}
}
}

Output der Konsole:

Sender: Sebastian Duschinger
Screen: jackhuaberbauer
Location: Nürnberg / Nuremberg / Bavaria
Message: 2440420942
Original: Treten Sie ein und schauen Sie sich ruhig um: http://digg.com/u17EMH
Text: @netways nice office ;)
........

Durch die Kombination der verschiedenen API-Calls und das durchgängige ID-System für Nachrichten und Personen, können Mentions zu einem Post ermittelt werden oder einfach auch das Antwortverhalten anderer Benutzer auf eigene Tweets untersucht werden.
Der nächste Blogpost widmet sich der Suche von Tweets.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.