Monthly Snap March > NETWAYS Web Services, Jitsi, ReactOS, Ceph, Braintower, OSDC, Graylog, Elastic{ON], Timelion, Icinga Director, Puppet

Tim began with a simple video chat jitsi-meets  and Alexander continued with his experiences with ReactOS.

Then Deniz wrote about Crush Maps in Ceph while Isabel presented the latest Shop Highlights such as AKCP sensorProbe 2, the Braintower software version 3.5.0 and some new STARFACE Services.

Then Martin announced our new platform NETWAYS Web Services and Gabriel analysed the differences between OwnCloud and Nextcloud.

Jean gave us an insight in the Icinga Buildserver, Version 3, while Julia started the countdown for the OSDC 2017 and presented the fixed program. Thomas Widhalm and Nicole reviewed the Elastic{ON] in San Francisco.

Blerim then described the Kibana add-on Timelion and Markus Waldmüller showed benefits given by the Icinga Director.

On events, Julia presented the programme and sponsors for the OSDC in May and announced our new training sessions for GRAYLOG.

Later in April, Ronny looked at multi-zone notifications in Icinga 2 while Gunnar presented ControlPlane.

Furthermore, Michael managed Elasticsearch, Kibana & icingabeat with Puppet and Lennart began with the first part of automated Monitoring with Puppet.

Last, but not least, Vanessa told about the Akademika 2017, where we’re serching for nice colleagues.

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

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 😉

On Tour with Icinga 2: San Francisco

The best thing about travelling? Definitely meeting people! My four colleagues and I had the chance to be guests at Pivotal and Slack in San Francisco.

Our group used the trip to Elastic{ON}17 in San Francisco as an opportunity to meet with other people who are active in the Icinga universe. Our first stop was at Pivotal who were kind enough to host our Icinga Camp at their office.

After a warm welcome at Pivotal, our keynote speaker Blerim Sheqa started our Icinga Camp by welcoming our guests. His talk provided insights into the current state and development of Icinga 2. Subsequently we heard about Icinga Director, in detail the current features and how it works from Markus Frosch. Our third talk about Elastic Stack and how to integrate it with Icinga 2 by Thomas Widhalm rounded off the camp.

Again, this Icinga Camp was a perfect way for customers and users to get to know the team members from NETWAYS. Our speakers were happy to answer many interesting and sophisticated questions as well as to take in ideas and requests from the audience. In the end, everybody attending the camp profited a lot from these discussions.

Out next stop was at Slack Headquarters where we were invited for a rather casual get-together. The people at Slack were mainly interested in Icinga 2, Icinga Web 2 and all the features available now and in the future. Furthermore it was extremely interesting to get an insight into American company culture and to compare it to Germany. All in all, we had a very good time at Slack HQ, met nice people and everybody was able to gather useful information and facts.

Again a big thank you to our hosts, it was a pleasure to be your guests!

If you are interested and want to learn more about Pivotal or Slack, you can visit them online or follow them on Twitter:

Pivotal @pivotal

Slack @SlackHQ

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

Timelion, eine Kibana Erweiterung

timelion logoIch habe mich in der Vergangenheit mit verschiedenen Tools beschäftigt die Performancedaten bzw. Metriken speichern und darstellen können. Aktuell beschäftige ich mich näher mit Timelion aus dem Hause Elastic und das hat zwei Gründe: Zum einen wurde mir die Kibana Erweiterung auf der ElasticON letzte Woche wieder schmackhaft gemacht, nachdem ich es eigentlich schon zur Seite gelegt hatte. Zum anderen erweist sich Timelion als sehr nützlich in Verbindung mit meinem Icingabeat. Ein Beat der Daten aus Icinga 2 zur weiteren Verarbeitung entweder an Logstash oder direkt an Elasticsearch schicken kann.

Timelion, übrigens Timeline ausgesprochen, ist eine Erweiterung für das bereits bekannte Kibana Webinterface. Es ist dazu gedacht Daten aus einem Elasticsearch Cluster visuell darzustellen. Anders als die bisherigen Visualisierugsmethoden von Kibana wird bei Timelion aber nichts zusammen geklickt und gefiltert. Stattdessen müssen die eingebauten Funktionen direkt aufgerufen und mit Parametern gefüllt werden. Klingt erst mal kompliziert, nach etwas Übung geht das aber schneller als alles mit der Maus zu bedienen.

Ein Beispiel: Um die Anzahl der Dokumente in Elasticsearch zu zählen, wird die Funktion es() verwendet. Sie erwartet als Parameter eine Query. Mit es(*) werden sämtliche Dokumente gezählt, die Query dabei ist *

timelion default query

Als Query kann alles eingegeben werden was das normale Kibana Interface auch versteht, also Apache Lucene Syntax. Zum Beispiel kann ich die Anzahl der Checkresults darstellen, die mein Icinga gerade ausführt: .es(type:icingabeat.event.checkresult)timelion icingabeat checkresults

Einfach Dokumente zu zählen reicht aber oft nicht aus, insbesondere im Hinblick auf Metriken. Wichtig an dieser Stelle ist der eigentliche Wert von einem Eintrag, nicht die Anzahl der Einträge. Die es() Funktion kann mit ihrem metric Parameter genau das tun. Man muss sich lediglich entscheiden mit welcher Methode man die Daten aggregieren möchte. Auch wenn die Daten nicht in einem definierten Zeitrahmen in Elasticsearch gespeichert werden, müssen sie spätestens bei der Darstellung irgendwie zusammengefasst werden um einen gleichmäßigen Graphen anzeigen zu können. Timelion versucht den Abstand in dem Daten aggregiert werden automatisch zu ermitteln, meistens ergibt das “Sekündlich”. Ob das der richtige Intervall ist, hängt davon ab wie schnell die Daten rein fließen. Wie viele MySQL Queries Icinga 2 innerhalb der letzten Minute ausgeführt hat, lässt sich zum Beispiel folgendermaßen ermitteln:

.es(metric=avg:perfdata.idomysqlconnection_ido-mysql_queries_1min.value).label("1 min").title("MySQL Queries").color(green)timelion icingabeat mysql

Hier sieht man auch das sich mehrere Funkionen aneinander ketten lassen. Zum Beispiel zum setzen von Titel oder Farbe. Timelion bringt eine ganze Fülle an Funktionen mit die die Darstellung der Daten beeinflussen. Ich will nicht alle aufzählen, weitere Beispiele aber sind:

  • bars(): Ein Barchart anstelle einer Linie
  • movingaverage(): Berechnet den gleitenden Durchschnitt
  • min(), max() und sum(): Erklärt sich von selbst

Es können auch mehrere Linien innerhalb eines Graphen angezeigt werden, dazu wird die Funktion einfach mehrfach aufgerufen. Hier ein vergleich der Ausführungszeiten von Icinga Plugins:

.es(metric=avg:status.avg_execution_time), .es(metric=avg:status.max_execution_time), .es(metric=avg:status.min_execution_time) timelion icingabeat execution time

Insgesamt ist das nur ein kleiner Teil dessen was Timelion kann. Auch wenn die Bedienung etwas gewöhnungsbedürftig ist, so kommt man nach etwas Übung schnell rein. Die Graphen die erstellt werden können entweder als eigenständige Dashboards abgespeichert werden oder als einzelne Visualisierungen. Werden die Graphen einzeln abgespeichert können Sie zu Kibana Dashboards hinzugefügt werden. Dadurch ergibt sich eine gute Ergänzung zu den normalen Visualisierungen.

Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Netways auf der Elastic{ON}17

Wie letztes Jahr hatten einige von uns die grossartige Gelegenheit, die Elastic{ON} in San Francisco besuchen. Dort stellt Elastic sämtliche kommenden Neuerungen am Elastic Stack vor. Daneben haben auch einige Kunden und Partner die Möglichkeit, ihre Use-cases oder Services zu präsentieren sowie ihr eigenes Setup und dessen Herausforderungen zu zeigen.

Die Neuigkeiten im Stack zeigen vor allem drei Schwerpunkte: Graphische Bedienung, mehr Visualisierungen in Kibana und noch mehr Stabilität. So sind eine graphische Aufbereitung und wohl auch eine teilweise graphische Konfiguration von Logstash Pipelines via Kibana geplant.

In Kibana selbst tut sich sehr viel. Da kommen neue Visualisierungen, insb. für Geolocation und ein “Visualisation Builder”, mit dem man deutlich ausgefallenere Graphen als bisher erstellen kann. In einer one-on-one Test Session konnte ich dieses Feature schon mal bestaunen, bin aber, ehrlich gesagt, etwas an der Komplexität und der ungewohnten Bedienung gescheitert. Entweder hat da noch der Jet-Lag zugeschlagen oder Elastic sollte noch etwas an der Bedienung feilen, die ja sonst doch sehr eingängig ist.

An der Stabilität wird insbesondere bei Elasticsearch gearbeitet. Dabei ist wohl eine Art “Transaction Log” geplant, das endlich schnelle Neustarts von Clusterknoten ohne vorherigen “Flushed Sync” ermöglicht und auch sonst sehr zur Stabilität beitragen soll.

Es wäre nicht Elastic, wenn nicht auch eine Menge Livedemos vorgeführt werden würden, was wir sehr schätzen, da sie doch auch einen wirklich sehr konkreten Nutzen für die Teilnehmer haben. Da heben sich die Elastic Mitarbeiter wirklich von vielen anderen Sprechern auf, insbesondere amerikanischen, Konferenzen positiv ab. Eine besonders beeindruckende Demo war der Auftakt der Konferenz mit einer Tänzerin, deren Bewegungen und Herzschlag live in Kibana visualisiert wurden. Das schien tatsächlich live zu sein, da Kibana durchaus auch mal den ambivalenten Smiley zeigte, der angibt, dass aktuell keine Datensätze gefunden wurden.

Es ist noch etwas zu früh, um alle Änderungen sichten und bewerten zu können, aber es sieht jedenfalls so aus, als hätte Elastic etliches in petto, das uns als Elastic Stack Usern das Leben deutlich einfacher und vor allem bunter machen würde. Wie immer schwebt das Damoklesschwert “kommt dieses Feature in X-Pack oder bleibt es frei” über jeder angekündigten Neuerung, aber das scheint teilweise noch gar nicht entschieden zu sein. Ziemlich sicher wird “Machine Learning” ein Kibana Feature, das aus “Prelert” entstanden ist, nur für Nutzer von X-Pack erhältlich sein. Ob “Canvas”, ein Feature, mit dem Reports und Präsentationen aus Kibana heraus erstellt werden können, frei verfügbar sein wird, wird noch entschieden. Auf jeden Fall würde das vielen Usern sehr weiterhelfen, nach dem, was wir an Nachfragen erhalten.

Viele der Features wurden für “kommende Releases” angekündigt. Einige davon kommen in 5.3, andere erst in 6.0.

Auf jeden Fall war die Konferenz wieder die Reise wert und ich kann es kaum erwarten, mit den neuen Features zu experimentieren und sie umzusetzen.

Ganz abgesehen von der Konferenz ist San Francisco natürlich auch für sich genommen eine wunderbare Stadt und wir alle sind sehr froh, dass die Reise so gefallen ist, dass wir uns auch noch etwas die Stadt ansehen konnten.

Wer noch keinen Kontakt zum Elastic Stack hatte, sollte sich einmal unsere Schulungen zum Thema ansehen. Die kurz und knackig und bieten alles, was man für einen Start in die Welt des Logmanagement braucht.

Dass der Blogpost etwas später als gewohnt erscheint liegt an der Zeitverschiebung und dem einen oder anderen wunderbaren IPA, das es hier zu probieren gab.

Die Talks gibt es sicherlich demnächst im Archiv nachzusehen.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

Fully packed to reduce heating – OSMC 2016 – Tag 3

OSMC Logo
Nach zwei interessanten Tagen mit Vorträgen ging es heute zum Abschluss wieder ans gemeinsame Hacken beim Hackathon. In einer kurzen Vorstellungsrunde kristallisierten sich bereits die Themen heraus und es ging sofort ans umgruppieren um den gemeinsamen Interessen zu folgen.

Neben viel Erfahrungsaustausch, migrierten Monitoringumgebungen, internen Skripten rund um Icinga 2, umgebungsspezifischen “Icinga Web 2”-Modulen und Prototypen wie “Icinga 2”-SNMP-MIBs und Debian-Packages für NSClient++, gibt es auch tatsächlich Ergebnisse zu vermelden.

Hackathon

* Das neue Puppet Module für Icinga 2 erhielt Unterstützung für SLES 12 (Pull-Request on Github)
* Die “Icinga 2”-Vagrant-Boxes erhalten Proxy-Support (Pull-Request on Github)
* Der Prototyp eines Elastic-Icinga-Beat (Prototype on Github)
* Das mit Dashing-Icinga2 zur Verfügung gestellte Dashboard wurde um weitere Funktionalitäten erweitert (Commit bereits gemerged)
* Das “Icinga Web 2”-Module NagVis wurde erweitert, unter anderem um Zoom für Dashboards (Commit bereits gemerged)
* Icinga Web 2 kann nun konfiguriert werden um Standalone zu laufen (Patch verfügbar)
* Neben einem kleinen Fix wurde dem Foreman-Smart-Proxy Monitoring-Plugin beigebracht Hosts in Icinga 2 anzulegen (Feature-Branch auf Github)
* Einen adaptiven Http-Check (Repository auf Github)

Ich würde es bei diesem Output als einen erfolgreichen Hackathon bezeichnen!

P.S.: Wer viel auf Github unterwegs ist, dem möchte ich noch den Artikel zum Erstellen eigener Labels ans Herz legen. Der erwähnte Smart-Proxy hat nun farblich korrekte Labels für Icinga 2 und Zabbix.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.