NETWAYS Webinare: Geballte Power

Am 20. Februar 2019 gibt es eine Doppelfolge unserer beliebten NETWAYS Webinar-Reihe: Vormittags behandeln wir OpenStack und nachmittags Graylog. Was erwartet unsere Teilnehmer inhaltlich?

OpenStack ist seit vielen Jahren in der IT-Branche ein Begriff und wird auf nahezu allen Konferenzen, die sich mit Automatisierung, Hosting, Rechenzentren usw. beschäftigen, beworben und vorgestellt. Unsere eigene IaaS-Plattform baut ebenso auf OpenStack auf – aber was ist OpenStack eigentlich? Wo kommt es her, welche Vorteile bietet die Lösung und was kann ich damit am Ende tun? Diese Fragen wollen wir in unserem Webinar beantworten und einige Möglichkeiten anhand unserer OpenStack-Plattform demonstrieren.

Graylog ist eine vielseitige und umfangreiche Lösung, wenn es um die zentrale Speicherung, Analyse und Auswertung von Logdaten – egal ob Syslog, Windows Event Log, Log-Dateien oder viele andere – geht. Neben einer übersichtlichen Oberfläche bietet Graylog vor allem die Möglichkeit, nativ Berechtigungen auf Inhalten und Dashboards festzulegen und individuelle Streams, Inputs und Filter zu definieren. In der neuen Version 3.0 stehen viele neue Features wie Views, Reports und die neue Sidecar zur Verfügung. In diesem Webinar wollen wir grundlegend auf die Möglichkeiten von Graylog, vor allem jedoch auf die Neuheiten, eingehen und diese vorstellen.

Für alle Freunde unserer Icinga 2 Webinare haben wir leider schlechte Nachrichten, da wir im März das Thema vorerst abschließen wollen:

Aber niemand muss traurig sein – seht Euch unseren Webinar-Kalender einfach an. Wir sind sicher, dass Euch auch die neue Webinar-Reihe zum Thema OpenStack begeistern wird.

Wir freuen uns, Euch in unseren Webinaren begrüßen zu dürfen!

Nicole Lang
Nicole Lang
Sales Engineer

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

Meine ersten eigenen Projekte

Das letzte Mal das ich einen Blogpost geschrieben habe ist jetzt schon ein Weilchen her und das Thema hat sich wenig mit meiner Arbeit beschäftigt – Teamwochenende.

Doch in den letzten Wochen habe ich meine ersten eigenständigen Projekte bekommen. Zunächst hat mir Markus die Aufgabe gegeben eine Backup-Lösung für unsere Notebooks zu finden. Vorgabe hierzu war es, sowohl Disaster Recovery und normale Datensicherung zu bewerkstelligen. Dies habe ich mittels Relax and Recover und DejaDub gelöst.

Natürlich hatte die Aufgabe ihre Tücke, wenn man noch keine Erfahrung mit dem Thema hat, aber zum Einstieg war das genau richtig. Vor Allem hat mir die Aufgabe die Möglichkeit gegeben nicht nur Erfahrung sondern auch Selbstvertrauen zu sammeln.

Danach bekam ich das Stichwort “Puppetized Graphing” zugeworfen, dahinter verbirgt sich dass ich Grafana und Graphite via Puppet installieren sollte. Ziel war es auch das Graphite und Grafana miteinander kommunizieren und alles was dazu gehört, sprich Datenbank und ähnliches. Ich durfte bei Netways auch schon einige Schulungen absolvieren und habe über entsprechende Grundlagenkenntnisse von Puppet verfügt, genauso wie Graphite und Grafana, und hatte auch Unterlagen, sowie Referenzen, aber einige Fallstricke kamen bei dem Thema trotz alledem auf mich zu.

In dem Zeitraum habe ich dutzende Versuche gestartet und bin oft hingefallen und hab Dinge gelernt, die ich ursprünglich gar nicht mit dem Thema in Verbindung gebracht hätte. Zu keinem Zeitpunkt hab ich mich allein gefühlt in meiner Aufgabe, denn auch wenn mal ein Kollege grinsend an der gigantischen Fehlerausgabe vorbei lief, wurde oft genug gefragt ob man mir den helfen könnte und auch umgekehrt, hat mich keiner abgewunken, wenn ich mal Hilfe brauchte.

 

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

Icinga Camp Berlin 2019 – Bekanntgabe der ersten Referenten

Bald ist es so weit! Das diesjährige Icinga Camp Berlin findet am 14. März statt und wir freuen uns, die ersten bestätigten Referenten vorstellen zu können. Auf dem Programm stehen eine Reihe von Vorträgen erfahrener Icinga-Anwender. Die Themen reichen von der Integration mit Elastic und dem HashiCorp Stack bis hin zu Erfahrungsberichten professioneller Icinga-Anwender über Herausforderungen und Best Practices aus der täglichen Anwendung. Nicht zu vergessen die neuesten Nachrichten direkt aus dem Icinga-Team zu aktuellen Entwicklungen und den künftig anstehenden Projekten.

Icinga Camps sind eine großartige Plattform, um Euren Wissensstand zu verbessern und neue Methoden kennenzulernen sowie Eure Monitoring-Kenntnisse zu erweitern. Neben dem Vortragsprogramm dient das Icinga Camps als Treffpunkt für Monitoring-Enthusiasten aus allen Branchen.

 

DIE AGENDA

Bernd Erk  | State of Icinga
Assaf Flato | Migrating from Vanilla to Director based solution – War Story
Jean Flach | IcingaDB Development
Max Rosin | Scaling Icinga2 with many heterogeneous projects – and still preserving configurability
Yaron Idan | Monitoria – A Monitoring Democracyy
Bram Vogelaar | Integrating Icinga 2 and the HashiCorp Stack
Francesco Melchiori | Automating Failure Analysis with KI
Philipp Krenn | Dashboards for Your Management with Kibana Canvas
Eric Lippmann | What’s next in Icinga

 

Die Frühbuchertickets sind bereits ausverkauft, reguläre Tickets sind aber noch zu haben. Also los, hol dir Dein Ticket für das Icinga Camp Berlin 2019!

Du möchtest ein Icinga Camp besuchen, aber Berlin liegt nicht auf Deiner Reiseroute? Kein Problem – wir haben in diesem Jahr noch viele weitere Veranstaltungen. Schau Dir die Icinga Tour Dates 2019 doch mal genauer an.

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...

Windows blocking Icinga 2 with ephemeral port range

Recently a customer opened a support ticket reporting “frozen” Icinga 2 agents on Windows. The agent was still running and writing logs but didn’t respond to connection attempts from an Icinga 2 master or satellite nor did it connect the other way.

The Icinga 2 log showed messages which stemmed directly from Windows and could not be found in the Icinga 2 code.

critical/TcpSocket: Invalid socket: 10055, "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."

What we found after some research is strange enough to make me write this article about. It seems that, depending on version, patch level and installed applications Windows is changing its range of ephemeral ports. So your windows might or might not be blocking ports which Icinga 2 uses for its communication.

What solved the problem was an entry into the Windows hosts registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

Value Name: MaxUserPort Value 
Type: DWORD 
Value data: 65534

You can find more information at Microsoft or in this blog.

Photo by Paweł Czerwiński on Unsplash

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

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

Bewirb dich und fliege zu einem Icinga Camp deiner Wahl!

Für den heutigen Freitag haben wir uns etwas ganz spezielles überlegt. Wir suchen nach wie vor (und eigentlich auch immer) Verstärkung für unser Professional Services Team.

Solltest du dich für den

bewerben und wirst eingestellt, darfst du dir ein Icinga Camp deiner Wahl aussuchen und dort hinreisen.

Zur Auswahl stehen Icinga Camps in:

Also schnell ab mit euch an die Tastatur und schickt eure Bewerbung an jobs@netways.de. Die ersten Camps sind bereits im März (Berlin) und Mai (Atlanta + Seattle).

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.