GitLab Training v2.5.0 released

We have released v2.5.0 of our GitLab training today. Based on the feedback from previous trainings, and many things learned together with the students, we aim for the next classes already.

Dive deep into Git rebase, merge, squash, cherry-pick, get to know real-life development workflows and explore the possibilities of CI/CD pipelines and even more fancy GitLab features. Check our training schedule and register now!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

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

Request Tracker: Highlight tickets based on due dates

A while ago we’ve announced a new extension for Request Tracker which allows to highlight tickets in search results even better.

Next to “last updated by” and custom field conditions, we’ve now added a requirement from production:

  • light red coloring for tickets with a due date in 3 days
  • dark red coloring for everything where the due date already passed

When there’s a ticket which matches one of the other conditions, due date wins over “last updated by” which itself wins over custom field conditions.

v2.0.0 is available on GitHub. Consider asking our sales engineers when building a new RT instance in NWS 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

New Request Tracker Extensions: Search Result Highlights, Quick Assign & User Overview

We use Request Tracker on a daily basis, and have written many extensions for our own workflows and visualizations. Lately we’ve been helping a customer to migrate from OTRS to RT running in NWS, and learned about new ways to improve our workflows.
 

Highlight Search Results on Conditions

When you own a ticket, but someone else updated the ticket with a comment/reply, you want to immediately see this. Our extension makes this possible with either a background color or an additional icon (or both).
You can also limit this to replies/comments from customers, where the last update wasn’t performed by users in a specific group. This allows to immediately see support or sales tickets which need to be worked on in the dashboards.
Another use case is to highlight search result rows when a custom field matches a specified value. If you’re setting tickets for example, you can visually see the difference between a “bought ticket” and “paid ticket” state.
While developing the extension, I’ve also fixed an upstream RT bug which has been merged for future releases. There’s even more possibilities, as we’ve recognised that one of the BestPractical/RT developers forked our extension already 🙂

 

Quick Assign People to Tickets

By default, one needs to edit the “People” tab to assign a ticket to a privileged user, or modify adminCC and the requestor. This takes far too long and as such, our own NETWAYS extension improved this with drop-downs and action buttons. We have now open-sourced this feature set into a new extension on GitHub: rt-extension-quickassign.

 

Show Ticket Count per User and Status

This extension was released a while ago, and we’ve fixed a bug with empty sets in there. In addition to that, we’ve added a new configuration option which allows to list specific groups and their members, and not only privileged users. This comes in handy to only show the NETWAYS members but not any root or meta accounts. Read more on GitHub.
 
Do you need more customizations for Request Tracker, or want to run RT in a managed cloud environment? Just get in touch 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Monthly Snap November


 
Remember one month ago? The first talks were about to start soon, you had your first coffee, enjoyed the rich Holiday Inn breakfast, took your journal, in which you had your plan for the day scetched, you were happy to meet an old friend in the hallway on your way to Saal Jacobi, where Bernd Erk was preparing to kick-off OSMC. …
OSMC – good times! Take some of its spirit with you into the cold and dark december days and let it warm your heart like a cup of hot Christkindlesmarkt mullet wine.

Form OSMC to Open Infrastructure

How? Make yourself a cup of hot wine and read through OSMC 2018 – Day 1 and OSMC 2018 – Day 2 by Dirk, or OSMC 2018 – or: The Thirteen-Star Conference, in which our attendees share their experiences. Read Michi’s Hackathon stories and Dirk’s report about OSCAMP on Puppet. You’re more of a visual type?  Browse through our OSMC Archive and find all the videos, pics and slides.
Right after OSMC our NWS-Team hit the road to Berlin for OpenStack Summit. Check out their managed Open Infrastructure service at nws.netways.de – now with MyEngineer support!

Icinga Seminar & Berlin Camp

Lennart Betz continues his blogpost-seminar Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile and Teil 10: Profile Part II. Join the Icinga community in 2019: Icinga Camp Berlin: Call for Papers is running until Decemeber 31! Find all November Icinga updates here.

For the tech hearts

Achim tell you to Get your RadosGW metrics into Ceilometer. Loei explains the use and functionality of RFID & NFC. Niko shares Neuheiten beim IntelliJ-Update. Tim knows Ceph Mimic | Using loop devices as OSD
In git gud! Henrik tells the story of: How I Learned to Stop Worrying and Love my Code. Noah introduces you with GitKraken to a nearly perfect Git-Client, while Johannes shares another useful tool: PDF manipulieren mit pdftk.

Presents

In November Silke announced Black Friday mal ganz in Orange – Es darf gespart werden und Die neue Generation der SMSEagle NXS-97xx Linie stellt sich vor. It‘s always a good idea to check our Shop for special offers. Especially if you are looking for Christmas presents. In that sense: Entschleunigung vom Weihnachtsstress bei Netways!
Have a wonderful December and Christmas season! Stay tuned!

Julia Hornung
Julia Hornung
Marketing Manager

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

Neuheiten beim IntelliJ-Update

Ob Java12, Kotlin 1.3 oder Neuerungen für Git oder Editor-Features wie mehrzeilige To-do-Kommentare. Das alles erwartet einen in dem neuen großen Update der Entwicklungsumgebung: IntelliJ Idea.

Die Publisher von Jetbrains haben mit der neuesten Version 2018.3 das nächste große Update von Intellji Idea eingeleitet. Mit der Erneuerung kommen neben der Unterstützung von Programmiersprachenversionen noch viele andere Features, die folgende Inhalte liefern.

Neue Features für Java 12 und Kotlin 1.3

IntelliJ unterstützt jetzt das Preview-Feature für die Raw-String-Literale. (Bild: Jetbrains)
(Prewiew-Feature für die Raw-String-Literale)
Intellij Idea beinhaltet zukünftig mit der Version 2018.3 die Unterstützung der kommenden Java-12-Features. Eine Vorschau für die neue Raw-String-Literale kommt mit der im März 2019 neu erscheinenden Version der Programmiersprache. Die neue Anpassung der Java-IDE unterstützt die Funktion bereits auch mit entsprechenden Quick-Fixes, sprich ein Stück Code der durch diese Fix-Funktion markiert wird und entsprechende Lösungen vorschlägt. Doppelter und somit redundanter Code kann ab sofort auch in komplizierten Situationen erkannt werden. Solche Duplikate sind dann im Diff-Viewer einsehbar.
Redundante Bedingungen werden jetzt noch besser erkannt. (Bild: Jetbrains)
(Redundante Bedingungen werden jetzt noch besser erkannt.)
Jetbrains hat einige weitere Quick-Fix-Optionen ergänzt um redundanten Code zu beheben. Unter anderem zählt dazu der überflüssige Sortieraufruf bei einer darauffolgenden Nutzung der Min-Funktion, bei der der Java-Stream-API genauso wie die Erkennung bei vorangegangenen überflüssigen Bedingungen, die bereits durch eine darauffolgende verknüpfte Bedingung abgedeckt ist. Zudem erkennt Intellij mit der neuen Version die redundante Verwendung von Annotations für unterdrückte Inspektionen.
IntelliJ bietet bei einigen Code-Stellen eine automatische Migration zum neuen Kotlin 1.3. (Screenshot: Jetbrains)
(IntelliJ bietet bei einigen Code-Stellen eine automatische Migration zum neuen Kotlin 1.3.)
Zu den Java-Neuerungen hinzu kommt auch noch die Unterstützung von Kotlin 1.3. Damit die Migration des Projekts zur neuen Version vereinfacht werden kann, greift Intellij einem unter die Arme. Zum Beispiel kann man Imports und Kotlin-Dependencies automatisch anpassen lassen. Ebenso gibt es auch für Kotlin Inspektions- und Quick-Fix-Optionen sowie eine verbesserte Unterstützung für Multiplattformprojekte.

Verbesserung der Editor-Funktionen und Git-Integration

Der Editor selbst hat auch einige neue Neuerungen mitgebracht, z.B mehrzeilige To-do-Kommentare(siehe Bild/GIF) oder dass in der Statusbar die verwendete Anzahl an Leerzeichen für Einrückungen angezeigt wird. Falls die Einrückung nicht mit der Projekteinstellung übereinstimmt, wird dies entsprechend markiert und eine Lösung vorgeschlagen. Zusätzlich kommt Ihr über das Pop-up direkt zu den Editor-Config-Dateien für die jetzt auch Syntax-Highlighting sowie Code-Vervollständigung unterstützt wird.

Auch mehrzeilige To-Do-Kommentare sind mit der aktuellen IntelliJ-Version kein Problem mehr. (Bild: Jetbrains)
Bei Git hat sich auch einiges geändert wie zum Beispiel, dass Intellij jetzt Github-Pull-Requests unterstützt und die Funktion „History up to Here“ die gesamte Historie aufzeigt. Auch nützlich dürfte die Funktion sein, die es erlaubt, eine Datei aus einem anderem Branch zu kopieren. Einfach ein Rechtsklick auf die ausgewählte Datei und schon gelangt man ins Compare-Branches-Fenster.(siehe Bild)
Mit wenigen Mausklicks kann jetzt eine Datei von einem anderen Branch kopiert werden. (Screenshot: Jetbrains)
Neben der überarbeiteten Funktion zum Durchsuchen des gesamten Projekts hat Jetbrains einige weitere kleinere Neuerungen zur Verfügung gestellt. Das betrifft Kubernetes, Javascript und Maven. Alle Neuerungen diesbezüglich findet Ihr auf der Internetseite von Jetbrains unter diesem Blog.

Niko Martini
Niko Martini
Junior Developer

Egal ob zu Hause oder bei NETWAYS, Niko hockt gern vor dem PC. Ab und zu fährt er auch mal mit seinem Dad auf eine Fahrradtour quer durch Deutschland. Nach seinen ersten Tagen bei uns, in denen er NETWAYS, die Kollegen und Tools näher kennengelernt hat, freut er sich besonders auf die kommenden Jahre.