Graphite Reporting mit der Render-API

Vor kurzem durfte ich mich damit beschäftigen, wie man schnell und halbwegs vernünftig eine Art Reporting für Performance-Daten für Icinga 2 umsetzen kann. Um solche Daten entsprechend aufzubereiten bedarf es weiterer Open-Source-Software. Meiner Meinung nach eignet sich Graphite hierzu am besten. Ich möchte heute einen kurzen Einblick in die Möglichkeiten geben.

Graphite ist ein Werkzeug, welches aus drei Komponenten besteht: Carbon-Cache als Datensammler, Whisper als Storage-Backend und Graphite-Web um die Graphen visuell und als API bereitzustellen. Icinga 2 schreibt die Performance-Daten mit dem “graphite”-Feature direkt an den Carbon-Cache-TCP-Socket. Welche Möglichkeiten habe ich als Anwender nun, diese historischen Daten für meine Zwecke in Reporting zu verwenden?

Eigentlich ganz einfach: Graphite liefert eine eigene Render-API. Diese bietet die Möglichkeit, die Daten als Graph, csv , json, pdf und einige weitere Formate zu generieren. Der Anwender kann diese Daten als REST-API Aufruf im Browser oder beispielsweise curl in der Shell abholen. Dabei können verschieden Metriken und Aggregationen auf Graphen angewandt und unterschiedliche Werte gebündelt abgerufen werden.

 

Wie fange ich an?

Generell wird die URL wie folgt aufgebaut:

http://grtaphite.ip/render?target=icinga2..services.*.*.perfdata.*.value

Im gezeigten Beispiel kann man für die “target”-Metriken auch Wildcards verwenden, um etwa mehrere Services gleichzeitig abzufragen. Dies entspricht dem Dateipfad im Whisper-Backend. Man kann allerdings auch Listen oder Arrays angeben, um gezielt bestimmte Werte abzufragen.

Es gibt unterschiedliche Möglichkeiten, die Daten für die entsprechenden Ausgaben weiterzuverarbeiten. Die wohl wichtigsten sind &from für die Zeit und &format für die Formatierung der Daten.

 

Metrik “Baum”

Um die Werte für die CPU-Load abzufragen, muss der entsprechende Service in Icinga 2 definiert sein und Performance-Daten nach Graphite schreiben. Im Screenshot sieht man im Baum “services” – “load”, letzterer stellt den Service-Namen dar. Der Sub-Knoten “load” liefert die Information, dass hier das “load” CheckCommand verwendet wurde. Tip an dieser Stelle: Lässt sich etwa für Dashboard-Templates als eindeutiger Schlüssel verwenden in Grafana.

Performance-Daten liefern zum einen “perfdata”, worin einzelne Metriken mit ihrem Namen abgelegt werden, etwa “load1” und darunter “value” als Wert und Thresholds, etwa “crit” und “warn”, sofern definiert. Zusätzlich können auch Metadaten von Icinga 2 geschrieben werden, die man aber explizit in der Konfiguration einschalten muss (“metadata”).

 

Einzelne Metrik abfragen

Im folgenden interessiert uns aber lediglich der Wert der Metrik “load1” als einzelner Wert. Um eine ordentliche Ausgangsbasis zu erhalten, wählen wir den Zeitraum der letzten 3 Stunden. Tip: Es sind relative und absolute Zeitangaben möglich.

http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load1.value&height=800&width=600&from=-3hours

 

Mehrere Metriken zusammenfassen

Man kann diese Abfrage auch erweitern, indem man mehrere Werte gleichzeitig abfrägt:

http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.{load1,load15,load5}.value&height=800&width=600&from=-3hours

 

Mehrere Hosts mit der gleichen Metrik abfragen

Eine Abfrage mit verschiedenen Servern für “load15” als Metrik könnte so aussehen:

http://192.168.100.101/render?target=icinga2.icinga*op_foreman_local.services.load.load.perfdata.load15.value&height=800&width=600&from=-3hours

Formatierung

Die Darstellung der Daten setzt immer eine &height und eine &width als Parameter voraus. Es ist auch möglich hier Tortendiagramme mit verschiedenen Funktionen für Mittelwerte und Summen aufzurufen.

Man kann die erhaltenen Daten auch als CSV-Werte formatieren und dann beispielsweise mit curl abspeichern. Alternativ kann man sich diese Werte auch direkt im Browser anzeigen lassen.

[root@icinga1op ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=csv'

icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:30:00,0.24
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:31:00,0.21
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:32:00,0.17
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:33:00,0.15
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:34:00,0.16
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:35:00,0.13
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:36:00,0.12
....

Wie bereits erwähnt lassen sich die Daten auch im JSON-Format anzeigen. Dies kann wieder über den Browser oder mittels curl erfolgen.

Das folgende Beispiel rendert alle erhaltenen Datenpunkte als JSON-Format:

[root@icinga1op ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json'
[{"target": "icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value", "datapoints": [[0.13, 1497595140], [0.11, 1497595200], [0.15, 1497595260], [0.13, 1497595320], [0.1, 1497595380], [0.08, 1497595440], [0.07, 1497595500], [0.06, 1497595560], [0.06, 1497595620], [0.05, 1497595680], [0.04, 1497595740], [0.07, 1497595800], [0.05, 1497595860], [0.04, 1497595920], [0.05, 1497595980], [0.04, 1497596040], [0.08, 1497596100], [0.06, 1497596160], [0.07, 1497596220], [0.06, 1497596280], [0.06, 1497596340], [0.05, 1497596400], [0.04, 1497596460], [0.04, 1497596520], [0.03, 1497596580], [0.05, 1497596640], [0.04, 1497596700], [0.05, 1497596760], [0.04, 1497596820], [0.09, 1497596880], [0.07, 1497596940], [0.06, 1497597000], [0.06, 1497597060], [0.05, 1497597120], [0.04, 1497597180], [0.04, 1497597240], [0.03, 1497597300], [0.02, 1497597360], [0.02, 1497597420], [0.01, 1497597480], [0.01, 1497597540], [0.01, 1497597600], [0.01, 1497597660], [0.01, 1497597720], [0.01, 1497597780], [0.07, 1497597840], [0.06, 1497597900], [0.07, 1497597960], [0.08, 1497598020], [0.07, 1497598080], [0.06, 1497598140], [0.04, 1497598200], [0.04, 1497598260], [0.03, 1497598320], [0.14, 1497598380], [0.14, 1497598440], [0.13, 1497598500], [0.12, 1497598560], [0.1, 1497598620], [0.09, 1497598680], [0.09, 1497598740], [0.07, 1497598800], [0.06, 1497598860], [0.07, 1497598920], [0.1, 1497598980], [0.1, 1497599040], [0.08, 1497599100], [0.06, 1497599160], [0.05, 1497599220], [0.04, 1497599280], [0.04, 1497599340], [0.03, 1497599400], [0.02, 1497599460], [0.05, 1497599520], [0.04, 1497599580], [0.03, 1497599640], [0.03, 1497599700], [0.04, 1497599760], [0.05, 1497599820], [0.04, 1497599880], [0.04, 1497599940], [0.04, 1497600000], [0.04, 1497600060], [0.03, 1497600120], [0.03, 1497600180], [0.02, 1497600240], [0.01, 1497600300], [0.01, 1497600360], [0.01, 1497600420], [0.04, 1497600480], [0.04, 1497600540], [0.03, 1497600600], [0.03, 1497600660], [0.02, 1497600720], [0.04, 1497600780], [0.04, 1497600840], [0.03, 1497600900], [0.03, 1497600960], [0.02, 1497601020], [0.01, 1497601080], [0.01, 1497601140], [0.01, 1497601200], [0.01, 1497601260], [0.01, 1497601320], [0.01, 1497601380], [0.01, 1497601440], [0.01, 1497601500], [0.01, 1497601560], [0.01, 1497601620], [0.63, 1497601680], [1.29, 1497601740], [1.87, 1497601800], [2.4, 1497601860], [2.74, 1497601920], [2.36, 1497601980], [1.93, 1497602040], [1.58, 1497602100], [1.29, 1497602160], [1.7, 1497602220], [2.26, 1497602280], [2.77, 1497602340], [3.1, 1497602400], [3.37, 1497602460], [3.09, 1497602520], [2.56, 1497602580], [2.09, 1497602640], [1.71, 1497602700], [1.4, 1497602760], [1.16, 1497602820], [0.95, 1497602880], [0.78, 1497602940], [0.63, 1497603000], [0.52, 1497603060], [0.42, 1497603120], [0.35, 1497603180], [0.28, 1497603240], [0.23, 1497603300], [0.19, 1497603360], [0.16, 1497603420], [0.13, 1497603480], [0.12, 1497603540], [0.1, 1497603600], [0.08, 1497603660], [0.07, 1497603720], [0.05, 1497603780], [0.07, 1497603840], [0.06, 1497603900], [0.05, 1497603960], [0.04, 1497604020], [0.03, 1497604080], [0.03, 1497604140], [0.02, 1497604200], [0.02, 1497604260], [0.01, 1497604320], [0.01, 1497604380], [0.01, 1497604440], [0.01, 1497604500], [0.01, 1497604560], [0.01, 1497604620], [0.01, 1497604680], [0.01, 1497604740], [0.01, 1497604800], [0.01, 1497604860], [0.04, 1497604920], [0.05, 1497604980], [0.06, 1497605040], [0.08, 1497605100], [0.06, 1497605160], [0.07, 1497605220], [0.06, 1497605280], [0.04, 1497605340], [0.05, 1497605400], [0.04, 1497605460], [0.03, 1497605520], [0.03, 1497605580], [0.02, 1497605640], [0.02, 1497605700], [0.01, 1497605760], [0.01, 149760

Um die Daten leserlich in der Konsole aufzubereiten, empfiehlt es sich “python -m json.tool” als Formatierungshilfe zu verwenden.

curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json' | python -m json.tool

Um die JSON-Daten in der Console zu visualisieren kann man Zach Holman’s Spark verwenden:

[root@graphite ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json' | python -mjson.tool | grep ',' | grep -v '\]' | spark
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3695 0 3695 0 0 230k 0 --:--:-- --:--:-- --:--:-- 240k
▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▃▅▅▅▃▃▃▃▅▅███▅▅▃▃▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

 

Conclusio

Das war nur ein kleiner und rudimentärer Überblick was über die Render-API möglich ist. Jedoch bietet sie genügend Anregung um mehr mit Graphite, Icinga 2 und Metriken zu machen. Die Render-APi bietet zudem die Möglichkeit, programmatisch in Scripts darauf zuzugreifen. Mir hat es zumindest Lust auf mehr gemacht und ich denke, dass ich noch weitere Blogposts zu diesem Thema schreiben werde 🙂

Falls ihr nicht warten könnt, hier nochmal der Link zur Doku. Oder ihr schaut einfach mal bei uns in der Graphite-Schulung vorbei und lernt die Render-API am praktischen Beispiel kennen.

Daniel Neuberger

Autor: Daniel Neuberger

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das Netways Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Documentation matters or why OSMC made me write NSClient++ API docs

Last year I learned about the new HTTP API in NSClient++. I stumbled over it in a blog post with some details, but there were no docs. Instant thought “a software without docs is crap, throw it away”. I am a developer myself, and I know how hard it is to put your code and features into the right shape. And I am all for Open Source, so why not read the source code and reverse engineer the features.

I’ve found out many things, and decided to write a blog post about it. I just had no time, and the old NSClient++ documentation was written in ASCIIDoc. A format which isn’t easy to write, and requires a whole lot knowledge to format and generate readable previews. I skipped it, but I eagerly wanted to have API documentation. Not only for me when I want to look into NSClient++ API queries, but also for anyone out there.

 

Join the conversation

I met Michael at OSMC 2016 again, and we somehow managed to talk about NSClient++. “The development environment is tricky to setup”, I told him, “and I struggle with writing documentation patches in asciidoc.”. We especially talked about the API parts of the documentation I wanted to contribute.

So we made a deal: If I would write documentation for the NSClient++ API, Michael will go for Markdown as documentation format and convert everything else. Michael was way too fast in December and greeted me with shiny Markdown. I wasn’t ready for it, and time goes by. Lately I have been reviewing Jean’s check_nscp_api plugin to finally release it in Icinga 2 v2.7. And so I looked into NSClient++, its API and my longstanding TODO again.

Documentation provides facts and ideally you can walk from top to down, and an API provides so many things to tell. The NSClient API has a bonus: It renders a web interface in your browser too. While thinking about the documentation structure, I could play around with the queries, online configuration and what not.

 

Write and test documentation

Markdown is a markup language. You’ll not only put static text into it, but also use certain patterns and structures to render it in a beautiful representation, just like HTML.

A common approach to render Markdown is seen on GitHub who enriched the original specification and created “GitHub flavoured Markdown“. You can easily edit the documentation online on GitHub and render a preview. Once work is done, you send a pull request in couple of clicks. Very easy 🙂

If you are planning to write a massive amount of documentation with many images added, a local checkout of the git repository and your favourite editor comes in handy. vim handles markdown syntax highlighting already. If you have seen GitHub’s Atom editor, you probably know it has many plugins and features. One of them is to highlight Markdown syntax and to provide a live preview. If you want to do it in your browser, switch to dillinger.io.

NSClient++ uses MKDocs for rendering and building docs. You can start an mkdocs instance locally and test your edits “live”, as you would see them on https://docs.nsclient.org.

Since you always need someone who guides you, the first PR I sent over to Michael was exactly to highlight MKDocs inside the README.md 🙂

 

Already have a solution in mind?

Open the documentation and enhance it. Fix a typo even and help the developers and community members. Don’t move into blaming the developer, that just makes you feel bad. Don’t just wait until someone else will fix it. Not many people love to write documentation.

I kept writing blog posts and wiki articles as my own documentation for things I found over the years. I once stopped with GitHub and Markdown and decided to push my knowledge upstream. Every time I visit the Grafana module for Icinga Web 2 for example, I can use the docs to copy paste configs. Guess what my first contribution to this community project was? 🙂

I gave my word to Michael, and you’ll see how easy it is to write docs for NSClient++ – PR #4.

 

Lessions learned

Documentation is different from writing a book or an article in a magazine. Take the Icinga 2 book as an example: It provides many hints, hides unnecessary facts and pushes you into a story about a company and which services to monitor. This is more focussed on the problem the reader will be solving. That does not mean that pure documentation can’t be easy to read, but still it requires more attention and your desire to try things.

You can extend the knowledge from reading documentation by moving into training sessions or workshops. It’s a good feeling when you discuss the things you’ve just learned at, or having a G&T in the evening. A special flow – which I cannot really describe – happens during OSMC workshops and hackathons or at an Icinga Camp near you. I always have the feeling that I’ve solved so many questions in so little time. That’s more than I could ever write into a documentation chapter or into a thread over at monitoring-portal.org 🙂

Still, I love to write and enhance documentation. This is the initial kickoff for any howto, training or workshop which might follow. We’re making our life so much easier when things are not asked five times, but they’re visible and available as URL somewhere. I’d like to encourage everyone out there to feel the same about documentation.

 

Conclusion

Ever thought about “ah, that is missing” and then forgot to tell anyone? Practice a little and get used to GitHub documentation edits, Atom, vim, MkDocs. Adopt that into your workflow and give something back to your open source project heroes. Marianne is doing great with Icinga 2 documentation already! Once your patch gets merged, that’s pure energy, I tell you 🙂

I’m looking forward to meet Michael at OSMC 2017 again and we will have a G&T together for sure. Oh, Michael, btw – you still need to join your Call for Papers. Could it be something about the API with a link to the newly written docs in the slides please? 🙂

PS: Ask my colleagues here at NETWAYS about customer documentation I keep writing. It simply avoids to explain every little detail in mails, tickets and whatnot. Reduce the stress level and make everyone happy with awesome documentation. That’s my spirit 🙂

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 😉

PHP Error – php_network_getaddresses

Ein Problem zu dem es viele Lösungsansätze gibt, ist folgender PHP Fehler. Er tritt beispielsweise auf, beim Verbinden auf externe Anwendungen oder APIs:
php_network_getaddresses: getaddrinfo failed: No address associated with hostname

Im Netz kursieren Teilweise die wildesten Lösungsansätze. Da ich vor kurzem mit eben diesem Problem konfrontiert wurde, möchte ich meine Erfahrung mit euch teilen. In der “php.ini” gibt es einen Parameter, der diesen Fehler verursachen kann.

Dieser kann unterschiedlich gefüllt sein und ist per default leer.

disable_functions = pcntl_alarm,pcntl_fork,,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,,pcntl_signal,,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,,pcntl_exec,pcntl_getpriority,pcntl_setpriority

Um obigen Fehler zu beheben, kann es also reichen, sich diesen Parameter anzusehen und notfalls sogar komplett zu leeren.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Open Source Backup Conference 2017 – Why Backup is so important!

What would you do if your access  of all your electronic data is completely locked?  You’d be a little bit annoyed, it was a trojan who encrypted your files?
Those, who have a backup yet do not have this problem and will smile about it!

BACKUP IS IMPORTANT FOR ALL OF US!
Come and visit the Open Source Backup Conference in Cologne from September 25 to 26.
Two days full of the latest trends and developments regarding Backup strategies with open source software!
Two talks are already confirmed.

  1. Didac Oliveira from Brain Updaters, SLL will visit us in Cologne with his talk on Smart GNU/LINUX Disaster Recovery Management with DRLM&REAR. 
  2. Maik Aussendorf from BAREOS will give an insight in the new BAREOS Roadmap 17.2.
    Among others, it includes database backend rewrite, performance enhancements for large installations on database level, NDMP Enhancements, an Amazon S3 Storage Backend and lots of other improvements concerning usability and more languages.

 

More talks will be online soon on www.osbconf.org.

Besides the expert talks, three workshops are also offered on „Puppet“, “Scripting BAREOS“ and „BAREOS Introduction“.

The call for papers is running until June 30! Submit your presentation via the cfp-form on www.osbconf.org. The Early Bird Tickets are also available until the end of June.

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.

Azubi-Projektwoche: ein ‘voller’ Erfolg

Ein neues Experiment aus dem Hause NETWAYS ist in der Woche vom 06.06. – 09.06.2017 angerollt: die Azubi-Projektwoche.
Dafür werden einmal im Jahr für eine Woche alle unsere Azubis eingesammelt und in unser Trainingszentrum, dem Kesselhaus, abgeladen.

Wir hatten nur wenige Vorgaben was genau wir fabrizieren sollten, nur dass wir innerhalb einer Woche, mit einem Budget von 500€ ein kleines unabhängiges Projekt auf die Beine stellen und das dann am Freitag Nachmittag präsentieren sollen.
Unsere 8 Mann starke Truppe, bestehend aus Nicole, Noah, Ufuk, Gabriel, Alexander, Andreas, Lukas und mir, hat am Dienstag zunächst das Kesselhaus bezogen, voller Elan und Motivation. Der erste Punkt auf der Tagesordnung war einen Gruppenleiter zu wählen, was auch recht schnell getan war, so musste Andreas für den Rest der Woche unsere Gruppe managen und drauf achten, dass Alles so läuft wie geplant.

Dann musste noch überlegt werden, was denn nun eigentlich in dieser Woche geschafft werden soll. Komplett ohne Vorgaben ein Thema zu finden ist nicht leicht, vor allem Eines, bei dem sich alle Teammitglieder die gesamte Zeit sinnvoll einbringen können und ihre Fähigkeiten nutzen.

Hier sieht man das Team beim Brainstormen

Diese Idee sollte  alle unsere selbst gestellten Ansprüche vereinigen: technisch sollte es sein, aber auch etwas zu Handwerken. Etwas nützliches, was auch öfters als nur einmal verwendet werden kann. Etwas was zu Netways passt, aber nichts mit IT zu tun hat. Etwas was bei den Kollegen Anklang findet. – Kurz gesagt, irgendwas cooles.

Unsere Überlegung starteten mit ‘Lasst uns ein Holzhaus bauen!’, über einen fahrbaren Eisstand, bis hin zu unserer Finalen Idee: eine fahrbare Bar, die per Knopfdruck Getränke mischen kann.

Nachdem wir uns auf das Thema geeinigt hatten, teilten wir uns in verschiedene Teams auf: Das Entwicklungs-Team kümmerte sich um die Knopfdruck-Mischtechnik, das Produktions-Team um das Zusammenschrauben der Bar selbst, Das Präsentations-Team (was eher Part-time aus Mitgliedern der erstgenannten beiden bestand) kümmerte sich um Foto- und Filmdokumentation und die Abschlusspräsentation für die Firma und das letzte ‘Team’ war die Ein-Mann-Truppe Lukas, der sich um die Getränke und das Cocktail-Kochbuch gekümmert hat.

Und dann ging die eigentliche Arbeit los:

DAY 1:

Entwicklungs-Team:

Die ersten Gehversuche mit der eben gekauften Elektronik

Noah, Alexander und Ufuk haben sich Gedanken gemacht, wie die Mischtechnik aufgebaut werden sollte. Es stellte sich relativ schnell heraus, dass Modellbau-Pumpen am besten geeignet sind Flüssigkeiten zu transportieren und die Getränke zu mischen. Ein Arduino UNO zur Steuerung der Pumpen war der beste Kompromiss aus technischen Möglichkeiten und Kosteneffizienz. Da dieser aber den Pumpen bei weitem nicht genug Strom bieten konnte, sah sich das Team gezwungen eine elektronische Verstärker-Schaltung zu entwerfen. Hier hat sich das Fachwissen aus dem Physik-Unterricht von Noah und aus dem stillen Kämmerlein von Alexander bezahlt gemacht. Nachdem die Planung abgeschlossen war und die Entscheidungen über die Technik gefallen waren, ging es sofort zum Technikgeschäft, wo alle benötigten Teile (von Kabeln über Steckbretter und Netzteile bis hin zu Modelbaupumpen) vorhanden waren. Da, trotz Interesse in dem Bereich, Niemand aus dem Team wirklich viel Erfahrung mit Elektrotechnik und Mikrocontroller (Arduino) hatte, widmete sich die Gruppe den restlichen Tag dem Verstehen und Ausprobieren.

Produktions-Team:
Nicole und ich hatten uns damit auseinandergesetzt, was für ein Design wir anstreben wollen, was wir dafür an Materialien benötigen und wie viel das uns in etwa kosten würde.Danach verbrachten wir einige Zeit mit der millimetergenauen Planung der Bar-Maße, was sich als ein ziemlich schwieriges Unterfangen herausstellte. Wir wollten sowohl ein ansprechendes Design, als auch Stabilität vereinen, was ziemlich schwierig ist, wenn alle Erfahrungen in dem Bereich vom ‘Zuschauen bei Anderen’ stammen. Die Wahl des Holzes war leider auch etwas durch das Budget limitiert, so fiel unsere Entscheidung auf 16mm Spanplatten für die Außenwände und eine Restholz-Küchenplatte für die Arbeitsfläche. Mit etwa 120€ für Holz, Farbe und Kleinkram waren wir mit unserem Kostenvoranschlag trotzdem noch gut im Rahmen. Zu guter letzt sind wir in den nächsten Baumarkt gefahren um uns die benötigten Spanplatten zuschneiden zu lassen, Beratung über lebensmittelechten Lack zu bekommen und alle möglichen benötigten Kleinteile zu besorgen.

Planung und Konzeption

Präsentations-Team:
Ufuk und Gabriel entschieden sich die Arbeitsabläufe der darauffolgenden Tage mit Foto- und Filmaufnahmen festzuhalten und einen kurzen Film daraus zusammen zu schneiden. Ufuk bot hierfür seinen Laptop an, da er ein professionelles Videoschnittprogramm (Final Cut Pro X) darauf installiert hat. Gabriel schlug vor, dass er seine Spiegelreflexkamera für die Aufnahmen mitnehmen könnte. Am ersten Tag entstanden leider nur wenige Aufnahmen, da das Equipment dafür noch nicht vor Ort war. Gabriel filmte notdürftig ein paar kurze Clips von den Einkäufen mit seinem Handy.
Andreas wimmelte nur so zwischen den Gruppen hin und her um potentielle Konflikte sofort zu verhindern und schon mal Informationen für die Abschlusspräsentation zu sammeln.

Getränke-Team:
Lukas hat sich am ersten Tag damit beschäftigt zu recherchieren was für Cocktails für unsere Bar denn so wünschenswert wären und sich Gedanken gemacht, wie denn unser Cocktail-Kochbuch so aussehen könnte.

DAY 2:

Entwicklungs-Team:
Durch die Tests und Erfahrungen vom Vortag gestärkt, fing dieser Tag direkt mit Schaltung auf dem Breadboard(Steckbrett) zusammenzustecken und testen an. Leider stieß die Truppe gegen Nachmittag auf das Problem, dass eines der Bauteile (das Darlington Transitor-Array um genau zu sein) sehr warm wurde und teilweise nicht mehr funktionierte. Die Vermutung war, dass die Temperatur um weiten zu hoch waren.Nach einem genauen Blick in die Dokumentation dieses Bauteils fiel auf, dass es nur für maximal 0,5A geeignet war, das Netzteil jedoch 3,5A Spannung lieferte. Nach gründlicher Recherche wurde das Transitor Array durch einzelne High Current Transistoren ersetzt. Ein erneuter Besuch beim Händler stand an und so wurde die Schaltung nocheinmal komplett umgebaut, um den neuen Transitoren gerecht zu werden. Alle folgenden Tests verliefen erfolgreich.

Der orange Lack lässt noch das Holz-Muster durchblicken

Produktions-Team:
Am zweiten Tag hatten wir nun auch alle benötigten Werkzeuge (Akkuschrauber, Stichsäge, Pinsel und Rollen) zur Verfügung und haben uns sofort daran gemacht die Bar zusammen zu schrauben. Dabei haben wir festgestellt, dass es gar nicht so leicht ist wie es immer aussieht eine Schraube gerade in das Holz zu treiben (wir sind trotzdem fest davon Überzeugt, dass auch die Tatsache, dass wir Spanplatten verwendeten Mitschuld an den krummen Schrauben hat). Innerhalb kurzer Zeit stand das Grundgerüst der Bar und wurde in schickem NETWAYS-Orange bemalt. Wir sägten ein rundes Loch für eine Waschwanne (zum Abspülen von Getränken) in die Arbeitsplatte und stellten fest, dass die Beschichtung sich nicht besonders gut abschleifen lässt. Schnell waren ein paar Grifflöcher hinzugekommen um die abgeplatzte Lackierung zu kaschieren.

Immer unterwegs

Präsentations-Team:
Ufuk brachte seinen Laptop mit und richtete auf diesem das Filmprojekt ein und Gabriel begann mit den Filmaufnahmen. Als er nach der ersten Stunde die Aufnahmen auf den Laptop überspielen wollte, erlitt die SD-Speicherkarte einen Defekt. Sehr schade, denn somit waren ein paar schöne Aufnahmen vom Zusammenbau der ersten Elemente des Cocktailstandes verloren. Nachdem eine weitere SD-Karte besorgt war ging es weiter. Ufuk begann mit dem Schnitt des Filmes. Er suchte eine passende Schriftart für den Titel heraus und begann mit der Auswahl passender Videoclips. Währenddessen filmte und fotografierte Gabriel die Arbeit der anderen Azubis. Gabriel filmte und fotografierte dann weiter. Mehr als ein schnelles, verschwommenes Handy-Foto gibt es natürlich nicht von dem Mann hinter der Kamera.

Getränke-Team: Lucas hat ein kleines Cocktail Kochbuch zusammengestellt, gedruckt und gebunden, welches am Ende als Inspiration auf der Arbeitsfläche liegen sollte. Aufgrund der relativ geringen Anzahl der Pumpen musste nochmal umdisponiert werden, was die angebotenen Getränke angeht, also einigten sich alle Teams auf eine Umdisponierung auf Longdrinks statt Cocktails.

DAY 3:

Entwicklungs-Team:
Am dritten Tag war dank unseren neuen Transistoren die Pumpensteuerung größtenteils fertig und es fehlte nur noch die Steuerung mittels Knöpfen. Dieser Teil der Arbeit gelang relativ schnell, weshalb sich das Team dann dem Schreiben unseres Programmcodes für den Arduino hingab. Der Arduino sollte später die Pumpen so steuern, dass diese Cocktails und Longdrinks auf den Centiliter genau zusammenmischt werden. Um unseren Programmcode richtig schreiben zu können, musste wir jedoch vorerst messen, wie lange eine Pumpe braucht und einen bestimmte Menge an Flüssigkeit zu transportieren. Am Ende des Tages funktionierte unser System nahezu perfekt und nun musste es nur noch in unsere Bar eingebaut werden und die Mischverhältnisse für die Drinks eingestellt werden.

Die sorgfältig gesteckten Kabel auf dem Breadboard

Produktions-Team:
Wir machten uns an die grobe Fertigstellung der Bar. Dazu mussten sowohl Rollen auf der Unterseite angebracht werden als auch Griffe an den Längs-Enden um die Bar mobil zu machen. Des Weiteren wurden in Absprache mit dem Entwicklungs-Team die Öffnungen für die Elektronik und die Schläuche gebohrt. Die Bohrlöcher mussten nochmal mit Lackfarbe nachgebessert werden, da die Position der Löcher erst mit Ausreifung der Elektronik gesetzt werden konnten. Des Weiteren hatten wir bei den Transportgriffen auf einen anderen Schraubentyp umdisponiert, weshalb unser Teil der Gruppe nochmals den Baumarkt aufsuchen musste. Dort füllten wir den Einkaufswagen auch mit Deko-Artikeln. Die letzten Stunden des Tages verbrachten Nicole und Gabriel mit dem Einsatz der neuen Schrauben und ich schmückte ein Rankgitter, das hinter der Arbeitsfläche angebracht wurde um zu verhindern, dass die Flaschen einen Abflug nach hinten machen.

Präsentations-Team:
Ufuk und Gabriel schauten sich gemeinsam die geschnittenen Aufnahmen des Vortags an und begannen damit, die Schnitte bzw. Übergänge zwischen den einzelnen Clips an den Takt des unterliegenden Liedes anzupassen.

DAY 4:

Die Schläuche werden auf gleiche länge gestutzt und zusammen gebunden, damit sie bequem in ein Glas reichen

Entwicklungs-Team:
Da das System größtenteils funktionierte, kümmerten sich das Team nun darum, den Arduino samt Knöpfen, Pumpen und Schaltung in die fertige Bar einzubauen und die Pumpschläuche auf diese zuzuschneiden. Danach folgten einige Probedurchläufe mit Wasser, das Einstellen der Drinks und später einige Durchläufe mit den vorgesehenen Getränken. Hier stießen sie auf das Problem, dass Getränke mit Kohlensäure, durch die Luftbläschen langsamer gepumpt werden als andere, weshalb die Mischverhältnisse ein wenig überarbeitet werden mussten. Nach kurzer Kalibrierung und Testing funktionierte alles einwandfrei und die Technik stand.

Traube-Käse, Olive-Brot und später noch Tomate-Mozzarella

Produktions-Team:
Am letzten Tag wurden unter Zeitdruck noch die letzten Löcher gebohrt, Macken zulackiert und die verbleibenden Dekorationen angebracht, bis dann die Bar selbst vollendet war. Danach fuhr Nicole noch einmal mit Gabriel zum Einkaufen los, diesmal aber nicht in den Baumarkt sondern in diverse Supermärkte, damit wir zur Präsentation auch Häppchen zu den Getränken anbieten konnten.

Wir hatten auch noch sehr viel Spaß mit unserem Label-Drucker und gaben unserer Bar auch noch einen Ikea-Namen

Präsentations-Team:
Auch an diesem Tag filmte Gabriel die Arbeitsabläufe der anderen Azubis. Ursprünglich hatten Ufuk und er geplant, das fertige Produkt am Ende des Filmes in Szene zu setzen. Dieser Plan konnte allerdings nicht umgesetzt werden, da bis zur Präsentation zu wenig Zeit blieb und der Cocktailstand erst in der letzten Stunde komplett fertiggestellt wurde. Ufuk kümmerte sich um die Texte für den Abspann und suchte weitere Clips heraus. Anschließend gingen er und Gabriel den Film ein weiteres mal durch. Dabei stellten sie fest, dass viele Schnitte nicht mehr zum Lied passten. Innerhalb von wenigen verbleibenden Minuten musste das gesamte Projekt nochmal an die Musik angepasst werden. Glücklicherweise gelang dies noch rechtzeitig vor Beginn der Präsentation.

Getränke-Team:
Lucas stellte in zusammenarbeit mit den anderen Teams zusammen die Longdrink Rezepte fertig und stellte die gekauften Getränkeflaschen. Er half beim dekorieren der Bar und testete die Mischverhältnisse der von der Maschine ausgespuckten Getränke. Nebenbei half er auch bei der Fertigstellung der Präsentation.

Der erste Testkandidat wird bedient

Die Abschlusspräsentation war auch ein ‘voller’ Erfolg. Andreas stellte die Teams vor und erzählte kurz über die Entstehung des Projekts, danach zeigten wir den von Gabriel und Ufuk erstellten Film. Abschließend erklärten Noah und ich nochmal die Funktionsweise der Bar am Objekt selbst und dann durfte jeder mal testen wie die so funktioniert. Innerhalb von 3 Minuten musste jedes Getränk einmal aufgefüllt werden, kein Wunder bei der etwa 30 Mann starken Besuchertruppe bestehend aus NETWAYS Personal.

 

 

 

Die Häppchen wurden ebenfalls verputzt und es wurden bereits wilde Theorien gesponnen, wie die Bar noch weiterhin verbessert werden soll, und wann denn die Produktion in Serie gehen soll.

Andrang an der eröffneten Bar

Bernd als selbsternannter Häppchen-Service

 

 

 

 

 

 

 

 

 

Zusammengefasst:
Die Woche hat uns Allen viel gebracht, sowohl für unsere Ausbildung als auch fürs Leben.
Wir haben gelernt Projekte als Team anzugehen, Probleme zu lösen, haben unseren Horizont erweitert, verborgende Talente in uns und unseren Kollegen entdeckt und hatte dabei noch unglaublich viel Spaß.
Unsere Hoffnung, dass unser Projekt gut bei den anderen NETWAYSianern ankommt hat sich auch bewahrheitet und das Experiment “Azubi-Projektwoche” war geglückt.

Wir freuen uns schon auf das Projekt im nächsten Jahr!

 

 

 

Dieser Text entstand in Zusammenarbeit der Teams.
Fotos von Gabriel, Gunnar und mir.

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer hat sich nach Ihrem Abitur erst einmal die große weite Welt angesehen, ehe es sie für Ihre Ausbildung zur Fachinformatikerin für Anwendungsentwicklung ab September 2016 nach Nürnberg zu NETWAYS verschlagen hat. Die Lieblingsfreizeitaktivitäten der gebürtigen Steigerwalderin sind das Zocken, Bouldern und sich mit Freunden und Kollegen auf gemütliche Spiele- und Filmabende zu treffen.