Namen sind Schall und Rauch? Lieber nicht.

Das Problem

Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob der Elastic Stack oder Graylog verwendet wird, um die Nachrichten zu “zergrokken”, wie es mal ein Kunde so schön formuliert hat.

Das Kuddelmuddel rund um die Feldnamen hat einige Nachteile, die früher oder später zuschlagen:

  • Ein Feld innerhalb eines Index darf nur einen Typ haben. Wenn also zufällig zwei Regeln ein Feld namens errorlevel anlegen und eine schreibt debug rein, die andere 4 wird das früher oder später dazu führen, dass Events von Elasticsearch abgelehnt werden
  • Gemeinsame Dashboards gestalten sich schwierig, wenn die IP des sich verbindenden Hosts mal in client , mal in client_ip und mal in anfragenderhost drin steht
  • Andere Tools und mitgelieferte Regeln / Dashboards haben keine Möglichkeit, vorherzusagen wie Felder heissen werden, deren Informationen sie brauchen

Schon immer galt die Empfehlung, sich ein Namensschema zu überlegen und sich strikt dran zu halten. Das klappt leider meist schon nicht, wenn nur eine Person dran arbeitet und wird nahezu unmöglich, wenn mehrere Teams eine gemeinsame Konfiguration pflegen. Das muss gar nicht einer gewissen Nachlässigkeit geschuldet sein, sondern kann alleine schon daraus resultieren, dass die gleichen Dinge manchmal in verschiedenen Teams einfach unterschiedlich genannt werden. Man muss nur an die Diskussion rund um “Satellite” oder “Slave” bei Icinga 2 oder die verschiedenen Logstash Instanzen (“Shipper”, “Indexer”, “Forwarder”, “häh?”) denken, um ein naheliegendes Beispiel zu haben.

ECS to the rescue

Elastic hat nun eine schöne, wenn auch noch nicht umfassende Lösung dafür geschaffen: Das “Elastic Common Schema”, kurz ECS.

Beschrieben in einem eigenen Abschnitt der Dokumentation. Darin sind Regeln festgelegt, wie Felder heissen müssen, die bestimmte Daten beinhalten. So gibt es z.B. nicht mehr logsource oder beat.hostname sondern host.hostname (der Host, auf dem das Event passiert ist, das den Logeintrag ausgelöst hat) und agent.name (Name des Agenten, der die Nachricht verschickt hat – kann der Hostname sein, aber auch ein Custom Name, falls z.b. mehrere Filebeat auf einem Host laufen)

Definiert im ECS sind eine ganze Menge von Überkategorien unter denen dann verschiedene Unterfelder definiert sind, die dann wiederum einen “Level” haben. Der Level gibt an, ob die Felder nach Möglichkeit befüllt werden sollen (“core”) oder eher optional sind (“extended”). Die core-Felder werden auch von diversen Tools des Elastic Stack genutzt, um automatische Auswertungen zu erlauben, was gleich einen riesigen Vorteil des ECS offenbart: Man kann damit viel einfacher fertige Lösungen verschicken, weil man nicht mehr rätseln muss, wie denn die Felder heissen könnten, in denen die wertvollen Informationen stecken.

So wird den meisten langjährigen Usern von Kibana aufgefallen sein, dass es inzwischen eine grosse Menge weiterer Tools in Kibana gibt als die klassischen “Discover”, “Visualize” und “Dashboard”. Die neuen Tools wie SIEM oder Infrastructure verlassen sich darauf, dass die benötigten Informationen in den richtigen Feldern abgelegt sind. Wenn man also ECS umsetzt, dann funktioniert z.B. der SIEM Teil von Kibana mehr oder weniger ohne weiteres zutun.

Im ECS ist auch definiert, welchen Typ welches Feld haben sollte. Sprechen Beats direkt mit Elasticsearch, kümmern sie sich darum, dass das richtig gesetzt wird. Baut man seine eigene Zerlegung in Logstash oder Graylog, dann sollte man darauf achten, dass die Felder auch entsprechend typisiert sind. In den meisten Fällen ergibt sich das aus der Art von Information, die im Feld gespeichert wird automatisch – man sollte dennoch immer wieder mal kontrollieren, ob nicht das eine oder andere durchgeschlüpft ist. Es sollte aber auch nichts dagegen sprechen, die Multifields von Elastic Search zu nutzen. Wird also ein Feld vom Typ keyword gefordert, kann man es auch als string in Elasticsearch schreiben, da der immer sowohl als text und als keyword abgelegt wird.

Der Umstieg

Wer schon ein funktionierendes Logmanagement hat, kann übrigens ziemlich sanft auf ECS umsteigen. ECS erlaubt nämlich ausdrücklich auch, eigene Felder zu definieren. Anders ausgedrückt sollten die relevanten Informationen in den angegebenen Feldern vorhanden sein. Ausser der dabei entstehenden Ressourcenverschwendung spricht aber nichts dagegen, die Daten auch in den zuvor genutzten Feldern vorzuhalten, solange man migriert. Man kann also die Information durchaus duplizieren, falls das nötig ist.

Wer noch ältere Clients im Einsatz hat, muss ohnedies vorsichtig sein, da Elastic die Standardfelder, die automatisch hinzugefügt werden, im Laufe der Zeit in einer nicht abwärtskompatiblen Art verändert hat. So kommen insbesondere Logs, die über Syslog verschickt wurden mit einem host Feld, in dem schlicht der Hostname drin steht. Laut ECS (und damit auch in Events von Beats) ist host aber ein “Nested Field”, das selbst wieder Unterfelder beinhaltet. Schickt man also in den selben Index Events, die man über Syslog-Protokoll erhalten hat und solche, die via Beats eingeliefert wurden, dann hat man leicht einen type mismatch. Dabei ist das nur eines von mehreren möglichen Beispielen. Die Logs von Elasticsearch und Logstash bzw. Graylog zeigen, wenn Events abgelehnt werden und üblicherweise auch wieso.

Eine gewisse Herausforderung ist dabei wieder, sich in die verschiedenen Positionen hineinzuversetzen. Aus Sicht des Logadmins ist der Client vielleicht der Agent, der die Nachricht verschickt, aber aus der Sicht dessen, der die Nachricht zur Überwachung seiner Applikation benötigt, ist der Client der, der mit seiner Applikation gesprochen hat. Dafür gibt es eben eigene Felder wie agent oder event, die Metadaten beinhalten können, die sich nur auf das Logmanagement beziehen, nicht auf den Inhalt der Nachricht. Das Problem ist aber nicht ECS spezifisch, sondern allgemein etwas, das Logadmins plagt.

Abschliessendes

Wer neue Regeln zum Zerlegen von Events anlegt, sollte aber von vornherein darauf achten, dass das ECS eingehalten wird. Dazu sollte man noch ein Feld mitgeben, das die ECS Version anzeigt, um in Kibana für Klarheit zu sorgen und ggf. noch ein paar Regeln kurz vor den Outputs einzuführen, die alte Nachrichten nachbessern. Das haben wir z.B. auch in der Logstash Pipeline für Icinga Logs getan.

Wer sich dazu noch etwas ausführlicher erzählen lassen möchte, kann ja mal in einer unserer Elastic Stack Schulungen vorbei schauen.

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...
NETWAYS Winterworkshop 2020

NETWAYS Winterworkshop 2020

 

Da der Winterworkshop mittlerweile schon voll ins Jahresprogramm bei NETWAYS integriert ist, ging es somit auch 2020 wieder in die Berge. Um 13 Uhr stand der Bus bereit, um mit einem Haufen an Essen, Getränken und 45 gespannten Kollegen und Kolleginnen beladen zu werden. Ein paar Stunden und viele Raucherpausen später sind wir in dem leider wenig verschneiten Haidmühle angekommen. Nachdem die Besitzerin der Hütte mit den ersten einen Rundgang gemacht hatte, haben alle stürmisch ihr Zimmer bezogen. Als dann jeder sich eingerichtet hatte, haben wir sogleich mit vereinten Kärften begonnen, das traditionell gute Essen für die Belegschaft zu kochen. Auf dem Menü standen an diesem Abend Schnitzel mit Pommes, Halloumi für die Vegetarier, Preiselbeeren, Salat und als Dessert Crêpes, was auf große Begeisterung stieß. Gut gestärkt konnten wir nun in den Abend starten.

 

 

Das Landhaus Frauenberg bietet zahlreiche Möglichkeiten, sich die Zeit auf äußerst angenehme Weise zu vertreiben. Wir konnten Billard, Tischtennis und Kicker spielen. Außerdem bestand die Möglichkeit, die zwei Saunen und den Whirlpool zu benutzen, was auch selbstverständlich ausgiebig getan wurde. Natürlich haben wir auch wieder viel getanzt und gefeiert. Pünktlich um 0:00 Uhr haben wir auf das Geburtstagskind Artur angestoßen und dann ging die Party so richtig los.

 

Irgendwann gingen alle – früher oder später oder gar nicht – ins Bett, um fit für den nächsten Tag zu sein.

 

Der nächste Tag startete für die einen mit Ski bzw. Snowboard in das Skigebiet Hochficht, während die anderen etwas später zu der Weltkulturerbe Stadt Cesky Krumlov aufbrachen. Eine kleine Gruppe fleißiger Kollegen blieb in der Unterkunft, um die über hundert Rouladen (!) und das Apple Crumble, für das Abendessen vorzubereiten.

 

Nachdem wir uns alle ausgetobt hatten, fuhren wir zurück zur Hütte, wo wir nach einer wiederbelebenden Dusche gemütlich beisammensaßen und sehnsüchtig auf das Essen warteten. An dieser Stelle nochmal vielen Dank an die Kollegen und Kolleginnen, die das ganze Team mit richtig gutem Essen versorgt haben! Es war wirklich mega lecker! Satt und glücklich starteten wir gemütlich ruhig in den Abend, der aber nicht so ruhig bleiben sollte. Nach vielen Getränken, Schlagerhits, Gesprächen und guter Laune fehlte nur noch eins… die NETWAYS- Polonaise natürlich! Und schon stürmte wie gewohnt, mitten in der Nacht, die Polonaise durch die Zimmer der Unterkunft, was bei den Schlafenenden auf helle Begeisterung stieß.

 

Am nächsten Morgen ließen wir uns ein letztes Mal das gute Essen schmecken, bevor wir uns wieder auf den Weg nach Hause machten. Nachdem die letzten Schlagerhits gesungen und das letzte Getränk getrunken war, kamen wir in Nürnberg an, müde und zufrieden. Vom Wochenende bleiben viele lustige Bilder, schöne Erinnerungen und natürlich die Vorfreude auf das nächste Mal!

Andreas Wienkop
Andreas Wienkop
Office Manager

Andreas ist seit 2015 bei NETWAYS. Im November 2018 hat er seine Ausbildung zum IT-Systemkaufmann erfolgreich abgeschlossen und ist nun im Bereich Finance & Administration tätig. In seiner Freizeit widmet er sich dem Reisen und dem Boxen.

Automatic PDF Generation with Google Chrome

Many developers get, sooner or later, the task to generate PDF documents automatically. Though, less developers put their experiences and insights then into a blog-post to save others some hassle. So let me do you a favor by explaining how we utilize Google Chrome in headless mode to generate pretty PDF files from HTML.

I won’t go into the details why Google Chrome. If you found this blog entry I suppose you already tried other options without success or satisfying results. We sure have tried several other options (e.g. wkhtmltopdf, dompdf, tcpdf) but only Google Chrome provided us with the results we wanted.

Another advantage of Google Chrome is the possibility to instrument a remotely running instance. And that’s exactly how we instruct it to generate a PDF file for us. Though, not with Puppeteer but with plain chrome devtools protocol (CDP) communication over a websocket.

I’ll avoid any programming language specific examples. You can take a look here at our implementation in PHP. So, let’s start with it.

The Process to Print HTML to PDF

First you’ll need to connect with the browser by use of a websocket connection at: ws://10.11.12.13:9222/devtools/browser/79744167-25f0-41a8-9226-382fa2eb4d66

This is printed on stderr right at launch of the process and also available on the JSON api: 10.11.12.13:9222/json/version

The important bit is the browser id (79744167-25f0-41a8-9226-382fa2eb4d66) at the end of the URI. This changes every time the process is launched and can’t be configured.

Communicating with the browser now takes place over this socket by transmitting and receiving JSON messages. They are divided into four types:

Calls

These primarily originate from ourselves. They contain an id, a method and parameters:

{ “id”: <mixed>, “method”: <string>, “params”: <object> }

The id is chosen by us and should be different for each call. It’s sent back with the response so it’s possible to later associate it with the call we made. Though this is mostly relevant if you are not communicating synchronously, which we do. So this may just as well be an integer incremented by 1 each time.

Results

These are sent by the browser in response to an API call.

{ “id”: <mixed>, “result”: <mixed> }

Errors

If it’s not a response, it’s an error.

{ “id”: <mixed>, “error”: { “code”: <int>, “message”: <string> } }

Events

These may be sent by the browser at any time.

{ “method”: <string>, “params”: <object> }

Some of these are of interest to us. Some of them are not and can be ignored.

Operating the Browser As Usual

In order to let the browser print us a web page (or HTML) to PDF we need to instrument it the same as when we do it manually on the desktop.

First we need to open a new tab:

Call: { “id”: 1, “method”: “Target.createTarget”, “params”: { “url”: “about:blank” } }

Result: { “id”: 1, “result”: { “targetId”: “418546565-d4f9-4d9f-8569-9ad8f9db7f9de” } }

Now we have to communicate with the tab, which requires a new websocket connection to: ws://10.11.12.13:9222/devtools/page/418546565-d4f9-4d9f-8569-9ad8f9db7f9de

Before we can print anything we have to tell the browser where to load the content to print from. This may either be a URI (which then needs to be accessible for the browser) or raw HTML. I’ll stick to raw HTML here, since it’s the most flexible option anyway:

Call: { “id”: 2, “method”: “Page.setDocumentContent”, “params”: { “frameId”: “418546565-d4f9-4d9f-8569-9ad8f9db7f9de”, “html”: <html> } }

Result: { “id”: 2, “result”: { } }

The next step is the instruction to print the page’s content to PDF:

Call: { “id”: 3, “method”: “Page.printToPDF”, “params”: <object> }

Result: { “id: 3, “result”: { “data”: <string> } }

What parameters you can use to influence the generation (e.g. the layout) are outlined in the official documentation.

The string you will get back is probably encoded in Base64, so decode it and store it where you want. The PDF file has been successfully generated.

If you are planning to use a single process to generate multiple PDFs with, remember to clean up afterwards. (i.e. closing the tab) Otherwise you will soon have a memory usage issue.

Call: { “id”: 4, “method”: “Target.closeTarget”, “params”: { “targetId”: “418546565-d4f9-4d9f-8569-9ad8f9db7f9de” } }

Result: { “id”: 4, “result”: { “success”: <bool> } }

I hope this proves useful to you or convinces you to give Google Chrome a try to generate pretty PDFs. 🙂

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.
NWS announces: Nextcloud Hub now available

NWS announces: Nextcloud Hub now available

Nextcloud released a new version. But it’s not just a normal update, since there are a lot of changes, as they already described in their press release:

“With the release of Hub, Nextcloud brings a free, open source, on-premises office suite to millions of users, lowering the barrier to use. Hub brings office integration to a new level with the built-in sidebar featuring an insight in file activities, file versions, comments, chat, and video calls. […] With Hub come major improvements in Nextcloud Files, Talk and Groupware. Files introduces Workspaces, […] Nextcloud Talk for Hub features a rewritten user interface […] Nextcloud Groupware was improved.” – Nextcloud, Press release 17.01.2020

Since yesterday Nextcloud Hub is also available on the NWS Plattform. The most interesting point is that the new version brought a huge performance improvement to our SaaS (Software as a Service) app. We saw in the past, that Nextcloud 17 was pretty slow with a S3 storage as primary storage. But now we have the best benefits of using our own S3 as a primary storage with a performance that is just awesome. You could call it a “Nextcloud Managed Hosting”

We also decided to stick with Nextcloud Collabora Online instead of OnlyOffice, since we invested a lot of time to optimize Collabora to ensure the best user experience.

What makes Nextcloud Hub as a NWS SaaS app so special?

Feature
Current Version Hub (18.0.0)
Users 25 / 50 / 100
Storage 50 GB / 200 GB / 1000 GB / More possible
Traffic Flat
Collabora Inclusive
Updates Inclusive
Backup (Of configuration) Inclusive
Storage Our own NWS S3 (NOT AWS)
Need to buy a domain No. Use one of our free CNAMEs or use your own Custom Domain
Support 8×5
Migrating to NWS Possible
Installed apps Use our preinstalled apps or install whatever you want from the appstore
Callable Monthly
Server locations Nuremberg, Germany
DC Certificate ISO 27001
Time the app needs to be ready Max. 5 minutes
Special offer First 30 days are for free. Note that it is callable monthly
Costs 9,99 € / 24,99 € / 99,99 €
Start now FOR FREE Show me more informations

What is the NWS SaaS platform about?

With our SaaS platform we provide our customers with applications on demand with almost no need to take care of them. We deliver the features, the updates, taking care of the security and offer support.
Not everyone has the know-how to build up an infrastructure that fits their needs as well as maintaining it. So we created NWS for everyone who don’t want to take care about things they need to work with – we created NWS for everyone who just wants to use the software.

It’s a platform for things like “one klick installation Nextcloud / Gitlab / Rocket.Chat” etc.

Give it a try. If you just want to try, it’s completely for free. WHAT ARE YOU WAITING FOR?

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

OSCamp on Bareos: Submit your Paper!

The title of this year’s Open Source Camp (OSCamp) tells it all: We want your backup stories! And ideally you tell them on stage. This time we focus on the Open Source backup software Bareos. Together with the Bareos company we invite you to share your expertise.

Call for Papers open

Call for Papers is open until March 30, 2020! Share your technical insights into Bareos and offer administrators new impulses for data backup, archiving and recovery. Each presentation is scheduled for 45 minutes, including a 5 to 10-minute Q&A session. Submit your paper at opensourcecamp.de!

The OSCamp on Bareos is where the community, Bareos users and developers meet – it’s an opportunity to talk to like-minded people and share expertise – as a speaker on stage, or as attendee during discussions and breaks.

What is OSCamp all about?

Open Source Camp is a conference format dedicated to changing Open Source projects and products and of course their communities.

The one-day event comprises expert presentations and tutorials on technical backgrounds, insights into the latest developments, how-tos, as well as future trends and perspectives. Focusing on advanced topics, the international addresses experienced administrators and systems engineers.

Get in touch with the Open Source enthusiasts behind the presented projects. Learn new features and techniques, benefit from their extensive know-how and get up-dated on the latest developments.

About Bareos

Bareos (Backup Archiving Recovery Open Sourced) provides an enterprise-level open source platform that preserves, archives and restores data from all major operating systems. The cross-network software protects your most critical data on-premises and in the cloud, including Enterprise Storage Systems.

Bareos offers NDMP support, LTO hardware encryption, bandwidth management, and a sophisticated scheduler that increases the level of automation.

Following stackconf

OSCamp #5 on Bareos takes place directly after stackconf, on June 19, 2020, in Berlin. More about stackconf at stackconf.eu! This is your chance to join two outstanding Open Source events in one week!

More information and tickets at opensourcecamp.de.

 

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.