Learn more and get inspired: OSMC Workshops!

OSMC, November 5: One day, four experts, four chances to gain knowlegde and come closer to being an expert yourself. The Workshops at OSMC are perfect opportunities for learning, gaining new friendships and bringing helpful and valuable information back to your business. Choose the one that suits your monitoring requirements best:

Prometheus

Prometheus brings monitoring to another level, when everything is about metrics and graphes. It puts the data first, and takes advantage of multiple service discovery systems. This workshop will dive into its ecosystem and teach you how to get the best out of it. Be ready to discover a new and very effective approach to monitoring.

Ansible

This workshop leads you to your very first automated deployment. Starting with the basic concept how Ansible works and how it will support you at your daily tasks. In this session we will guide you step by step to your first playbook and application deployment.

Icinga 2 / Puppet

This workshop is an advanced workshop to show how a distributed Icinga 2 environment is managed by Puppet. We will build a distributed Icinga 2 setup with puppet-icinga2 module using the role/profile concept. Additionally we will spend some time to discuss zones and endpoints in Icinga 2 and also some advanced puppet features used by previous mentioned puppet module.

Graylog

This workshop is a beginners guide to central log management. After talking about fundamental elements of central log management with Graylog we will start to setup a Graylog system from scratch to ingest, and filter and visual individual data.

All courses will take place on November 5th, from 10 am to 5 pm, at the conference venue. To promote a comprehensive training success, the number of participants is limited. Workshops are held in German, Prometheus in English. Attendance requires the purchase of an OSMC & Workshop ticket.

More on osmc.de/workshops/

 

OSMC | November 5 – 8, 2018 | Nuremberg

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Monitoring: alles ist geregelt. Aber!

Es könnte so einfach sein. Auf der einen Seite eine Reihe von Import- und Sync-Definitionen welche aus den unterschiedlichsten Quellen unsere zu überwachenden CI’s importieren. Excel, CMDB, Datenbanken, AWS, JSON, YAML, LDAP, VMware, Active Directory – alles geht. Quellen werden kombiniert, Daten angereichert und wo nötig geradegebogen. Egal wie mies die Daten sind, der Director wird’s schon richten.

Auf der anderen Seite stehen mächtige Apply-Regeln. Diese weisen regelbasiert aus einem liebevoll vorbereiteten Service-Katalog das zu was passt. Ausnahmen von der Regel sind knifflig, nämlich dann wenn wöchentlich jemand wieder einen Schwellwert anders haben möchte. Genau dort wo wir’s nicht bedacht haben, dort wo Konstrukte mit vars am Host schnell hässlich werden.

Auch hier hilft der Director, mit den “Custom Variable Overrides” fühlt es sich so an als würde man wirklich diesem einen Service auf dem einen Host einen anderen Schwellwert verpassen. Alles gut soweit. Die Regeln sitzen, für Schwellwerte sind die Overrides da.

Nun ist unsere Welt aber leider nicht perfekt. Und das ist auch gut so, sonst wäre sie furchtbar langweilig. Für unsere Regeln bedeutet das leider, dass sie im Laufe der Zeit immer umfangreicher und komplizierter werden. Bis wir erneut an dem Punkt angelangen, an dem wir wieder am liebsten alles selbst machen würden. Wir haben nämlich Angst, dass es kaputt wird wenn es ein Kollege anpackt.

Klar, der Director hat ein wunderbares Aktivitätslog, man kann hinterher mit dem Finger auf eben diesen Kollegen zeigen und es heroisch selbst wieder geradebiegen. Ein Klick auf “Restore” hilft dabei. Aber wenn man sich dann allein dadurch besser fühlt, dann hat man charakterlich durchaus noch Möglichkeiten an sich selbst zu arbeiten.

Zudem gab es vorher unnötigen Stress. Über zwei Wochen ist niemandem aufgefallen, dass die Checks für einen wichtigen Job auf ein paar Servern verschwunden sind. Am Wochenende ist das Ding an die Wand gerannt, das Monitoring blieb stumm. Bemerkt hat’s der Kunde, und wir mussten uns mal wieder so doofe Sprüche wie “Ja habt ihr denn kein Monitoring?” anhören. Und alles nur, weil jemand mal wieder eine simple doppelte Verneinung falsch verstanden hat.

Mit dem Director v1.5.0 sind die häufigsten Ausnahmen von der Regel jetzt ein Kinderspiel. Man muss die Apply-Regel gar nicht mehr anfassen, einfach auf besagtem Host die Services anzeigen lassen, einen wählen, Blacklist, fertig:

Im Hintergrund rendert der Director passende Ignore-Regeln und alles ist gut. Man kann wieder einen Task mehr an seine Kollegen delegieren und sich um Wichtigere Dinge kümmern. Also den Raspberry der den Wasserstand der Kaffeemaschine im Auge behält. Was in der v1.5.0 sonst noch alles neu ist steht im Release-Blogpost des Icinga-Blogs.

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

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

Autor: Stefan Gundel

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.

Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging

 

„Das @netways Blog kann man auch generell einfach mal empfehlen: https://blog.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.

Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!

Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!

CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!

Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.

Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.

Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.

Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.

Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

NETWAYS Webinare – Aus der Asche

Wer am letzten Webinar zur Icinga 2 Anbindung von Graphite und Grafana teilgenommen hat, wurde Live Zeuge wie sich ein System verhält wenn es faktisch zu heiß ist und einfach seinen Dienst quittiert. Zugegeben, so etwas passiert in der Regel relativ selten. Während eines Webinars ist der Zeitpunkt aber relativ ungünstig.

Wie angekündigt werden wir das Webinar nachholen und zwar am 23. August 2018 um 10:30 Uhr. Die kostenfreie Anmeldung ist direkt hier möglich.

Damit natürlich nicht das selbe Szenario wie beim letzten mal Auftritt, haben wir unser Equipment ein klein wenig aktualisiert.

Somit ist zumindest das Hitze- und Performance Problem kein Hindernis mehr und können entspannt in die Zukunft blicken und die nächsten geplanten Webinare mit Bravur meistern:

Ich freue mich wie immer auf 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".