Aus Linux-Magazin 11/2024

Anwendungen lückenlos überwachen per End-to-End Monitoring

© Roman Samborskyi / 123RF.com

Der Webserver läuft laut Nagios einwandfrei – aber liefert er auch flott ein fehlerfrei funktionierendes WordPress aus? Solche Fragen beantwortet das End-to-End Monitoring.

Alle Systeme arbeiten normal, und trotzdem hat seit gestern Nachmittag kaum jemand im Online-Shop eine Bestellung aufgegeben. Erst eine mühsame manuelle Untersuchung ergibt, dass der Warenkorb eine quälend lange Bedenkzeit braucht, um zur Kasse weiterzuleiten – das Problem verursacht ein durcheinander geratener Cache. Solche fiesen Fehler richten schnell teure Schäden an, gehen den klassischen Monitoring-Lösungen allerdings häufig durch die Lappen. Die prüfen lediglich, ob der Webserver nebst PHP läuft, nicht aber, ob die ausgelieferte Webanwendung immer noch einwandfrei und vor allem zackig funktioniert. Dazu benötigen Sie eine spezielle Monitoring-Lösung.

Eine solche beobachtet alle realen Nutzer dabei, wie sie den Warenkorb befüllen und an der Kasse bezahlen. Alternativ oder ergänzend schlüpft sie in die Rolle eines echten Kunden und ruft kurzerhand selbst regelmäßig wichtige Funktionen auf. So durchläuft das Monitoring beispielsweise einen kompletten Bestellvorgang im Online-Shop oder meldet sich als Autor in einem Blog an. In jedem Fall stoppt das Werkzeug die für einen Vorgang benötigte Zeit. Auf diese Weise erfahren Sie nicht nur, ob das Responsive Design auf Smartphones versehentlich wichtige Bedienelemente ausblendet, sondern auch, ob die Anmeldung im Online-Shop urplötzlich mehrere Minuten Bedenkzeit verstreichen lässt.

Im Gegensatz zum klassischen Infrastruktur- beziehungsweise System-Monitoring überwachen solche Tools kontinuierlich die Softwarequalität – und zwar aus der Sicht der Nutzer. Die Monitoring-Werkzeuge prüfen dabei automatisch sämtliche im Hintergrund beteiligten Komponenten, angefangen bei der Datenbank bis hin zur Benutzeroberfläche am anderen Ende. Deswegen spricht man von End-to-End-Monitoring (Abbildung 1) oder kurz E2E-Monitoring. Vorwiegend kommt diese Art der Überwachung bei Webanwendungen zum Einsatz, sie lässt sich jedoch ebenso gut bei nativen (Linux-)Programmen und Smartphone-Apps anwenden. E2E-Monitoring eignet sich sogar für Anwendungen ohne grafische Benutzeroberfläche: Stehen die Dienste etwa über eine REST-API bereit, nimmt eine entsprechende Monitoring-Lösung sie über ihre Endpunkte unter die Lupe.

Abbildung 1: Das E2E-Monitoring beobachtet die Nutzer (Real User Monitoring) und simuliert regelmäßig deren typische Aktionen (Synthetic Monitoring). Die dabei gewonnenen Informationen und Performance-Werte ergänzen das herkömmliche Uptime-Monitoring.

Abbildung 1: Das E2E-Monitoring beobachtet die Nutzer (Real User Monitoring) und simuliert regelmäßig deren typische Aktionen (Synthetic Monitoring). Die dabei gewonnenen Informationen und Performance-Werte ergänzen das herkömmliche Uptime-Monitoring.

Begriffswirrwarr

End-to-End-Monitoring ist zwar ein gängiger Begriff, das Konzept firmiert aber auch gern unter anderen Bezeichnungen wie End User Monitoring (EUM), End User Experience Monitoring (EUXM), App Monitoring, Application Performance Management (APM) und Chain Monitoring.

Die Begriffe beziehen sich allerdings eigentlich nur auf jeweils einen Aspekt ds End-to-End-Monitorings: Während das Application Performance Management ausschließlich Geschwindigkeitsmessungen bis hinunter auf die Code-Ebene in den Vordergrund stellt, prüft das End User Monitoring, wie gut und schnell die Benutzeroberfläche aus Sicht der Anwender funktioniert. Sowohl das EUM als auch das im Artikel angesprochene Real User Monitoring können daher gleichzeitig ein Teil des APM sein. Mit dem wiederum verwandt ist das Application Response Time Monitoring, das die Reaktionszeit einer Anwendung misst. Das Chain Monitoring beobachtet ein System aus mehreren Komponenten, etwa einen LAMP-Stack, der WordPress ausliefert.

End-to-End-Monitoring vereint die Ansätze: Eine entsprechende Monitoring-Lösung misst die Performance und Qualität einer kompletten Anwendung aus Nutzersicht (oder neudeutsch: am Point of Customer Contact). Als Synonym findet sich mitunter Digital Experience Monitoring (DEM). Im Internet und in der Literatur werden jedoch sämtliche Begriffe gern durcheinandergewürfelt und schwammig verwendet. Die Marketing-Abteilungen tun ein Übriges, um das Begriffswirrwarr zu komplettieren.

Keine Zeit!

Reagiert der Warenkorb sehr träge, brechen entnervte Kunden den Bestellvorgang irgendwann ab. Administratoren wiederum möchten wissen, ob die Software in ihren Containern und virtuellen Maschinen gerade am Limit arbeitet. Und nicht bloß Banken müssen gegenüber ihren Kunden zwingend vorgegebene Transaktionszeiten einhalten. Deswegen gelten die von einem E2E-Monitoring ermittelten Geschwindigkeiten und Reaktionszeiten als besonders wertvolle Informationen. Die ermittelten Performance-Daten geben der Entwicklungsabteilung die Möglichkeit, ganz gezielt das Reaktionsverhalten des Warenkorbs zu perfektionieren. Administratoren können die gerade tatsächlich benötigte Rechenleistung buchen und so das Capacity Planning optimieren. Obendrein finden sie schnell heraus, ob gebuchte Cloud-Dienste oder genutzte Software-as-a-Service-Dienste (SaaS) tatsächlich die eigene Anwendung ausbremsen.

Eine E2E-Monitoring-Lösung überwacht die Anwendung periodisch und protokolliert die dabei ermittelten Reaktionszeiten. Mit den produzierten Reports lässt sich die Einhaltung eines Service Level Agreements (SLA) gegenüber einem Kunden belegen. Gleichzeitig erlauben die Protokolle einen Blick in die Zukunft: Geht beispielsweise nach 15:00 Uhr die Performance des Warenkorbs kontinuierlich in die Knie, lässt sich anhand einer passenden Hochrechnung kurzerhand ablesen, wann der Warenkorb gar nicht mehr reagieren wird. Entwickler und Administratoren können so rechtzeitig Maßnahmen ergreifen und das Schlimmste verhindern. Ein E2E-Monitoring identifiziert folglich frühzeitig Schwachstellen selbst in komplexen Komponenten und hilft dabei, einem Störfall vorzubeugen.

Real User Monitoring

Um an die Performance-Daten zu kommen, beobachtet ein E2E-Monitoring die echten Nutzer bei ihrem Weg durch den Bestellprozess. Dabei misst das Monitoring-Werkzeug die Geschwindigkeit der einzelnen Aktionen und verzeichnet auftretende Probleme. Das Vorgehen heißt Real User Monitoring (RUM). Da eine entsprechende Software ausschließlich die Abläufe im Blick behält und nicht selbst tätig wird, handelt es sich bei diesem Vorgehen um ein passives Monitoring.

Im Idealfall erfolgen die Messungen in Echtzeit, womit sich ein passendes Monitoring-Werkzeug zum Beobachten kritischer Dienste empfiehlt. Als äußerst hilfreich erweist sich ein RUM bei der Analyse von Marketing-Kampagnen. So können Sie anhand der Messwerte genau sehen, was der sagenhafte Rabatt auf rote Wollknäuel auslöst, wo sich plötzlich im Online-Shop Staus bilden und wie die Kunden auf das Angebot reagieren. Anhand der Daten lässt sich der Online-Shop dann gezielt für künftige Kampagnen vorbereiten.

Im Maßen genießen

Aufgrund seiner Arbeitsweise erzeugt das RUM überaus flott große Datenmengen. Die erlauben zwar eine detaillierte Analyse der Probleme und der Performance, die Auswertung dagegen gestaltet sich alles andere als trivial. In der Regel definieren Sie deshalb Messpunkte an wichtigen Stellen innerhalb der Anwendung. Die Software muss dann nicht jeden Mausklick im Warenkorb festhalten, sondern beispielsweise nur die Zeit von seinem Aufruf bis zum Bezahlvorgang stoppen. Insbesondere wenn im Hintergrund viele Microservices agieren, schmuggeln sich außerdem oft unzählige unwichtige Informationen in die Messdaten. Dieses Rauschen (Noise) verfälscht die Analysen. Dementsprechend müssen Sie versuchen, durch geschickt gewählt Messpunkte sowie weitere Maßnahmen den Noise zu reduzieren. Je nach Infrastruktur und Anwendung fällt das Einrichten eines RUM also relativ aufwendig aus – und es gibt noch andere Probleme.

Das RUM verfolgt die Nutzer durch die Anwendung, was unweigerlich ein Datenschutzproblem aufwirft. Ein entsprechendes Monitoring muss deswegen zwingend anonym erfolgen. Zudem deckt das RUM nicht alle möglichen Aktionen und Funktionen einer Anwendung ab. So müssen Sie zum Beispiel abwarten, bis ein Nutzer mit Kreditkarte bezahlt, um auf Performance-Probleme mit dem Zahlungsdienstleister zu stoßen. Obendrein entdeckt ein RUM ein Problem erst, wenn das Kind schon im Brunnen liegt und der potenzielle Kunde vor dem nicht mehr funktionierenden Warenkorb steht.

Integrationsprobleme

Ein RUM muss zudem irgendwie mitbekommen, wann ein Nutzer eine relevante Aktion auslöst. Das gelingt nur, wenn die Anwendung darauf entsprechend vorbereitet ist oder man direkt im Quellcode an den passenden Punkten geeignete Überwachungsfunktionen einbauen kann. Dazu stellen die Entwickler der Monitoring-Lösungen vielfach ein Software Development Kit bereit. Bei Webanwendungen müssen die Messungen im Browser der Nutzer laufen. Meist übernimmt das ein eingeschleuster Javascript-Schnipsel (Abbildung 2). Ad-Blocker und andere Schutzmaßnahmen können die Messungen dort allerdings verhindern oder sogar verfälschen.

Abbildung 2: Grafana Faro besteht aus einem Javascript-Agenten, den Sie in die eigene Webanwendung integrieren und der die beobachteten Daten auf einem Grafana-Stack ablegt.

Abbildung 2: Grafana Faro besteht aus einem Javascript-Agenten, den Sie in die eigene Webanwendung integrieren und der die beobachteten Daten auf einem Grafana-Stack ablegt.

Auf dem Markt tummeln sich kaum RUM-Werkzeuge unter einer Open-Source-Lizenz. Besonders populär dürfte Grafana Faro sein, das sich allerdings auf Webanwendungen konzentriert [1]. Eine Alternative (Abbildung 3) findet sich in BasicRUM [2]. Deswegen sollten Sie gerade bei nativen Linux-Anwendungen ernsthaft überlegen, selbst Funktionen zur Telemetriedatenerhebung zu implementieren beziehungsweise entsprechende Telemetriedatenbibliotheken einzubinden. Immerhin kennen Sie die eigene Anwendung am besten und können die Messwerte an ein eventuell schon laufendes Monitoring-Backend wie den Grafana-Stack weiterleiten. Für Go-Programme gibt es beispielsweise die Bibliothek OpenTelemetry-Go [3], die Performance- und andere Metriken gemäß OpenTelemetry-Standard erhebt und an dazu kompatible Analyseplattformen schickt.

Abbildung 3: BasicRUM spannt einige bekannte Komponenten wie BoomerangJS zur Datenerfassung und Grafana zur Datenspeicherung ein.

Abbildung 3: BasicRUM spannt einige bekannte Komponenten wie BoomerangJS zur Datenerfassung und Grafana zur Datenspeicherung ein.

Beim Monitoring einer Drittanbietersoftware hat man nur selten den Quellcode parat. In diesem Fall muss die Monitoring-Anwendung ähnlich wie eine Spionagesoftware die auf dem Bildschirm des Nutzers angezeigte Benutzeroberfläche analysieren und beispielsweise mithilfe von OCR alle Texte erkennen. Das Verfahren ist jedoch fehlerhaft und liefert keine exakten Performance-Werte. Allerdings lässt sich dieses Problem recht elegant umgehen.

Synthetic Monitoring

Ein E2E-Monitoring kann sich wie ein echter Nutzer verhalten und sich auf einem vorgegebenen Pfad durch die Anwendung klicken. Beispielsweise könnten Sie das Monitoring-Werkzeug anweisen, den Online-Shop im Browser aufzurufen, rechts oben in der Ecke auf Registrieren zu klicken und schließlich in die beiden Felder einen Benutzernamen und ein Passwort einzutippen. Zusammen mit weiteren derartigen Aktionen simuliert eine entsprechende Monitoring-Software die zu erwartenden Besucherströme auf der Seite.

Dieses Vorgehen heißt Synthetic Monitoring. Der Begriff Synthetic verdeutlicht, dass die Monitoring-Software keine echten, sondern fest vorgegebene Anfragen an die Anwendung stellt. Da das Monitoring-System mit der Anwendung interagiert, gehört das Verfahren zum aktiven Monitoring. Das Synthetic Monitoring sieht die Anwendung stets als Black Box, kann also nicht am Benutzerinterface vorbei auf andere Teile zugreifen und beispielsweise in der Datenbank direkt Änderungen vornehmen.

Spiel’s noch einmal

Beim Synthetic Monitoring kennt man sowohl die Eingaben als auch die dazu passenden Ausgaben. Zum Beispiel sollte nach der Anmeldung im Online-Shop wieder die Startseite erscheinen. Eine passendes Monitoring kann folglich direkt feststellen, ob das reale Verhalten vom gewünschten abweicht, und gezielt Fehler in der Anwendung melden. Darüber hinaus lassen sich mehrere Durchläufe durch den Warenkorb miteinander vergleichen. Das ist vor allem bei Performance-Messungen nützlich. So lässt sich schnell ermitteln, ob Anfragen aus dem Telekom-Netz schneller beantwortet werden als solche aus dem Vodafone-Netz.

Programmierer und Administratoren sollten spätestens jetzt ein Déjà-vu haben: In der Softwareentwicklung prüft man die erstellten Programme mit End-to-End-Tests auf exakt dieselbe Weise. In vielen Unternehmen beobachten zudem Werkzeuge die Anwender und spielen ihre Aktionen bei Bedarf automatisch wieder ab. So wandert etwa eine per E-Mail hereinkommende Rechnung umgehend in das Dokumentenmanagementsystem. Solche Helfer kennen Administratoren unter dem Begriff Robotic Process Automation (RPA). Tatsächlich sind die Grenzen zum E2E-Monitoring fließend: Zahlreiche RPA- und Testwerkzeuge eignen sich ebenso gut für das Synthetic Monitoring.

Synthetische Werkzeuge

Genau das trifft beispielsweise auf das Robot Framework zu [4]. Der quelloffene Werkzeugkasten hilft eigentlich bei der Testautomation und der RPA, hat sich aber beim E2E-Monitoring ebenso bewährt (Abbildung 4). Das Framework lässt sich leicht um zusätzliche Funktionen erweitern, Testfälle notieren Sie in der hauseigenen Skriptsprache. Dessen Syntax verstehen mittlerweile Visual Studio Code und PyCharm, mit RIDE gibt es außerdem eine eigene Entwicklungsumgebung [6].

Abbildung 4: Das Robot Framework verlangt die Testfälle in Form von Skripten, wobei sich einige Beispiele direkt auf der Projektwebseite ausprobieren lassen.

Abbildung 4: Das Robot Framework verlangt die Testfälle in Form von Skripten, wobei sich einige Beispiele direkt auf der Projektwebseite ausprobieren lassen.

Das Robot Framework integriert die Erweiterung Robotmk [6] in das Monitoring-System Checkmk (Abbildung 5). Für Checkmk 2.3 steht die Erweiterung in Form des Addons Checkmk Synthetic Monitoring [7] zur Verfügung. In jedem Fall sogt das Monitoring-System dafür, dass die Tests immer wieder automatisch anlaufen, ihre Ergebnisse bereitet die Checkmk-Oberfläche auf. Die Integration besitzt den Vorteil, dass Sie mit dem gewohnten Monitoring-System weiterarbeiten können und nicht zwei komplett unterschiedliche Überwachungslösungen pflegen müssen. Auch das Monitoring-System Zabbix kann bei Webanwendung eingeschränkt ein Synthetic Monitoring vornehmen [8].

Abbildung 5: Die Erweiterung Robotmk funktioniert mit Checkmk ab Version 1.6.

Abbildung 5: Die Erweiterung Robotmk funktioniert mit Checkmk ab Version 1.6.

Bei Webanwendungen werden daneben häufig die alten Bekannten Cypress [9] und das Selenium Framework eingespannt [10]. Letzteres steuert den Browser und die darin enthaltenen Seiten über Skripte fern. Das Testwerkzeug kann die Mausklicks eines Nutzers aufzeichnen und später wieder abspielen, was wiederum das Erstellen von praxisnahen Tests deutlich vereinfacht (Abbildung 6).

Abbildung 6: Selenium kann aufgezeichnete Aktionen in unterschiedlichen Geschwindigkeiten abspulen.

Abbildung 6: Selenium kann aufgezeichnete Aktionen in unterschiedlichen Geschwindigkeiten abspulen.

Die Mischung macht’s

Das Synthetic Monitoring simuliert allerdings nur typische Nutzeraktionen. Reale Nutzer verhalten sich möglicherweise komplett anders. In der Praxis kombiniert man deshalb das Real User Monitoring mit dem Synthetic Monitoring. Letzteres kommt bevorzugt während der Entwicklung beziehungsweise noch vor der Veröffentlichung einer neuen Version zum Einsatz. Reagiert etwa der Warenkorb beim Synthetic Monitoring nicht binnen einer Sekunde, gelangt die Software gar nicht erst zum Kunden. Zum einen kann man so frühzeitig Performance-Probleme und Fehler entdecken, zum anderen lassen sich vorab Performance-Richtlinien und SLAs sicherstellen.

Nach dem Deployment der Anwendung stellt dann das RUM sicher, dass die Anwendung im Betrieb wie erwartet läuft. Nur mit dem RUM kommen plötzliche Ausfälle oder Performance-Probleme von Drittanbieterdiensten zum Vorschein. Zudem erfahren Sie, wie sich die Anwendung auf den Geräten der Nutzer verhält, insbesondere, wenn sie exotische Smartphones nutzen.

Zielstrebig ans Ziel

Wenn Sie jetzt mit einem E2E-Monitoring liebäugeln, sollten Sie kurz innehalten und dessen Einsatz vorab planen. Ausschließlich so können Sie das Monitoring gezielt und effektiv die wirklich wichtigen Funktionen in der Anwendung überwachen lassen und eine dazu passende Lösung wählen.

Dazu legen Sie in einem ersten Schritt fest, welche Ziele Sie mit der Überwachung überhaupt erreichen möchten. Ist zum Beispiel die Reaktionszeit des Warenkorbs besonders wichtig für den Unternehmenserfolg? Hierbei hilft es, konkrete Geschäftsziele zu formulieren. Beispielsweise könnten Sie von der Prämisse ausgehen, mehr Kunden zum Abschluss eines Kaufs zu bewegen oder pro Stunde mindestens einen Umsatz von 10 000 Euro zu generieren.

Im nächsten Schritt gilt es, herauszufinden, welche Messwerte Sie zum Erreichen der Ziele in welchem Umfang benötigen. Dabei geht es nicht allein um die Messpunkte innerhalb der Anwendung. Sie müssen die Ergebnisse des E2E-Monitorings mit weiteren Daten verknüpfen wie der aktuellen Auslastung des Servers. Nur so finden Sie heraus, ob die Trägheit des Warenkorbs an einem gerade überforderten Apache-Webserver oder doch an einer schlechten Implementierung liegt. Folglich gilt es, die notwendigen Datenquellen zu identifizieren und geschickt zusammenzuführen. In größeren Unternehmen müssen dazu sogar mehrere Teams aus Entwicklern, DevOps und Administratoren zusammenarbeiten.

Werkzeugwahl

Bei der jetzt anstehenden Wahl einer konkreten Monitoring-Lösung sollten Sie darauf achten, dass sie Ihre Ziele und Anforderungen erfüllt. Prüfen Sie, ob sich schon vorhandene Test- und Monitoring-Werkzeuge für ein RUM oder ein Synthetic Monitoring eignen. Dadurch können Sie unter Umständen darauf verzichten, eine neue Monitoring-Lösung einzuführen. Alle Messungen, Testfälle und die Konfiguration sollten Sie versionieren. Idealerweise übernimmt das die Monitoring-Lösung.

Für ein RUM müssen Sie das entsprechende Monitoring-Werkzeug in die Anwendung einbinden. Arbeit spart ein dazu bereitgestelltes SDK. Setzen Sie die Messpunkte passend zu Ihren Anforderungen, das hält gleichzeitig das Rauschen gering. Selbstverständlich muss die Monitoring-Lösung die erzeugten Messdaten irgendwo speichern. Nutzen Sie dazu möglichst ein offenes Format, was später das Auswerten, Speichern und Weitergeben der Daten erleichtert.

Des Weiteren müssen Sie klären, welche Datenspeicher und Datenbanken infrage kommen. Wenn die Software beispielsweise jeden einzelnen Kunden durch den Check-out-Prozess im Online-Shop begleiten soll, fallen in kurzer Zeit große Datenmengen an, die eine passende Infrastruktur im Hintergrund auffangen und speichern muss.

Betriebsführung

Bei der Einführung von neuen Funktionen oder nach Arbeiten am Quellcode droht am ehesten die Gefahr von Performance-Problemen und Bugs. Jede neue Version der Anwendung sollten Sie daher möglichst noch vor der Veröffentlichung intern durch das E2E-Monitoring schicken und so vorab auf Performance-Probleme abklopfen.

Sämtliche Tests und das RUM müssen unter realen Bedingungen und vor allem auf den verschiedenen Endgeräten der Nutzer stattfinden. Einer Webanwendung sollte die Monitoring-Lösung somit nicht nur im verbreiteten Chrome auf den Zahn fühlen, sondern zumindest auch noch in Firefox. Darüber hinaus müssen die Anfragen von verschiedenen Stellen ausgehen. Testen Sie zum Beispiel, ob Zugriffe aus dem Telekom- und dem Vodafone-Netz auf Ihren Online-Shop gleich schnell erfolgen. Die vom Monitoring ausgespuckten Werte sollten Sie schließlich immer wieder auf den Prüfstand stellen. Ist beispielsweise die Performance des Warenkorbs nach zwei Jahren immer noch wichtig, oder gibt es mittlerweile andere Ziele?

Letztlich sollten Sie die E2E-Monitoring-Lösung ebenfalls einem Monitoring unterziehen: Eine ausgefallene Lösung deckt weder Probleme auf, noch misst sie die Performance. Klassische Monitoring-Systeme macht ein E2E-Monitoring außerdem keineswegs überflüssig. So müssen Administratoren weiterhin umgehend informiert werden, wenn die Maschine mit dem Webserver plötzlich hängt. Einen derartigen Fehler kann ein E2E-Monitoring-Werkzeug nicht erkennen.

Fazit

Beim End-to-End-Monitoring steht die Überwachung der kompletten Anwendung im Vordergrund. Die gelieferten Daten helfen vor allem beim Verbessern der User Experience und der Performance. Darüber hinaus entdeckt das E2E-Monitoring fehlerhaft arbeitende Funktionen, die das herkömmliche Monitoring nicht erfasst.

Seine Vorteile spielt das E2E-Monitoring besonders bei Anwendungen aus, die sich aus mehreren Komponenten zusammensetzen oder auf einer Microservices-Architektur fußen. Dort stellt es sicher, dass im Hintergrund alle Komponenten korrekt ineinandergreifen.

Das E2E-Monitoring deckt somit Bereiche ab, die das herkömmliche Monitoring nicht berücksichtigt, und sollte vor allem bei Webanwendungen stets zum Einsatz kommen. (csi)

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 6 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben