fail2ban Monitoring

fail2ban Monitoring

von | Mai 24, 2020 | Linux, Monitoring, Tips und Tricks

fail2ban

Fail2ban ist ein nützliches Werkzeug und ich habe ja schon einmal darüber geschrieben: fail2ban und dynamische IP-Adressen. Heute mal ein etwas anderes Thema welches mich beruflich ebenfalls häufig bewegt: Monitoring.

Also wie würde man vorgehen wenn man einen Check für Nagios, Icinga2, Shinken, ... braucht? Man sucht in der Suchmaschine des Vertrauens oder bemüht eine der Plugin-Sammlungen im Internet. Doch halt, ein Blick ins Repository von fail2ban verrät das ein passender Check bereits mitgebracht wird: https://github.com/fail2ban/fail2ban/tree/master/files/nagios.

Das ist ja mal richtig super 🙂 Was mir jetzt weniger gefällt ist die Ausgabe der Performance-Daten:

CHECK FAIL2BAN ACTIVITY - CRITICAL - 6 detected jails with 195 current banned IP(s) | apache.currentBannedIP=0 dovecot.currentBannedIP=0 fail2ban.currentBannedIP=0 postfix.currentBannedIP=0 roundcube.currentBannedIP=0 sshd.currentBannedIP=195

Viele Monitoringinstallationen die ich betreue verwenden zur Visuallisierung rrd basierte Systeme wie zum Beispiel PNP4Nagios (http://docs.pnp4nagios.org/start). Das ist jetzt weniger toll, da sich bei mir durchaus auch mal die Anzahl der jails ändern kann. Zweitens sind mir diese Daten eigentlich egal, viel interessanter finde ich die Anzahl der Jails sowie die aktuell geblockten IPs. Das täte mir reichen.

Naja, dann also mal in den Quellcode rein geschaut. Die passende Stelle sollte sich finden lassen. Ist in Python geschrieben. Das ist jetzt nicht so meins, aber so eine kleine Änderung/Ergänzung bekomme ich allemal hin. Ich hab ja schon das ein oder andere kleinere Skript in Python geschrieben. Doch halt, Moment: Der Nagios Check ist in perl geschrieben. Das ist jetzt allerdings sehr meins. Kurz den Code angelesen und tada, fertig. Nun in einen Pull Request gepackt und fertig: https://github.com/fail2ban/fail2ban/pull/2732.

Meine Ausgabe sieht jetzt so aus:

CHECK FAIL2BAN ACTIVITY - CRITICAL - 6 detected jails with 195 current banned IP(s) | jails=6 currentBannedIp=195

Die alte Ausgabe möchtest Du zusätzlich haben? Das geht natürlich ebenfalls:

CHECK FAIL2BAN ACTIVITY - CRITICAL - 6 detected jails with 195 current banned IP(s) | jails=6 currentBannedIp=195 apache.currentBannedIP=0 dovecot.currentBannedIP=0 fail2ban.currentBannedIP=0 postfix.currentBannedIP=0 roundcube.currentBannedIP=0 sshd.currentBannedIP=195

Oder man lässt alles so wie es ist, das geht selbstverständlich weiterhin 😛

Hier der Link zu meiner Variante von check_fail2ban: https://github.com/SteScho/fail2ban/tree/master/files/nagios.

Monitoring nach Remote

Monitoring nach Remote

von | Jan. 12, 2020 | Monitoring, Werbung

Monitoring nach Remote

Monitoring kann spannende Dinge überwachen. Funktioniert richtig toll solange das Ziel direkt via Netzwerk vom Monitorring aus erreichbar ist. Ein SMTP Server lauscht üblicherweise auf Port 25 und dort geht - oh Wunder - doch tatsächlich ein SMTP-Server ran. Lässt sich super mit einem Check prüfen welcher SMTP spricht. Nur was ist wenn es keinen Netzwerkdienst zu der überwachenden Komponente gibt? Solche Dinge wie der Füllstand der Festplatte, die Auslastung der CPU? Ein Agent muss auf das Zielsystem. Bleibt die Frage nach dem welchem. Ein kurzer Überblick der Möglichkeiten.

 

Ich beziehe mich in den folgenden Beispielen auf Icinga und Linux Systeme welche überwacht werden sollen. Als Monitoring-Software darf aber alles laufen was Nagios kompatible Checks verwenden kann. Also egal ob Nagios, Shinken, check_mk und wie Sie alle heißen mögen.

Icinga Agent

Wer ohnehin Icinga2 nutzt kann auch gleich den Icinga2 Agent nutzen. Der ist klein, schlank und sicher. Dazu ist er sauber in Icinga integriert. Klar, ist ja schließlich Icinga selbst. Hauptnachteil für mich: Der bläht die Zonenconfig immer so ungemein auf. Für einzelne Rechner wo man überwachen will gleich den großen Aufwand mit Zonen- und Endpoint-Config wagen? Kann man machen. Für alle ohne Icinga: ganz klar, hier muss was anderes her. Oder wechselt zu Icinga. Kann ich wärmstens empfehlen 😉

NRPE

Lange Zeit erstes Mittel der Wahl: NRPE, der Nagios Remote Plugin Executor (https://github.com/NagiosEnterprises/nrpe). Seit 2017 keine Änderung mehr. Wozu auch? Solange es funktioniert ist ja alles gut. Ja, NRPE ist simpel und einfach. Und da liegt vermutlich das Problem. Verschlüsselung gibt es, jedoch keine Authentifizierung. Lediglich das frei schalten von IP-Adressen welche Anfragen stellen dürfen. Dazu noch die tolle Problematik rund um dont_blame_nrpe. Jeder der das Konstrukt kennt weiß was ich meine. Ansonsten einfach mal nach dem Schalter in der Dokumentation suchen. Viel Spaß beim lesen 😉

Zusammengefasst: Kann man machen. Im abgeschlossenen Netzwerk hinter einer Firewall sollte Verschlüsselung und IP Filter reichen. Das Ding ist klein und schlank, die Problematik rund um dont_blame_nrpe haben genau genommen alle Remote Agent Lösungen. Dumm nur, dass bei aktuellen Distributionen wie z.B. SLES 15.1 der Trend dazu geht NRPE nicht mehr mit auszuliefern. Zu lange keine Änderungen an den Paketen heißt es in der Begründung. Dem Trend werden vermutlich weitere Distributionen folgen bzw. sind schon gefolgt. Als NRPE Nutzer sollte man wohl zumindest offen für anderes sein - jenachdem was die Zukunft einem zu bieten hat.

 

 

check_by_ssh

Oder nur by_ssh wie es innerhalb von Icinga heißt. Jemand schon mal bei NRPE das Problem gehabt, dass der Ausgabe Text gekürzt wurde? Weil die maximale Größe für die Ausgaben seitens Quellcode auf 1024 Zeichen beschränkt wurde? Und wie gelöst? By_ssh? Willkommen im Verein 😉

Oder auch anders ausgedrückt: Welches Linux-System hat keinen ssh Server am laufen? Wenn es im Netz steht und man Monitoring darauf ansetzt dürfte es das so gut wie nie geben. Die Problematik der NRPE Installation ist weg, die Sicherheit ist hoch: Verschlüsselung und Authentifizierung ist bei ssh einfach super gelöst. Die dont_blame-Problematik ist hier sinngemäß die Gleiche: Wenn man erlaubt Argumente zu übergeben könnte jemand Blödsinn machen. Könnte. Heißt ja nicht gleich "muss". Oder einfach keine Argumente zu lassen. Problem der Eventualität gelöst. Wo nichts ist kann auch niemand. Klingt super, oder? Naja, ein Problem fällt mir spontan dazu schon ein. Spaßverderber, ich weiß: Ich brauche einen Benutzer der sich via ssh anmelden kann.

Ok, das ist ja jetzt nicht so das Thema. Das Thema ist eher: Checks sind meistens irgendwelche Skripte, der Benutzer fürs Monitoring braucht somit eine Login-Shell. Der Benutzer kann sich also am System anmelden und Dinge tun die er aus Sicht des Monitoring gar nicht braucht. Wenn jetzt irgendjemand das Monitroing-System knackt und dort die Zugangsdaten fürs ssh ausliest oder den hinterlegten key entsprechend weiter verwendet... Ihr seht schon auf was ich raus will. Der Benutzer braucht also so irgendwas wie chroot mit nur den Checks und Bibliotheken drin die er braucht. Und vermutlich noch das proc-System weil da heraus solche Dinge wie Festplattenbelegung usw. heraus gelesen werden. Und was sonst noch alles so fehlt. Puh, ganz schön aufwendig.

Geht auch etwas anders: Für jeden Check einen eigenen Benutzer anlegen und dem via sshd-Config als auszuführendes Programm den entsprechenden Check hinterlegen. Oder die Login-Shell bei dem Benutzer auf den Check ändern. Irgendwas, was keine Anmeldung mehr in Richtung Shell mit der Möglichkeit der eigenen Befehlseingabe erlaubt.

Machbar also. Mit Aufwand. Ein Hoch auf Orchestrierungstools wie ansible, puppet, chef oder wie die alle auch heißen mögen.

SNMP

Ganz anderer Ansatz: SNMP kennt man. Drucker, Netzwerkkomponenten, diverse Appliances. Die alle haben SNMP drauf und das funktioniert doch super. Ok, in Version 2 mit Community-String ist die Sicherheit so naja. Aber spätestens mit v3 wo Authentifizierung und Verschlüsselung gefordert werden kann ist doch alles wunderbar. Und wenn dann der Monitoringbenutzer im SNMP-Baum unter seiner Kennung nur das findet was er fürs Monitoring braucht ist doch alles perfekt. Bleibt die Frage was mit den eigentlichen Checks fürs Monitoring ist.

Also der Reihe mal nach durchgehen: SNMP ist unter Linux rasch installiert. Von Haus aus gibt es bei Icinga bereits die Checks welche via SNMP CPU, RAM, Prozesse, Plattenplatz usw. auswerten können. Grobe Sicht auf das was die Hardware betrifft: Läuft. Und die speziellen Checks welche man ggf. sogar noch selbst programmiert hat? Ja, die laufen auch. Einfach in die Config mit aufnehmen, im Internet nach check_by_snmp suchen und wie analog zu NRPE oder by_ssh verwenden. Läuft ebenfalls (Links finden sich weiter unten).

Ok, braucht man einen snmpd-Dienst. Einen extra Dienst brauchst bei NRPE aber ebenfalls. Die Checks muss man in der Config definieren. Musst bei NRPE ebenfalls und wenn by_ssh "richtig" machen willst ja auch. Von daher tut das eigentlich nicht weh. Ein weiterer Vorteil gefällig? Systeminventarisierung welche via SNMP Systeme ermittelt? Klar, das kannst jetzt ebenfalls machen. Ein spezielles Überwachungstool welches zusätzlich zum Monitoring läuft und ebenfalls SNMP kann? Na logisch doch, kein Problem. Und ich kenn sogar noch eine GroupWare Lösung welche via Webfrontend überwacht werden kann. Oder via AgentX Schnittstelle den lokal installierten SNMP erweitert. Somit ohne speziellen Checks am Monitoring dran. Das macht Laune, weil das funktioniert mit jeglichem Monitoring welches SNMP kann.

Fazit

SNMP ist viel spannender als man zunächst ggf. vermutet hätte. Jeder der das bisher noch nicht nutzt sollte es zumindest mal anschauen. Es lohnt sich!

Und Windows?

Hier gibt es ebenfalls SNMP. Was der so alles kann und ob bzw. wie man den erweitert weiß ich nicht wirklich. Gerne Kommentare dazu her!

Ich selbst nutze dafür bisher eigentlich immer diesen Weg: https://icinga.com/docs/icinga2/latest/doc/07-agent-based-monitoring/#nsclient-on-windows. Dank Icinga Agent ist die Übertragung gesichert und man kann über nscp ohne großen Aufwand alles mögliche Rund um Windows abfragen.

Testen

Ich nehme inzwischen ganz gerne um so etwas zu testen einen Docker Container. Hat den Vorteil, dass ich den Dienst in einem Container starten und falls ich den nicht mehr brauche einfach löschen kann. Ebenso unkompliziert ist es kurzerhand einen zweiten Dienst mit anderer Konifg parallel zu starten falls man was probieren möchte. Geht aber auch ohne Docker. Für alle mit Docker bzw. Docker interessierten füge ich hier mal meine docker-compose und dockerbuild Datei an:

Ginge auch ohne compose - zumal ich mit nur einem Container ausgekommen bin 😉

#
# Gehirn-Mag.Net snmpd
#

version: '3'

services:

   snmpd:
      build:
         context: .
         dockerfile: snmpd.Dockerfile
      ports:
         - "127.0.0.1:161:161/udp"
      volumes:
         - ./volumes/etc_snmp/:/etc/snmp/

 

Mein Docker-Container basiert auf Ubuntu 18.04. Sollte ein Proxy notwendig sein um das Internet zu erreichen einfach die beiden Proxy-Zeilen entsprechend anpassen.

FROM ubuntu:18.04

# Notwendige Software installieren
#ENV http_proxy=http://xxxx:xxxx@10.1.1.1:3128/
#ENV https_proxy=http://xxxx:xxxx@10.1.1.1:3128/
RUN apt-get update && apt-get install -y snmpd snmp-mibs-downloader snmp openssl monitoring-plugins git wget
RUN git clone https://github.com/dnsmichi/manubulon-snmp.git /usr/lib/nagios/plugins/manubulon
RUN wget "https://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3121&cf_id=29" -O /usr/lib/nagios/plugins/check_by_snmp && chmod -v 0755 /usr/lib/nagios/plugins/check_by_snmp
RUN ln -sv /usr/lib/nagios/plugins/manubulon/plugins/*.pl /usr/local/bin
RUN ln -sv /usr/lib/nagios/plugins/check_snmp /usr/local/bin
RUN ln -sv /usr/lib/nagios/plugins/check_by_snmp /usr/local/bin

# snmpd vorbereiten und starten
ENV MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
RUN /bin/mkdir -pv /var/run/agentx
CMD /usr/sbin/snmpd -Lo -u Debian-snmp -g Debian-snmp \\
    -I -smux,mteTrigger,mteTriggerConf -f

Im Container selbst sind dann die Manubulon Checks sowie check_snmp und check_by_snmp nach /usr/local/bin verlinkt. Zum testen also einfach direkt die Checks aufrufen.

Meine Beispiels snmpd.conf. Mit v2 Community "icinga" sowie einem v3 Benutzer "icinga" und Passwort "abcde%12345".

#
# Gehirn-Mag.Net Beispiel snmpd.conf fürs Monitoring
#

#######################################
#
# Allgemeine Einstellungen
#


# Auf *:161 lauschen
agentAddress udp:161

#######################################
#
# Auth: 1x SNMPv3, 2x community
#


# system, interfaces, host, ucdavis, nsExtendObjects
view icinga included .1.3.6.1.2.1.1
view icinga included .1.3.6.1.2.1.2
view icinga included .1.3.6.1.2.1.25
view icinga included .1.3.6.1.4.1.2021
view icinga included .1.3.6.1.4.1.8072.1.3.2


# Die folgende Zeile "createuser..." sollte besser in /var/lib/snmp/snmpd.conf stehen
# Und das Passwort sollte sinnigerweise angepasst werden ;-)
createUser icinga SHA "abcde%12345" AES
rouser icinga default -V icinga
rocommunity icinga default -V icinga


# public darf nur die sysDescr sehen ;-)
view public included .1.3.6.1.2.1.1.1.0
rocommunity public default -V public


#######################################
#
# Build in - ein paar Beispiele
#


# System Informationen
sysLocation GMN-RZ/WDD
sysContact Mein.Gehirn-Mag.Net <mein@gehirn-mag.net>
sysServices 72


# Process Monitoring
proc snmpd


# Disk Monitoring
disk / 20%
includeAllDisks 10%


# System Load
load 12 10 5

#######################################
#
# Erweiterungen
#


extend check_disk /usr/lib/nagios/plugins/check_disk -w 20% -c 10%
extend check_critical /usr/lib/nagios/plugins/check_procs -C gibtesnicht -c 1:

 

In der dritten Registerkarte direkt über diesem Abschnitt findet sich die von mir verwendete snmpd.conf. Diese kann auch ohne Docker als Ausgangsbasis für eigene Tests verwendet werden.

Zum testen ist noch ein v2 Zugang mit icinga als Community String enthalten, ebenso steht der v3 Zugang direkt in dieser Konfigdatei. Diese sollte aber, wie im Kommentar erwähnt entsprechend in die zweite snmpd Konfig verschoben werden. Die vollständige Doku zur Konfig gibt es hier: http://www.net-snmp.org/docs/man/snmpd.conf.html

"Allgemeine" Checks

Für Checks wie CPU, Plattenplatz usw. verwende ich gerne die SNMP-Checks von Manubulon. Diese sind z.B. in Icinga2 bereits enthalten. Ansonsten finden diese sich hier: http://nagios.manubulon.com/. Leider sind diese nicht mehr aktuell gepflegt, deswegen greife ich gerne auf diesen Fork von einem der Icigna Entwickler zurück: https://github.com/dnsmichi/manubulon-snmp. Diese sind ebenfalls im Container installiert und wären nach /usr/local/bin verlinkt.

Ein paar Beispiele dazu:

root@0b99c3febe7b:/# check_snmp_load.pl -H localhost -2c -C icinga -Tnetsl -w 1,1,1 -c 2,2,1.5
Load (CPUs: 4) : 0.56 1.00 1.34 : OK
root@0b99c3febe7b:/# check_snmp_mem.pl -H localhost -2c -C icinga -w 20,20 -c 30,30
Ram : 87%, Swap : 26% : > 30, 30 ; CRITICAL

Das funktioniert schon mal wunderbar 🙂

 

 

 

 

check_by_snmp

Um nun "eigene" Nagios-Checks einzufügen muss man lediglich in der Config einen Eintrag der Form "extend <check_name> <check_command mit args>" aufnehmen. In dem Beispiel von mir finden sich folgende zwei Zeilen:

extend   check_disk     /usr/lib/nagios/plugins/check_disk -w 20% -c 10%
extend   check_critical /usr/lib/nagios/plugins/check_procs -C gibtesnicht -c 1:

Vom Grundsatz her sieht das zu NRPE ja sehr ähnlich aus. Fehlt noch das passende Gegenstück zu check_nrpe bzw. check_by_ssh. Das gibt es hier: https://exchange.nagios.org/directory/Plugins/%2A-Remote-Check-Tunneling/check_by_snmp--2F-check_snmp_extend--2F-check_snmp_exec/details. In dem Beispiel-Container ist das, wie bereits erwähnt, ebenfalls nach /usr/local/bin verlinkt. Also einfach aufrufen. Und so sehen die beiden Beispiele aufgerufen aus:

root@0b99c3febe7b:/# check_by_snmp -H localhost -2 -C icinga -E check_disk
DISK WARNING - free space: / 30394 MB (20% inode=93%);| /=120929MB;127595;143544;0;159494
root@0b99c3febe7b:/# check_by_snmp -H localhost -2 -C icinga -E check_critical
PROCS CRITICAL: 0 processes with command name 'gibtesnicht' | procs=0;;1:;0;

Auch das funktioniert super! Mehrzeilige Ausgaben, der richtige Exit-Code: Kommt alles sauber mit rüber.

 

 

Sonstiges

Das war ja schon mal einiges was man damit tun kann. Es geht aber noch etwas mehr. Ich habe bei den Beispielen mit extend immer einen vollwertigen Nagios-Check aufgerufen. Das darf aber natürlich auch ein ein Skript sein welches zum Beispiel nur einen Integer Wert zurück liefert. Dieser kann dann mit check_snmp abgerufen und entsprechend weiter aufbereitet werden. Die Doku dazu gibt es hier: https://www.monitoring-plugins.org/doc/man/check_snmp.html. Der ist bei vielen Monitoringlösungen bereits mit dabei und ihr ahnt es ja bereits: Innerhalb von Icinga hießt der nur snmp.

Finale

Neben der Zugriffskontrolle die man wie so oft natürlich entsprechend umfangreich aufblähen kann ist der Rest der snmpd.conf jedoch eher kurz und übersichtlich gehalten. Also innerhalb kürzester Zeit machbar. Meiner Meinung nach lohnt es sich also SNMP als Alternative zu NRPE und check_by_ssh auf dem Schirm zu haben.

Icinga2 vs. PNP

Icinga2 vs. PNP

von | Dez. 12, 2019 | Monitoring, Werbung

Icinga2 ist eine praktische Sache, darüber braucht es vermeintlich keine Diskussionen. Eine einfache Lösung für die Darstellung von Performance-Daten ist PNP (ehemals PNP4Nagios). Nur ist diese Kombination bei Checks via nrpe oder by_ssh zunächst zickig.

Die dazugehörigen Links:

Wo das Problem dabei liegt? Jeder der diese Kombination am laufen hat wird die Erkenntnis getroffen haben, dass das Template welches PNP verwendet logischerwiese nrpe oder by_ssh lautet. Genau genommen logisch da der ausgeführte Check halt nun mal nrpe oder by_ssh heißt. Ok, dass die beiden so zunächst nur Mittelsmänner für den eigentlichen Check sind ist der Kombi Icinga2 und PNP an der Stelle schlichtweg egal...

Auf zur Lösung

Was kann man also tun? Man kann sich seine eigenen CheckCommands definieren die dann den passenden Namen haben und für diesen ein PNP Template hinterlegen. Das ist aber umständlich und macht zumindest mir wenig Spaß. Und das geht auch besser: Die PNP Templates werden in php geschrieben. Eine Programmiersprache... Also kann da auch Programmiercode mit rein welcher Entscheidungen trifft und nicht nur Layout entwirft...

Also fix ans Werk gemacht: PNP sieht als Check ja nur nrpe bzw. by_ssh. Woran erkenne ich was das für ein Check eigentlich war? Richtig, ein Blick in die zugehörige xml-Datei hilft. Da steht zum Beispiel die Datasource als auch der Name der rrd-Datei drin. Und letztere trägt den Namen des eigentlichen Checks. Bingo, Treffer: Schiff versenkt.

Uns so wird es gelöst: Ein Template namens by_ssh.php oder npre.php mit folgender Logik erstellt:

  • Ermitteln des Check-Namens anhand der verknüpften rrd-Datei
  • Suchen eines Templates mit Namen des Checks an den noch ein .php angefügt wurde
    • Gefunden? Dann dieses Template per php include einfügen und fertig
    • Nicht vorhanden? Dann einfach das Default Template einfügen

Fertig und funktioniert. Den Quellcode gibt es hier: https://gitlab.com/Gehirn-Mag.net/pnp-by_ssh-or-nrpe-template. Oder hier:

<?php

#
# A clever template for PNP which selects the correct template for by_ssh or 
# nrpe. Just rename or link the file to nrpe.php if needed ;-)
#

#
# MIT License
#
# Copyright (c) 2019 Steffen Schoch <mein@gehirn-mag.net>
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#


// Adjust these both to your needs
$templatePath = '/etc/pnp4nagios/templates';
$templateDefault = '/usr/share/pnp4nagios/html/templates.dist/default.php'; 

// Check if template for the used rrd file exists
if(preg_match('/([^\\/]+)\\.rrd$/', $RRDFILE[1], $matches)) {
    // Some debug information if needed
    //throw new Kohana_exception(print_r($matches,TRUE));
    $templateFile = $templatePath . '/' . $matches[1] . '.php';
    if(is_file($templateFile)) {
        // template found, so use it
        include($templateFile);
    } else {
        // nothing found, use default template
        include($templateDefault);
    }
}

Einfach im PNP Template Ordner als by_ssh.php oder nrpe.php ablegen. Da eh gleicher Inhalt: Das kann verlinkt werden. Funktioniert logischerweise auch für alle anderen Templates mit gleichem Problem.

Mehr zum Thema Monitoring gefällig? Gibt es zum Beispiel hier: https://gehirn-mag.net/category/monitoring/.

check_ntp_time Offset unknown

check_ntp_time Offset unknown

von | Sep. 13, 2019 | Monitoring, Seltene Wunder

Irgendwie kommen Freitags regelmäßig die Kuriositäten des Monitorings bei mir auf den Tisch. Heute zum Thema NTP: Der check_ntp_time aus den nagios-plugins wirft einen Offset unknown Fehler. Obwohl die Uhrzeit richtig wäre. Also mal nachgeschaut was da los ist. (mehr …)

Diese Abmahnung wurde maschinell erstellt und benötigt keine Unterschrift

Diese Abmahnung wurde maschinell erstellt und benötigt keine Unterschrift

von | Juni 17, 2019 | Monitoring, Werbung

Bei mir kommen regelmäßig Azubis, Praktikanten oder Studenten vorbei. Das ist absolut ok so - man lernt nun mal am Besten die anderen Abteilungen bzw. Unternehmen der Gruppe kennen indem man dort mal ein paar Tage rein schnuppert. Wenn es die Zeit zulässt erzähle ich ganz gerne neben dem was wir so machen noch ein paar Dinge über den üblichen Tellerrand darüber hinaus. Gern genommene Themen sind "Email" (wir haben mehrere TB bei uns auf den Platten liegen), "Webhosting aus Adminsicht mit Hinblick auf Google Pagespeed", "Der Einfluss von langsamen DNS auf ein Firmennetzwerk", "Ethik und Moral zum Thema Monitoring"... Jetzt kommt meistens "langweilig" oder "ne, Ethik ist nicht so meins". Na wunderbar! Das Thema ist gefunden, der Einstieg bereits gemacht 😉

Zuerst einmal gehen wir dann immer der Frage nach was Monitoring überhaupt ist. Grob zusammengefasst findet man dieses hier als Einleitung auf Wikipedia (Logo und Text von hier https://de.wikipedia.org/wiki/Monitoring):

Monitoring ist die Überwachung von Vorgängen. Es ist ein Überbegriff für alle Arten von systematischen Erfassungen (Protokollierungen), Messungen oder Beobachtungen eines Vorgangs oder Prozesses mittels technischer Hilfsmittel oder anderer Beobachtungssysteme.
Ok, erfassen, messen und beobachten. Über das "wie" wollen wir uns jetzt mal etwas weniger Gedanken machen, viel interessanter ist die Frage nach dem "was".

Monitoring Allgemein

Gehen wir also zunächst mal der Frage nach was man überhaupt so alles mit einem Monitoring-System überwachen kann. Ich frage dann mal nach bzw. lenke die Diskussion in folgende Richtungen:

Dienste

Netzwerk um die Welt.

Vernetzte Dienste

Eine der häufigsten Antworten sind "Dienste" oder die "Verfügbarkeit von Diensten". Das kann sowas einfaches sein wie ein Ping auf Server, Router oder sonstige Geräte. Oder mit etwas mehr Anspruch weil via Protokoll verbunden wird um z.B. nachzusehen ob ein Mailserver artig Hallo sagt, ob ein Webserver eine Webseite ausliefert usw. Das ist ok und richtig so. Nur allzu oft wird hierbei etwas ganz wichtiges übersehen. Kurzer Exkurs: Häufig wird der Dienst alle 5 Minuten geprüft. Im Falle eines Fehlers wird der Abstand verkürzt, oftmals auf zwei Minuten. Bei 3 hintereinander aufgetretenen Fehlern wird alarmiert. Dann mal fix zusammen gerechnet was hier als worst case raus kommt: 9 Minuten. Also nach 9 Minuten wird jemand kontaktiert. Wieder eine offene Frage: Wie wird kontaktiert? Per Email, per SMS? Per Messanger (wie auch immer die heißen mögen)? Wie lange dauert es im Schnitt bis jemand auf die Nachricht reagiert und tatsächlich was tun kann? Und jetzt die einzig spannende Frage zu diesem Bild: Meint Ihr wirklich, dass bei einem produktionskritischen System wo Kunden drauf sind es um die 10 Minuten dauert bis die anrufen um sich zu beschweren, dass Sie nichts mehr arbeiten können? Exkurs Ende. Dienste überwachen ist wichtig. Nur braucht das allzu oft anzutreffende Zeitmodel wie gerade gezeigt eine dringende Überarbeitung. Es ist auf Dauer sehr ungünstig wenn die Kunden das bessere Monitoringsystem sind 😉

Hardware und Co.

Das mit den Diensten muss besser werden. Eine Möglichkeit das zu optimieren ist der Blick auf die Hardware. Was macht die CPU Auslastung? Wie voll ist die Festplatte? Wie steht es um den Arbeitsspeicher? Das sind sinnvolle Ergänzungen die einem helfen ein besseres Verständnis für die Last auf einem System zu bekommen. Und oftmals erhält man hier rechtzeitig Hinweise und kann agieren bevor was ausfällt. Ein Beispiel der von mir gerne verwendeten Hardware-Checks gibt es hier: Monitoring Linux Extended Memory.

Dienste 2.0

Schon wieder Dienste. Die hatten wir doch schon. Ja, zumindest einen Teil. Ich selbst bin riesengroßer Fan davon auch die andere Seite von den Diensten zu betrachten. Beispiel Webserver Apache: Das der Dienst verfügbar ist kann man mittels http bzw. https Anfrage an den Webserver prüfen. Kommt die erhoffte Webseite zurück ist alles gut. Nur was macht der Webserver eigentlich alles? Apache kennt einen Server Status der genau dies verrät. Ein Beispiel wie so etwas aussehen kann? Gibt es hier: https://exchange.icinga.com/dsbits/apache_serverstatus. Oder Du schaust in die angefügte Galerie: Dort sind ebenfalls ein paar Beispiele enthalten. Das habe ich unterm Strich für alles wo etwas mehr Last anliegt bzw. sehr, sehr produktionskritisch ist. Da sind neben dem Beispiel mit apache noch solche Dinge wie ISC DNS, Novell/NetIQ eDirectory, OpenLDAP, NFS-Server, GroupWise, Kopano usw. dabei. Selbst moderne Dateisysteme wie btrfs verraten einem beim genaueren Blick deutlich mehr Details zu ihren internen Vorgängen und Engpässen. Von Routern und Switchen gibt es über die VLANs kaskadierte Sichten zu den Netzwerkports. Netzwerk dicht? Ein Blick aufs Diagramm im Monitoring und sofort ist klar welche VLANs der Auslöser sind. Soviel dazu. Detailschärfe kann im Falles eines Falles das Leben so viel leichter machen. Kombiniert mit sinnvollen Limits und man wird rechtzeitig informiert bevor irgendetwas steht. Angenehmer Seiteneffekt dabei und nochmals am Beispiel apache: Der Server-Status wird ebenfalls via http/https aufgerufen. Also wenn das funktioniert, dann muss der Webserver als solches laufen. Der vorhin angesprochene Check auf http/https kann also weggelassen werden.

Fazit von Dienste 2.0: Mit geschickt gewählten Checks bleibt die Anzahl der Checks unverändert. Der Mehrwert an gewonnenen Informationen: Unbezahlbar 😉

Dienste 2.1

Was, schon wieder Dienste? Ja, bzw. ja... Zum Teil kann es lohnend sein Funktionsgruppen zu testen. Ich nenne das jetzt einfach mal so, folgende zwei Beispiele sollen erklären was ich meine: Eine der Basis-Datenbanken für eine große Softwarelösung sei die CRM-Datenbank mit den Adressdaten aller Kunden. Die ist so groß, dass die auf eigenem Blech läuft und sonst nichts macht außer CRM-DB. Über Webservices ist es möglich, dass externe Dritte Änderungen an den CRM-DB Einträgen vornehmen. Wenn es also funktioniert, dass über Webservices ein neuer Dummy-Kunde angelegt werden kann, dann muss auf dem Weg dazwischen alles funktionieren: Firewall, WAF, Webservices, die dortigen Applikationen und zu guter Letzt die CRM-DB selbst. Ein einziger Check, aber unterm Strich eine riesen große Fülle von Dingen die hierbei, wenn auch zum Teil indirekt, geprüft wurden. Geschickte Peformance-Daten hierbei erfasst und schon hat man eine Grundlage für die monatlichen SLA-Berichte an die Kunden. Monitoring kann Spaß machen. Beispiel 2: Eine Email von einem Server aus dem Internet an einen der via DNS gelisteten MX-Server übergeben und kurze Zeit später via IMAP bzw. GroupWare-Konnektor geprüft ob die Mail da ist. Bzw. Eicar-Testvirus (https://de.wikipedia.org/wiki/EICAR-Testdatei) oder GTUBE Spam-Email (https://de.wikipedia.org/wiki/GTUBE) verschickt - die sollten logischerweise nicht da sein oder in der Quarantäne wieder zu finden. So die Art. Weitere Details: Kopfkino. Mach was draus 😉

Es mag genug Szenarien geben wo so etwas sinnvoll ist. Vor allem wenn man es schafft aus den erfassten Daten noch zusätzliche Informationen wie zum Beispiel das angesprochene SLA-Reporting zu gewinnen.
PNP bind via rndc

Bind9 DNS

Ein Nameserver mit ein bisschen Grundlast 😉

Novell/NetIQ eDirectory

Anfragetypen

Novell/NetIQ eDirectory

Übersicht Authentifizierungsanfragen

Novell/NetIQ eDirectory

Interne LDAP Operationen

apache2

Übersicht über die Apache Prozesse

apache2

Übersicht über die apache Prozesse – mit zusätzlichen Anfrageraten

Luxus

Neben dem bisher gezeigten kann ich noch mit folgenden Beispielen dienen die zum Teil für große Augen sorgen. Einfach mal ein Auflistung einiger Punkte was man so alles machen kann:

  • Für ein Email-Relay welches ausschließlich Emails im Namen von Kunden mit deren Domains versendet: Ein Check welcher prüft, dass die zugehörigen SPF-Records, sofern gesetzt, auch dieses Relay beinhaltet. Natürlich werden die Domains dynamisch ermittelt um bei Änderungen am Adresspool keine Änderung im Monitoring-System zu brauchen.
  • Gute Netzwerkdrucker haben die Möglichkeit via SNMP Daten bereits zu stellen. Toner bald leer, Papier aufgebraucht? Im ersten Fall eine Mail an die Materialwirtschaft damit rechtzeitig Nachschub bereit liegt, im zweiten Fall eine Mail an die Azubis den Papiervorrat wieder aufzufüllen. Und bei geleasten Geräten nebenbei die monatlichen Zählerstände an den Dienstleister versendet.
  • Via Montioring-API alle https-Webserver ermitteln und den SSL/TLS-Stack zu prüfen. Zum Beispiel hiermit: https://testssl.sh/. Mit geeigneter Monitoringsoftware kann der Link zum Bericht gleich noch bei den Check-Details mit eingefügt werden. Testssl kann dies darüber hinaus auch für SMTP-Server.
  • Für Webseitenentwickler ist der Pagespeed sehr wichtig. Warum externe Tools verwenden wenn man doch selbst die Time To First Byte (TTFB) überwachen kann?
  • Wir haben genügend Monitoring Checks die überprüfen wie die Hitrate eines Caches ist. Aber mal ehrlich, wer schaut da rein? Die zugehörigen Admins. Warum hier nicht gleichzeitig neben der Hitrate eine Empfehlung berechnen lassen auf welchen Wert man die dazugehörigen Einstellungen setzen müsste? Geheimnis ist das keins, die zugehörigen Formeln stehen oftmals im Handbuch des Servers. Macht das Admin Leben leichter da man nicht jedes mal selbst nach diesen Formeln die passenden Werte berechnen muss. Und dank Laufzeitdiagrammen hat man sogar noch eine Trendübersicht.

Und das waren nur ein paar Beispiele. Alles nur theoretischer Natur? Hab ich so bereits alles in der Praxis zum laufen gebracht - mehrfach zum Teil sogar. Da geht aber noch viel, viel mehr. Und bis jetzt ist das doch alles ok und alles andere als verwerflich. Was soll daran so böse sein wo man sich um Ethik und Moral Gedanken machen müsste? Nun ja, eins hat dies bisher gezeigt: Überwacht werden kann eigentlich so ziemlich alles. Und man kann richtig viel Information daraus gewinnen. Im nächsten Abschnitt gebe ich ein paar Bespiele was man sonst noch so machen könnte - wenn man wirklich wollte.

Spezialtät des Hauses

Die Spezialität nach Art des Hauses

Da geht doch was 😉

Ticket

Ticketing

Auf dem Weg ins Glück

Überwachung

Matrix

Code-Review der anderen Art

Very special Monitoring

Fangen wir mal hiermit an: In vielen mittleren und größeren Unternehmen gibt es Webproxys welche für das Surfen im Internet verwendet werden. Ohne Frage, dass Proxys eine Daseinsberechtigung haben und viele Vorteile mitbringen. Wenn dann auch noch solche Mechanismen wie Single-Sign-On (SSO) dazu kommen wird das richtig super in der Handhabe. Und im Hintergrund noch das Surfverhalten jedes einzelnen Mitarbeiters mit den gängigen Blacklists oder der firmeninternen Whitelist abgeglichen und schon hat man den "surft geschäftlich Quotient" ermittelt. Der ist über Tage hinweg zu tief? Automatische Meldung an den Abteilungsleiter und/oder ins Personalbüro.

Na und bei Email geht das sogar noch einfacher und braucht so zusätzliches Zeug wie SSO doch gar nicht. Die Absender- bzw. die Empfängeradresse ist doch eindeutig. Dazu noch rasch das Unternehmensadressbuch via passender API vom Groupware System abgerufen und abgeglichen. Und Tada: Brauchbare Zahlen über die sich jeder cholerische Personalchef freut!

Bei Dir gibt es eine elektronische Schließanlage? Na wunderbar, schon wieder genug Zahlenfutter welches mit den vereinbarten Arbeitszeiten abgeglichen werden kann.

Das folgende hatten wir mal als Aprilscherz in einer größeren Monitoringumgebung geplant. Auf jedem Arbeitsplatz lief hier Windows. Also via WMI oder Powershell-Remote von jedem Rechner ausgelesen wer angemeldet ist und ob der Bildschirmschoner läuft. Im Monitoring kann dadurch rasch geprüft werden ob es sich lohnt zu einem Kollegen los zu laufen oder ob man doch lieber noch etwas wartet. So in Analogie zur Trojan-Room-Kaffemaschine 😉 Details zu dieser gibt es zum Beispiel hier: https://de.wikipedia.org/wiki/Trojan-Room-Kaffeemaschine.

Das war noch nicht bedenklich genug? Bitte, da geht noch mehr! Aus den Informatonen lässt sich wunderbar eine effektive Arbeitszeit ermitteln. Ja, aber der Kollege könnte doch mal im Meeting sein oder am geschäftlich telefonieren... Und Du denkst das ist ein Problem? Fix im Groupware Terminkalender nachgeschaut ob ein Termin drin steht oder ob laut Telefonanlage der Anschluss gerade besetzt ist.

Apropos Telefonanlage: Du weißt ja, Anlagen zeichnen geführte Gespräche in der Anrufliste auf. Das Unternehmensweite Adressbuch hatten wir ja schon mal im Zusammenhang mit Email. Also fix die Telefonate gegen die Nummern aus dem Adressbuch abgeglichen und schwupp, schon wieder beim privat telefonieren erwischt.

Wer ein Ticketsystem verwendet kann hier zum Beispiel die Anzahl der gelösten Tickets pro Kopf ermitteln. Ok, jeder der darin arbeitet weiß, dass es Tickets gibt die rasch erledigt sind während andere schon mal etwas Hirnschmalz erfordern um gelöst zu werden. Moderne Ticketsysteme kennen aber die Quote der wieder geöffneten Tickets. Ebenso lässt die Anzahl der ausgetauschten Nachrichten je Ticket auf dessen Komplexität schließen. Also wieder eine messbare Eigenschaft über mehrere verknüpfte Werte. Fehlt noch der Bezugswert mit dem dieser Quotient verglichen wird. Da bietet sich zum Beispiel der Abteilungsschnitt an. Das hier keiner behaupten kann die Tickets der Vertriebsabteilung hätten eine andere Komplexität als die der IT-Abteilung. Und genau das ist doch der Punkt und die Lösung steckt bereits in der Behauptung drin: Dann vergleiche doch auf Abteilungsbasis. Oder was auch immer der gemeinsame Nenner bei Dir im Unternehmen ist. Ein paar Male in Folge im Monat als schlechtester Mitarbeiter gekürt oder im Jahresschnitt zu weit hinter den Kollegen zurück? Schon kommt der große Holzhammer vorbei...

Ja und für die Programmierer die sich gerade noch entspannt zurück lehnen: Meint Ihr nicht auch, dass dank Revisionskontrollsystemen sehr elegant ermitteln werden kann wie viel zum Gesamtquellcode von jedem Einzelnen beigetragen wurde? Jaha, aber das ist doch noch keine Aussage über die Qualität des Codes. Manche Zeilen sind viel härter erarbeitet als andere die locker von der Hand gehen. Das mag ja alles sein, aber schon mal was von Quellcode-Bewertungen gehört? So wie z.B. COCOMO? Siehe für allgemeines hier: https://de.wikipedia.org/wiki/COCOMO. Oder gleich noch ein passendes Tool gefällig? Das gibt es hier: https://github.com/boyter/scc. Die Best-Of Liste von unten her gelesen wird dann jeden Monat in der Toilette aufgehängt. Oder wie sagte mein alter Mathelehrer an der Oberstufe immer? "Einmal an der Tafel blamiert fördert die Arbeitsmoral!"

Fazit

"Diese Abmahnung wurde maschinell erzeugt und benötigt keine Unterschrift."  Dabei ging dieser Text doch nur der Frage nach was man denn so alles überwachen kann. Mit ein paar technischen Hinweisen wie man das umsetzen könnte. Hier wird global auf individueller Ebene entschieden ohne Rücksicht darauf ob die erfassten Daten für die gerade im speziellen betrachtete Situation überhaupt vollständig sind. Um im Bild der Zeit zu bleiben wird das Ergebnis per sozialem Netzwerk an der jeweiligen Pinnwand aufgehängt. Unbequeme persönliche Kommunikation mit Konfliktpotential? Wo denkst Du hin? Der Flame War der einem entgeht wäre zu schön gewesen. Als IT-Administrator und vor allem auch als IT-Verantwortlicher sollte man sich die richtigen Fragen stellen. Sei Dir bewusst was Du tust und kenne die Konsequenzen. Bekenne Dich zu dem was wirklich richtig ist. Sei mutig. Sage "nein" wenn es sein muss. Auch oder gerade deswegen im IT-Umfeld. Ethik und Moral.

Monitoring Linux Extended Memory

Monitoring Linux Extended Memory

von | Feb. 15, 2019 | Linux, Monitoring, Werbung

Das Monitoring des Arbeitsspeichers eines Linux-Systems ist mühselig: Der physikalische RAM ist immer voll, die Auslagerungsdatei alleine betrachte keine wirklich genaue Aussage.

Also mal wieder Monitoring. Du merkst schon, dass ist ein Thema das mich immer wieder beschäftigt. Ein Dauerbrenner. Und immer wieder erstaunlich: Es gibt schon so viele Checks. Einige sind richtig gut. Und dennoch können einige davon noch weiter verbessert werden. Vieles fehlt dennoch. Oder die Dinge wurden nicht tief genug ausgewertet. Genauso erging es mir bei der vordergründig simplen Frage: "Wie viel des Arbeitsspeichers eines Linux-Servers ist denn tatsächlich noch frei?"

Prolog

Es ist nun mal so, dass auf einem Linux Server sobald dieser etwas zu tun hat der physikalische Arbeitsspeicher fast immer voll ist. Buffers und Festplattencache füllen, sinnvollerweise, den eigentlichen freien Speicher fast komplett aus. Eine Betrachtung der noch freien Bytes? Bringt nichts da keine sinnvolle Aussage möglich. Freie Bytes zuzüglich Buffers und Cache als Summe betrachtet? Schon besser. Aber nicht wirklich gut. Den diese Summe könnte immer noch kleiner als der belegte Bereich im Swap sein.

Eine gern genommene Notlösung da der RAM eh immer voll ist: Die reine Betrachtung des Swaps. Wenn dieser sich füllt hat der Server zu wenig RAM. Das mag für viele Systeme soweit ganz gut passen. Aber genau ist was anderes und was ist mit denen wo das so nicht stimmt? Ein Server bei dem zwar der Swap sehr voll ist, die Summe von Buffers, Festplattencache und physikalisch frei aber um etliches größer? Das kommt öfters vor als man zunächst denken mag. Stichwort "swappiness" falls Du danach suchen magst 😉

Dieser Check hat schon ein paar Jahre hinter sich, funktioniert aber immer noch sehr gut. Und da mir vor kurzem eine Frage in genau diese Richtung gestellt wurde habe ich den alten Quellcode genommen, etwas aufgehübscht, MIT-Lizenz rein und frei zur Verfügung gestellt. Und so sieht das Ergebnis in Icinga aus - inkl. dem passenden pnp4nagios Template:

extmem in icingaweb2

extmem in icingaweb2

extmem performance data

extmem performance data

Ok, das rechte Bild mit den Performance-Daten mag nicht ganz perfekt sein: Der obere Bereich des Swaps ist fast leer. Aber als Beispiel reicht es trotzdem: Unten ist der physikalische Teil aufgelistet, darüber der Swap-Bereich. Die Limit-Angabe für Warning und Critical ist möglich und betrachtet das prozentuale Verhältnis zwischen "belegt" sowie "frei" zuzüglich Buffers und Cache.

Auch dieser Check ist sicherlich alles andere als perfekt. Aber er ist deutlich näher dran als die einzelne Betrachtung von RAM und Swap. Vor allem die Darstellung der Performance-Daten in denen die Gesamtsumme des Speichers dargestellt wird lässt über längere Zeiträume betrachtet eindeutige Tendenzen erkennen. Bei den meisten von mir verwalteten Linux-Servern ist inzwischen dieser Check installiert und wird immer wieder gerne hergenommen sobald eine entsprechende Auswertung der Serverlast benötigt wird.

Hier findest Du check_extmem auf GitLab: https://gitlab.com/Gehirn-Mag.net/icinga-and-nagios-plugins/tree/master/linux/check_extmem