Seite wählen

NETWAYS Blog

Most awaited OSMC is here!!

Hello! Your long wait is over and finally OSMC day starts. As the day begins with the following workshops Icinga 2 – Distributed Monitoring by Lennart Betz, Ansible – Configuration Management by Thilo Wening, Timesseries & Analysis with Graphite and Grafana by Markus Waldmüller and Elastic Stack – Modern Logfile Management by Thomas Widhalm. WOW! Lot more to know.
Bernd will kick start the Day 2 & 3 with so much exciting talks, Alba Ferri Fitó from Vodafone, Martin Schurz from T-Systems, Rihards Olups from Nokia, James Shubin from Red Hat and the long list of the speakers across the world. The day will follow by “evening event” where you can socialize with the fellow with the same interest.
Last day of conference is the “Hackathon Day”.
Download our OSMC App and Enjoy the conference.
 
 
 

Keya Kher
Keya Kher
Marketing Specialist

Keya ist seit Oktober 2017 in unserem Marketing Team. Nach ihrer Elternzeit ist sie seit Februar 2024 wieder zurück, um sich speziell um Icinga-Themen zu kümmern. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

Open Source Monitoring Conference 2017 – Last Ticket to grab!

The Open Source Monitoring Conference is the world’s leading interactive, community networking conference. This is your chance to network with more than 200 Open Source Monitoring community developers, system engineers, network engineers and IT managers from all over the world.
You will get a chance to hear and interact from around 34 expert speakers including Alba Ferri Fitó (Vodafone), Rihards Olups (Nokia), Martin Schurz (T-Systems), James Shubin (Red Hat), Holger Koch (DB Systel GmbH), Walter Heck (OlinData), Jan Doberstein (Graylog Inc), Bodo Schulz (CoreMedia) and many more.
The experts will get your insight with the cutting-edge agenda which will help you to gain actionable insight into 2017’s biggest challenges. For your food for brain, we announce last minutes shout out for all to grab the seat ticket. Get your ticket on www.osmc.de

Keya Kher
Keya Kher
Marketing Specialist

Keya ist seit Oktober 2017 in unserem Marketing Team. Nach ihrer Elternzeit ist sie seit Februar 2024 wieder zurück, um sich speziell um Icinga-Themen zu kümmern. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

Graphite entlasten mit Carbon Relay (NG)

Graphite ist eine der beiden häufig genutzten Lösungen zum Erstellen von Graphen durch (nicht nur) Icinga 2. Im Gegensatz zu PNP4Nagios, das zusätzliche Software braucht, bringt Graphite mit dem Carbon Cache schon von Haus aus eine Lösung mit, die Daten zwischenspeichern kann, bevor sie auf Platte geschrieben werden. Während eine einzelne Graphite Installation so etliche Datenpunkte in kurzer Zeit „verdauen“ kann, so stösst auch Graphite irgendwann an seine Grenzen.
Eine Lösung, die sich bei einigen Setups bewährt hat, ist ein Carbon Relay. Eigentlich dafür gedacht, Daten auf mehrere Carbon Cache Instanzen aufzuteilen, bietet ein solches Relay auch die Möglichkeit, eine weitere Pufferinstanz einzuführen und so noch besser Lastspitzen abzufangen. Sollte das Relay nicht als Pufferinstanz ausreichen, ist damit schon die Grundlage gelegt, Graphite in der Breite zu skalieren.
Zur Auswahl stehen zwei Implementierungen des Carbon Relay, wobei der neuere, Carbon Relay NG genannte, Rewrite in „Go“ bisher deutlich bessere Ergebnisse gebracht hat. Zur Installation werden Pakete angeboten, die auch über Repositories zu beziehen sind. Leider stehen keine einfachen Repo-Files, die die Repositories in den Package Manager konfigurieren, zur Verfügung. Statt dessen wird man gezwungen, ein Script auszuführen, das erst Abhängigkeiten installiert und dann ein passendes Repofile zusammenbaut und ablegt. Da ich nicht gern einfach irgendwelche Scripts auf meinen Hosts laufen lassen, habe ich die Anleitung auf einer Wegwerf-VM befolgt, die Schritte auf den eigentlichen Hosts nachempfunden und das Repofile kopiert. Danach reicht auf CentOS 7 ein yum install carbon-relay-ng um das Relay zu installieren.
Leider scheint das Paket noch nicht ausreichend für CentOS 7 angepasst zu sein, weshalb ein paar Nacharbeiten nötig sind: Die beiden Verzeichnisse /var/spool/carbon-relay-ng und /var/run/carbon-relay-ng müssen angelegt werden. Ausserdem braucht die Konfigurationsdatei /etc/carbon-relay-ng/carbon-relay-ng.conf noch ein paar kleinere Anpassungen. Sehr wichtig dabei ist, zwei Leerzeichen in der addRoute Zeile vor dem Empfänger zu verwenden.

instance = "default"
max_procs = 2
listen_addr = "0.0.0.0:2003"
pickle_addr = "0.0.0.0:2013"
admin_addr = "0.0.0.0:2004"
http_addr = "0.0.0.0:8081"
spool_dir = "/var/spool/carbon-relay-ng"
pid_file = "/var/run/carbon-relay-ng.pid"
log_level = "notice"
bad_metrics_max_age = "24h"
validation_level_legacy = "medium"
validation_level_m20 = "medium"
validate_order = false
init = [
     'addRoute sendAllMatch carbon-default  192.168.5.20:2003 spool=true pickle=false',
]
[instrumentation]
graphite_addr = "localhost:2003"
graphite_interval = 1000  # in ms

Dabei ist natürlich 192.168.5.20 durch die IP der Carbon Cache Instanz zu ersetzen.
Leider ist die Dokumentation des carbon-relay-ng aktuell noch etwas dürftig, weshalb einiges an Probiererei gefragt ist, wenn man die Funktionen ausreizen möchte. Zum Probieren und Testen habe ich Vagrant Boxen gebaut, die aktuell nicht viel mehr sind als Prototypen. Wer Erfahrung mit Vagrant und Puppet hat, kann die aber ganz gut als Ausgangsposition nehmen. Wenn sie mal ein bissl ausgereifter sind, wandern die auch aus meinem privaten Github Account in einen „offizielleren“.
Ein grosser Vorteil des Carbon Relay NG ist, dass es nicht nur puffern, sondern die Daten auch sehr einfach auf mehrere Carbon Cache Instanzen verteilen kann. Dazu ändert man einfach den init Teil der Konfigurationsdatei auf folgende Version (auch hier wieder zwei Leerzeichen vor jedem Ziel):

init = [
        'addRoute consistentHashing carbon-default  192.168.5.20:2003 spool=true pickle=false  192.168.5.30:2003 spool=true pickle=false',
]

Dabei wird der cosistentHashing Algorithmus von Graphite verwendet, der Metriken anhand ihres Namens auf verschiedene Instanzen verteilt. Somit kann man ganz einfach die Schreiblast auf beliebig viele Carbon Caches verteilen und stellt sicher, dass die Metriken immer am gleichen Cache ankommen. Am besten funktioniert das, wenn man die Verteilung konfiguriert, bevor zum ersten mal Daten in die Carbon Caches geschrieben werden. Sollte man eine bestehende Installation umziehen wollen, muss man alle bereits angelegten Whisper Files auf alle Carbon Caches verteilen. Also eigentlich nicht alle, da es aber nicht einfach nachvollziehbar ist, welche Metriken der Hashing-Algorithmus wo hin schreibt, ist es sicherer, alle zu kopieren und nach einiger Zeit mit find diejenigen zu suchen und zu löschen, in die schon länger nicht mehr geschrieben wurde. Das sollte man ohnehin regelmässig machen, da Whisper Files von Hosts und Services, die man in Icinga 2 umbenennt oder entfernt, liegen bleiben.
Hat man mehrere Carbon Cache Instanzen als Ziel konfiguriert, muss man sie auch für Graphite-Web nutzbar machen. Viele Addons wie Grafana nutzen die API von Graphite-Web, um auf die in Graphite gespeicherten Daten zuzugreifen, weshalb es naheliegend ist, sämtliche Datenquellen dort zu hinterlegen. Graphite-Web lässt in seiner Konfiguration mehrere Datenquellen zu, wobei 3 davon für uns relevant sind:

  1. lokale Whisper Files
  2. Andere Graphite-Web APIs
  3. Andere Carbon Caches (hier sollten nur die angegeben werden, die auf dem selben Host liegen, wie Graphite-Web, sonst lieber den Umweg über Lösung 2)

Da Graphite-Web üblicherweise so konfiguriert ist, dass es die lokalen Whisper Files verwendet, muss in local_settings.py nur mehr die zusätzliche Graphite Instanz auf dem hinzugekommenen Host konfiguriert werden. (Port 8003 ist hier aus den oben genannten Vagrant Boxen entnommen. Natürlich muss hier konfiguriert werden, wie das andere Graphite Web erreicht werden kann)

CLUSTER_SERVERS = ["192.168.5.30:8003"]

So erreicht man zwar keine Hochverfügbarkeit, aber das liesse sich relativ einfach erreichen, in dem man mehrere Graphite Webs anlegt, die jeweils ihre lokalen Whisper Files und die APIs aller anderen Instanzen konfiguriert haben. Davor einen Loadbalancer, fertig. Auf jeden Fall hat man auf diese Weise aber Carbon Cache in die Breite skaliert, was für grosse Installationen, die vielleicht nicht nur aus Icinga 2, sondern auch aus dem Elastic Stack und collectd Daten erhalten, einige Probleme lösen kann.
Wer jetzt Lust bekommen hat, mehr über Graphite zu erfahren, der sollte sich mal unser Schulungsangebot dazu ansehen.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Fully packed to reduce heating – OSMC 2016 – Tag 2

OSMC LogoDer gestrige Tag endete in lockerer Atmosphäre in der Indabahn, die wir nach ein paar Jahren am Flughafen wieder zur Abendlokation erkoren hatten, und für die Ausdauernden in Checkpoint Jenny, unserer üblichen Late-Lounge. Aufgrund unserer Rekordteilnehmerzahl gab es auf der Abendveranstaltung ein Running Buffet, so dass man einfach entspannt sitzen bleiben und sich unterhalten konnte und trotzdem gut mit Essen und Getränken versorgt wurde. Für weitere Unterhaltung war mit mehreren Roulette-Tischen gesorgt, an denen natürlich nicht um echtes Geld sondern um die Platzierung und damit den Preis für den ersten Platz gespielt wurde.
Trotz allem hatte Mario Mann volles Haus für den ersten Vortrag „Application Performance Management with Open-Source-Tooling“ des Tages. Primär ging es um InspectIt welches Mario sowohl kommerziellen Tools gegenüberstellte als es auch in die Landschaft der „Open Source“-Monitoring-Tools einordnete. Auch hier drehte sich alles um Metriken, diesmal zur Erkennung von Anomalien in der Anwendungsperformance, und um die weiteren Daten um diese Anomalien richtig einzuordnen. Ein weiteres nettes Werkzeug, das ich aus dem Vortrag mitnehme ist WebPagetest.org.
Der „Engineer’s guide to Data Analysis“ von Avishai Ish-Shalom spannte die Teilnehmer direkt ein um Problemanalyse auf Basis von Metriken zu betreiben. Ein paar der erlernten Lektionen: Durchschnittswerte sind nicht gut, die schlechtesten 5% (oder 1%) und möglichst nicht aggregierte Daten zeigen das Problem deutlicher. Aggregation ist nötig um die Daten speichern zu können, allerdings muss man im Vorfeld wissen wie man die Daten nutzen will um sie richtig zu aggregieren. Dies gilt auch für die graphischen Tools, die automatisch Daten zur Anzeige aggregieren.
„What’s Happening with OpenNMS“ war der Update-Vortrag zu OpenNMS von David Hustace. Auch OpenNMS hat eine stetig wachsende Community und Feature-Liste, mit den üblichen Verdächtigen wie API und Grafana-/Elasticsearch-Integration. Die Integration von Backshift und R zur Darstellung von Graphen erlaubt eine richtige schöne Interaktion mit den Daten wie beispielsweise Live-Analyse und Vorhersage für Trends. Das neue BusinessProcess-Tool sieht auch sehr interessant aus, in der Icinga-Welt würde ich es als Mischung aus dem BusinessProcess Modul und NagVis bezeichnen. Allgemein kann man sagen viel Modernisierung hat in den letzten Monaten stattgefunden und wird es in den nächsten noch weiter tun.
Frisch gestärkt ging es nach dem Mittagessen weiter mit Thomas Niedermeier und „Hello Redfish, goodbye IPMI – The Future of Hardware Monitoring“. Nach einem Abriss warum man Remotemanagement einsetzen sollte und warum IPMI nicht mehr zeitgemäß ist, ging es um Redfish welches seit 2014 versucht eine moderne Lösung für diese Aufgabe darzustellen. Die Lösung basiert auf einer REST-API mit entsprechender Authentifizierung. Wer will kann also schon mit einem einfachen Browser-Plugin oder etwas python-Code arbeiten, die DMTF liefert allerdings sogar schon entsprechende einfache Tools. Es sieht also aus als könnte in naher Zukunft das IPMI-Protokoll zu Gunsten von Redfish abgeschaltet werden.
Nach seinem Vortrag fand dann auch gleich die übliche Hardware-Verlosung statt bei der Thomas-Krenn sich als Sponsor wie üblich nicht Lumpen gelassen hat und so durften drei Teilnehmer mit einer neuen Laptop-Tasche, SSD oder gar Mini-Computer nach Hause gehen. Ebenfalls wurde der Roulette-Gewinner der Abendveranstaltung mit einer smarten Waage beehrt, die man nach einer OSMC sicherlich gebrauchen kann.
Jan Doberstein mit „Take Care of your Logs“ machte deutlich warum Logging wichtig ist und warum man Log-Events zentral sammeln sollte. Vom einfachen zentralen Syslog-Server über den Platzhirsch Elastic Stack ging es zu Graylog, welches einem gesamtheitlichen Ansatz folgt um Logs zu normalisieren und anzureichern um sie möglichst hilfreich zu präsentieren. Klarer Vorteil bei Graylog ist und bleibt die schöne Zugriffsteuerung auf die gesammelten Daten. Für Neugierige sei gesagt, dass die Open Beta der nächsten Version kurz vor der Veröffentlichung steht, die es noch flexibler machen wird.
„Software Development seen from a #yolo^Wdevop“ von Jan Wagner aus dem Monitoring-Plugins-Projekt zeigte wie sich die Entwicklerwerkzeuge vom Texteditor zu heutigen Toolchains weiterentwickelt haben (inklusive YoloOps Bingo). Ich kann nur sagen ein schöner Einblick in das Projekt und eine nette Auswahl an Tools.
Ich fand es mal wieder eine sehr schöne und interessante Konferenz. Meinen Dank dafür an alle Speaker und Teilnehmer. Ich wünsche allen, die nicht zum Hackathon bleiben können, eine gute Heimfahrt und wir sehen nächstes Jahr am 21. bis 24. November wieder.
Bilder folgen!

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman 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 wie nun bei NETWAYS.

OSDC Workshops 2016

Nur noch ein paar Wochen bis zur nächsten Auflage der OSDC in Berlin. Wir freuen uns wie immer schon jetzt über das große Interesse und die spannenden Vorträge. Bereits seit einigen Jahren bieten wir sowohl vor der OSDC als auch OSMC fachspezifische Workshops an. Ziel davon ist es, in die entsprechenden Technologien etwas weiter einzusteigen. Zwar kann der eintägige Workshop keine vollwertige Schulung ersetzten, jedoch bietet er einen detaillierten Einblick. Für die diesjährigen OSDC-Workshops haben wir uns folgende Schwerpunkte gesetzt:
Advanced Graphing
Bei diesem Workshop geht es wie der Name bereits vermuten lässt um die Speicherung und Analyse von Metriken. Haben wir uns jahrelang mit RRD basierten Add-ons begnügen müssen, bieten moderne Frontends wie Grafana nun sehr flexible Anzeigemöglichkeiten. Der Hauptvorteil liegt vor allem in der Kombination unterschiedlicher Werte innerhalb eines Panels bzw. Dashboards, was sich mit RRD sehr schwierig gestaltet. Da Blerim sich seit vielen Jahren mit dem Thema beschäftigt, weiss er genau worauf es in der Praxis ankommt und der Besuch loht sich auf jeden Fall.
Docker
Zugegeben ist Docker schon ein Hype-Thema, aber nach dem anfänglichen „Das ist ja geil, ich finde bestimmt etwas was ich in einen Container stecken kann“, nimmt das Thema auch in der realen Welt immer mehr Fahrt auf. Ob bei uns im eigenen Managed-Service Betrieb oder auch beim Docker-Hosting für Kunden. Es ist auf jeden Fall eine Technologie mit der man sich beschäftigen sollte. Noch dazu scheinen die großen Mitstreiter sich langsam auch in Richtung einer gemeinsamen Spezifikation zu einigen. Das verschafft dem ganzen Thema nochmals zusätzliche Sicherheit. Sebastian, quasi unser Container-Beauftragter und Head of Managed Service, hält den Vortrag persönlich und freut sich auf Sie.
Elastic Stack
Das Thema haben wir in der Zwischenzeit schon einige male unter verschiedenen Namen angeboten. Natürlich entwickeln wir auch das Schulungsmaterial mit jedem Workshop weiter, aber das anfängliche Sammeln von Logs hat unter der Federführung von Elastic ordentlich an Fahrt aufgenommen. Gerade die angekündigten Neuerungen in Logstash 5 versprechen eine transparente Analyse des Informationsflusses und Kibana wird permanent mit neuen Auswerte-Möglichkeiten erweitert. David, der bereits im Bereich Managed Services mit Elastic Erfahrung sammeln durfte, gibt in diesem Workshop praktische Tips aus dem Consulting an sie weiter.
Ich fasse zusammen: Kaufen, Kaufen, Kaufen – Oder eben einfach anmelden. Es lohnt sich!
P.S. Sie haben sich schon für die OSDC, aber nicht für einen Workshop angemeldet? Ein verständlicher, jedoch nicht verzeihbarer Fehler. Wir biegen das wieder gerade 🙂

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.