AIOps auf VPS: Self-Hosted KI-Monitoring Open Source

Datadog und New Relic berechnen pro Host, pro GB oder beides. Für einen Einzelentwickler oder ein kleines Team, das ein bis fünf VPS-Instanzen betreibt, summieren sich diese Kosten schnell bei geringem Nutzen. Aktuelle Preise finden Sie auf der Datadog-Preisseite und der New-Relic-Preisseite.

Die Alternative: Betreiben Sie Ihren gesamten Monitoring-, Loganalyse- und Incident-Response-Stack auf einem einzelnen VPS. Open-Source-Tools wie SigNoz, Grafana+Loki und Ollama bieten Ihnen Observability, KI-gestützte Anomalieerkennung und automatisierte Fehlerbehebung. Gesamtkosten: der Preis Ihres VPS. Bei Virtua Cloud beginnt das bei 24 EUR/Monat für einen Server mit 2 vCPU und 4 GB RAM für grundlegende Observability, oder 48 EUR/Monat für den kompletten Stack auf einem Server mit 4 vCPU und 8 GB RAM.

Dieser Artikel beschreibt die fünf Schichten eines selbstgehosteten AIOps-Stacks. Es handelt sich nicht um eine Schritt-für-Schritt-Anleitung. Jeder Abschnitt erklärt die Funktion der Schicht, empfiehlt Tools und verweist auf den dedizierten Leitfaden, in dem Sie alles installieren und konfigurieren.

Was ist AIOps und warum ist es für VPS-Betreiber relevant?

AIOps bedeutet, KI und maschinelles Lernen einzusetzen, um Monitoring, Loganalyse, Anomalieerkennung und Incident Response zu automatisieren. Für VPS-Betreiber ersetzt es den manuellen Zyklus aus Dashboards prüfen, Logs lesen und Dienste neustarten. Anstatt für Enterprise-SaaS-Plattformen zu bezahlen, betreiben Sie Open-Source-Tools auf der Infrastruktur, die Sie bereits verwalten. Ihre Daten bleiben auf Ihrem Server. Ihre Kosten bleiben konstant.

Die Enterprise-Definition von AIOps konzentriert sich auf die Korrelation tausender Alerts über hunderte Microservices hinweg. Darum geht es in diesem Leitfaden nicht. Für VPS-Betreiber, die ein bis fünf Server verwalten, bedeutet AIOps:

Metriken, Logs und Traces sammeln an einem Ort, statt sich per SSH auf jeden Server zu verbinden.
Ein lokales LLM betreiben, um Muster in Logs zu erkennen, die grep und Regex übersehen.
Reaktionen automatisieren auf häufige Ausfälle wie eine volle Festplatte, einen abgestürzten Prozess oder ein Speicherleck.
KI-Feedback zum Code erhalten, bevor er in Produktion geht.

Der Stack hat fünf Schichten. Sie brauchen nicht alle. Beginnen Sie mit Observability, fügen Sie KI-Analyse hinzu, wenn das Logvolumen die manuelle Überprüfung mühsam macht, und arbeiten Sie sich in Richtung Self-Healing vor, wenn Sie Vertrauen gewonnen haben.

Was kostet Self-Hosted-Monitoring im Vergleich zu Datadog?

Ein selbstgehosteter AIOps-Stack auf einem Virtua Cloud VPS kostet zwischen 24 und 96 EUR/Monat, je nachdem, wie viele Schichten Sie bereitstellen. Das sind die Gesamtkosten: Server, Speicher, Bandbreite und die gesamte Software. Kommerzielle Alternativen wie Datadog verwenden Pro-Host- und Pro-GB-Preismodelle, die mit Ihrer Infrastruktur skalieren. Deren Kosten steigen, wenn Sie Hosts hinzufügen, mehr Logs aufnehmen oder APM-Tracing aktivieren.

Funktion	Kommerzielles SaaS (Datadog, New Relic)	Self-Hosted (Virtua Cloud VPS)
Infrastruktur-Monitoring	Pro-Host-Preise, nach Plan gestaffelt	Enthalten (Prometheus + Grafana)
Log-Management	Pro-GB-Aufnahme + Indexierungsgebühren pro Event	Enthalten (Loki oder OpenObserve)
APM / Traces	Zusätzliche Pro-Host-Gebühr	Enthalten (SigNoz oder Tempo)
KI-Loganalyse	Nicht verfügbar oder separates Add-on	Enthalten (Ollama + lokales LLM)
Alerting	Enthalten	Enthalten (Alertmanager)
Datenaufbewahrung	Vom Anbieter definierte Grenzen (Tage bis Monate)	Sie bestimmen es. Die Festplatte ist das Limit.
Datenstandort	US/EU (Ihre Wahl)	Ihr VPS. Ihre Jurisdiktion.
Preismodell	Pro Host + pro GB, wächst mit der Nutzung	Feste monatliche VPS-Kosten

Für aktuelle kommerzielle Preise siehe Datadog-Preise und New-Relic-Preise. Die Self-Hosted-Kosten hängen nur vom gewählten VPS-Plan ab.

Die Self-Hosted-Spalte setzt einen einzelnen vCS-8-Plan voraus (4 vCPU, 8 GB RAM, 160 GB SSD), der den kompletten Observability-Stack via Docker Compose betreibt. Wenn Sie nur grundlegende Metriken und Logs benötigen, bewältigt ein vCS-4 (2 vCPU, 4 GB RAM) für 24 EUR/Monat Grafana + Loki + Prometheus für kleine Workloads.

Für Teams, die auch die KI-Analyseschicht wollen (Ollama mit einem 3-7B-Parameter-Modell), ist der 8 GB VPS das Minimum. Ollama mit Gemma 2 (2B) läuft mit etwa 2 GB RAM und lässt genug Spielraum für SigNoz oder Grafana daneben.

Welche Open-Source-Observability-Tools funktionieren am besten auf einem VPS?

Die Observability-Schicht sammelt Metriken, Logs und Traces von Ihren Anwendungen und Ihrer Infrastruktur. Drei Open-Source-Stacks dominieren diesen Bereich: SigNoz, OpenObserve und Grafana + Loki. Jeder macht unterschiedliche Kompromisse zwischen Funktionsumfang, Ressourcenverbrauch und Komplexität.

Tool	Am besten für	Logs	Metriken	Traces	Backend	Min RAM	Komplexität
SigNoz	Vollständiger APM-Ersatz für Datadog	Ja	Ja	Ja	ClickHouse	4 GB	Mittel
OpenObserve	Leichtgewichtige Log-Aggregation	Ja	Ja	Ja	Integriert (Rust)	~1 GB	Niedrig
Grafana + Loki + Prometheus	Etabliertes Ökosystem, Erweiterbarkeit	Ja (Loki)	Ja (Prometheus)	Via Tempo	Mehrere	2-4 GB	Höher

Alle drei unterstützen OpenTelemetry für die Instrumentierung. Das bedeutet, Sie können Ihre Anwendung einmal instrumentieren und das Backend später wechseln, ohne den Anwendungscode zu ändern.

Wann sollten Sie SigNoz statt OpenObserve wählen?

Wählen Sie SigNoz, wenn Sie vollständiges Application Performance Monitoring benötigen: verteilte Traces, Service Maps, Error Tracking und korrelierte Logs. SigNoz verwendet ClickHouse als Storage-Engine, die hochkardinalige Daten gut verarbeitet, aber mehr RAM erfordert. Ein Docker-Compose-Deployment braucht mindestens 4 GB RAM für SigNoz, wobei 8 GB für Produktions-Workloads mit ClickHouse empfohlen werden.

Wählen Sie OpenObserve, wenn Ihr Hauptbedarf Log-Aggregation und Suche ist. OpenObserve wird als einzelne Binary in Rust ausgeliefert. Es startet mit unter 1 GB RAM in einem einfachen Docker-Compose-Setup. Es verspricht 140-mal niedrigere Speicherkosten im Vergleich zu Elasticsearch dank spaltenbasierter Kompression. Wenn Sie ein Indie-Hacker sind, der eine einzelne Anwendung betreibt und schnelle Logsuche ohne den Overhead von ClickHouse möchte, ist OpenObserve der leichtere Weg.

Beide Tools haben Web-UIs für Abfragen und Dashboards. SigNoz bietet ein vollständigeres Datadog-ähnliches Erlebnis. OpenObserve ist schlanker und schneller zu deployen.

Ist Grafana + Loki 2026 noch die beste Option?

Grafana + Loki bleibt die flexibelste Option. Es ist nicht die einfachste Einrichtung, aber es gewinnt bei der Breite des Ökosystems. Tausende Community-Dashboards existieren für jeden erdenklichen Dienst. Prometheus-Exporter decken Datenbanken, Webserver, Hardware-Metriken und benutzerdefinierte Anwendungsmetriken ab. Loki übernimmt die Log-Aggregation mit einer LogQL-Abfragesprache, die PromQL widerspiegelt.

Der Kompromiss: mehr bewegliche Teile. Ein minimaler Grafana-Stack bedeutet, Grafana (UI), Prometheus (Metriken) und Loki (Logs) als separate Container zu betreiben. Dazu kommt Promtail oder Alloy als Log-Shipper. Das sind vier Container, bevor Sie Ihre eigene Anwendung hinzufügen. Auf einem 4 GB VPS passt dieser Stack, lässt aber wenig Spielraum.

Wählen Sie Grafana + Loki, wenn Sie das Ökosystem bereits kennen, umfangreiche Anpassungen benötigen oder Tools integrieren möchten, die nur Prometheus-Metrik-Export unterstützen.

Wie fügen Sie KI-gestützte Loganalyse zu Ihrem Monitoring-Stack hinzu?

Betreiben Sie ein lokales LLM über Ollama, um Logs zu analysieren, ohne Daten an eine externe API zu senden. Ollama stellt Modelle wie Gemma 2 (2B), Llama 3.2 (3B) oder Qwen 2.5 (7B) über eine lokale HTTP-API bereit. Ein Skript oder Cron-Job speist Log-Auszüge in das Modell ein und fragt es, Anomalien zu identifizieren, Fehlermuster zusammenzufassen oder Ursachen vorzuschlagen. Keine API-Kosten. Keine Daten verlassen Ihren Server.

Hier unterscheidet sich selbstgehostetes AIOps vom traditionellen Monitoring. Grafana und Prometheus sagen Ihnen, was passiert ist. Ein lokales LLM hilft Ihnen zu verstehen, warum.

Was die KI-Analyseschicht leistet:

Anomalieerkennung: Geben Sie die letzten 1.000 Logzeilen mit einem Prompt wie „Identifiziere ungewöhnliche Muster oder Fehler in diesen Logs" an das Modell. Das Modell markiert Einträge, die von normalen Mustern abweichen.
Fehlerzusammenfassung: Wenn ein Vorfall hunderte Logzeilen erzeugt, fasst das LLM sie in eine lesbare Zusammenfassung mit der wahrscheinlichen Ursache zusammen.
Mustererkennung: Mit der Zeit treten wiederkehrende Fehlermuster auf. Das LLM kann verwandte Fehler gruppieren und wiederkehrende Probleme identifizieren, die schwellenwertbasierte Alerts nicht auslösen würden.

Modellgrößen für VPS:

Modell	Parameter	RAM-Verbrauch	Geschwindigkeit (Tokens/Sek., CPU)	Am besten für
Gemma 2 (2B)	2,6 Mrd.	~2 GB	~15-20	Schnelle Log-Triage auf VPS mit wenig RAM
Llama 3.2 (3B)	3,2 Mrd.	~2,5 GB	~10-15	Ausgewogene Analyse und Geschwindigkeit
Qwen 2.5 (7B)	7 Mrd.	~5 GB	~5-8	Tiefere Analyse, braucht 8 GB+ VPS

Auf einem 4-vCPU-VPS ohne GPU erwarten Sie reine CPU-Inferenz. Ein 2-3B-Modell liefert nützliche Loganalyse in 5-15 Sekunden pro Abfrage. Das reicht für Batch-Analyse alle paar Minuten, nicht für Echtzeit-Streaming.

Das ist keine Magie. Kleine Modelle halluzinieren. Sie übersehen Kontext. Sie markieren manchmal normale Log-Einträge als verdächtig. Behandeln Sie LLM-Loganalyse als Triage-Assistenten, nicht als Orakel. Überprüfen Sie seine Vorschläge immer anhand der tatsächlichen Logs und Metriken.

Was ist ein selbstheilender VPS und wie funktioniert er?

Ein selbstheilender VPS erkennt und behebt häufige Ausfälle automatisch ohne menschliches Eingreifen. Die grundlegende Architektur: Prometheus überwacht Metriken, Alertmanager löst Alerts aus, wenn Schwellenwerte überschritten werden, und ein Webhook-Empfänger führt Behebungsskripte aus. Ein LLM in dieser Schleife ermöglicht die Behandlung von Ausfällen, die keinen vordefinierten Regeln entsprechen.

Die Self-Healing-Pipeline:

Prometheus sammelt alle 15 Sekunden Metriken (CPU, Speicher, Festplatte, Prozessstatus, HTTP-Fehlerraten).
Alerting-Regeln definieren Bedingungen: Festplattennutzung über 90 %, ein Dienst antwortet seit 60 Sekunden nicht, Speichernutzung dauerhaft über 95 %.
Alertmanager empfängt den Alert und leitet ihn an einen Webhook-Endpunkt weiter.
Behebungshandler empfängt den Webhook. Für bekannte Bedingungen (volle Festplatte, abgestürzter Dienst) führt er ein vordefiniertes Skript aus. Für unbekannte Bedingungen ruft er das lokale LLM über Ollama mit dem Alert-Kontext und den aktuellen Logs auf und fragt nach Diagnose und Behebungsvorschlag.
Ausführung (optional): Für bekannte Behebungen mit hoher Konfidenz (Dienst neustarten, temporäre Dateien löschen, Logs rotieren) führt der Handler automatisch aus. Für LLM-vorgeschlagene Aktionen sendet er den Vorschlag an Ihren Benachrichtigungskanal zur menschlichen Genehmigung.

Häufige automatisierte Behebungen:

Festplatte voll: /tmp leeren, alte Logs rotieren, Docker-Images mit docker system prune bereinigen.
Dienst abgestürzt: systemctl restart <service>, dann Gesundheitsstatus prüfen. Bei erneutem Absturz innerhalb von 5 Minuten an einen Menschen eskalieren.
Speicherdruck: Den größten Speicherverbraucher identifizieren, ihn neu starten, wenn er seine erwartete Baseline überschreitet.
Zertifikatsablauf: Eine Certbot-Erneuerung auslösen, wenn das Zertifikat in weniger als 7 Tagen abläuft.

Beginnen Sie konservativ. Automatisieren Sie nur Behebungen, die Sie dutzende Male manuell ausgeführt haben und vollständig verstehen. Lassen Sie das LLM Aktionen für unbekannte Situationen vorschlagen, aber behalten Sie einen Menschen in der Schleife für die Ausführung.

Für einen No-Code-Ansatz zum Alert-Routing und zu Behebungs-Workflows kann n8n die Orchestrierungsschicht zwischen Alertmanager und Ihren Behebungsskripten bilden.

Wie passt KI in Ihre CI/CD-Pipeline?

KI-Code-Review erkennt Bugs, Sicherheitslücken und Performance-Probleme, bevor der Code Ihren Server erreicht. GitHub-Actions-Workflows können Pull-Request-Diffs zur Analyse an Claude oder Gemini senden, Review-Kommentare posten und Merges blockieren, wenn kritische Probleme gefunden werden. Das läuft in Ihrer CI/CD-Pipeline ohne Änderungen an Ihrem VPS.

Was KI-Code-Review erkennt, das Linter übersehen:

Logikfehler und Randfälle, die statische Analyse nicht erkennen kann.
Sicherheitslücken im Kontext (ein Linter markiert gefährliche Funktionen, aber ein LLM versteht, warum der umgebende Code sie ausnutzbar macht).
Performance-Regressionen: „Diese Abfrage in einer Schleife wird die Datenbank N-mal ansprechen."
Dokumentationslücken: fehlende Fehlerbehandlung, unklare Variablennamen, undokumentierte Seiteneffekte.

Diese Schicht unterscheidet sich von den anderen, da sie typischerweise in Ihrer CI-Plattform (GitHub Actions, GitLab CI) läuft, nicht auf Ihrem VPS. Wenn Sie jedoch alles selbst hosten möchten, können Sie einen CI-Runner auf Ihrem VPS betreiben und Code-Review-Anfragen an Ihre lokale Ollama-Instanz weiterleiten. Der Kompromiss: langsamere Reviews mit kleineren Modellen gegenüber schnelleren, genaueren Reviews mit Cloud-APIs.

Was ist LLM-Observability und warum brauchen Sie sie?

LLM-Observability verfolgt die Leistung Ihrer KI-Tools: Token-Verbrauch, Latenz, Fehlerraten, Kosten und Ausgabequalität. Wenn Sie eine LLM-gestützte Funktion betreiben (Chatbot, Code-Assistent, Log-Analysator, Content-Generator), gibt Ihnen Langfuse Einblick in jeden Aufruf. Es ist die Schicht „die Monitore überwachen" Ihres AIOps-Stacks.

Langfuse ist eine Open-Source-Plattform für LLM-Engineering. Selbstgehostet läuft sie als zwei Container (Web + Worker) mit PostgreSQL und optional ClickHouse für Analysen. Sie bietet:

Tracing: Jeden LLM-Aufruf mit Eingabe, Ausgabe, Latenz und Token-Anzahl sehen. In mehrstufige Agent-Workflows eintauchen, um zu finden, wo Zeit und Tokens verbraucht werden.
Evaluierung: Ausgaben mit LLM-as-a-Judge, menschlichem Feedback oder benutzerdefinierten Metriken bewerten. Qualität über die Zeit verfolgen.
Kostenverfolgung: Tatsächliche Ausgaben pro LLM-Aufruf, pro Benutzer, pro Funktion berechnen. Modellleistung bei verschiedenen Preispunkten vergleichen.
Prompt-Management: Prompts versionieren und A/B-testen. Zurückrollen, wenn ein neuer Prompt die Ausgabequalität verschlechtert.

Wenn Sie Ollama für Loganalyse betreiben (Schicht 2 dieses Stacks), verfolgt Langfuse jede Analyseanfrage. Sie sehen, welche Log-Abfragen nützliche Ergebnisse liefern, welche dem Modell Schwierigkeiten bereiten und wie sich die Latenz ändert, wenn Sie Modelle wechseln.

Langfuse integriert sich mit OpenTelemetry, LangChain, LlamaIndex und dem OpenAI SDK (mit dem Ollama kompatibel ist). Die Instrumentierung erfordert in der Regel nur wenige Codezeilen.

Sie brauchen diese Schicht, wenn Ihre LLM-Nutzung über das Experimentieren hinausgeht. Sobald Sie sich für Alerting oder Fehlerbehebung auf KI-Ausgaben verlassen, müssen Sie wissen, wann das Modell anfängt, unbrauchbare Ergebnisse zu produzieren.

Welche VPS-Ressourcen brauchen Sie für einen kompletten AIOps-Stack?

Die Ressourcen hängen davon ab, welche Schichten Sie bereitstellen. Hier sind drei Konfigurationen, die den Virtua Cloud VPS-Plänen zugeordnet sind:

Konfiguration	Schichten	VPS-Plan	CPU	RAM	Festplatte	EUR/Monat
Starter	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 GB	80 GB	24
Standard	SigNoz + Ollama (3B-Modell)	vCS-8	4 vCPU	8 GB	160 GB	48
Komplett	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

Starter bewältigt Metriken und Log-Aggregation für ein bis drei kleine Anwendungen. Dashboards und Alerts ohne KI-Analyse.

Standard fügt KI-Loganalyse hinzu. SigNoz benötigt etwa 4 GB und Ollama mit einem 3B-Modell etwa 2,5 GB. Der verbleibende RAM geht an das Betriebssystem und Ihre überwachten Anwendungen. Das ist der optimale Punkt für einen Einzelentwickler oder ein kleines Team.

Komplett betreibt alle in diesem Leitfaden beschriebenen Schichten. Ein 7-Milliarden-Parameter-Modell liefert bessere Analyse als ein 3B-Modell, braucht aber mehr RAM. Langfuse fügt etwa 1 GB hinzu. Diese Konfiguration ist für Teams, die LLM-gestützte Funktionen in Produktion betreiben und vollständige Observability über ihre Infrastruktur und ihre KI benötigen.

Alle Konfigurationen laufen über Docker Compose. Die zugehörigen Artikel behandeln die genauen docker-compose.yml-Dateien für jedes Tool.

Hinweis zur Festplattennutzung: Observability-Daten wachsen schnell. SigNoz mit ClickHouse komprimiert gut (erwarten Sie 5-10-fache Kompression bei Logs), aber planen Sie mit 1-5 GB neuer Daten pro Tag, je nach Log-Verbosität. Legen Sie Aufbewahrungsrichtlinien vom ersten Tag an fest. Eine 160-GB-Festplatte gibt Ihnen bei moderaten Aufnahmeraten etwa ein bis drei Monate an Daten.

Datensouveränität: der DSGVO-Vorteil von selbstgehostetem Monitoring

Wenn Sie Ihren Monitoring-Stack auf einem europäischen VPS betreiben, verlassen Ihre Observability-Daten nie die Jurisdiktion. Metriken, Logs und Traces enthalten oft personenbezogene Daten: IP-Adressen, Benutzer-IDs, Anfragepfade, Fehlermeldungen mit Benutzerkontext. Das Senden dieser Daten an eine US-basierte SaaS-Plattform birgt ein DSGVO-Transferrisiko, selbst wenn der Anbieter eine EU-Region anbietet.

Mit einem selbstgehosteten Stack auf einem Virtua Cloud VPS in Frankreich oder Deutschland kontrollieren Sie:

Wo die Daten gespeichert werden. Auf der Festplatte, in Ihrem VPS, in einem europäischen Rechenzentrum.
Wer darauf zugreifen kann. Keine Anbieter-Mitarbeiter, keine Unterauftragsverarbeiter, keine Datenverarbeitungsvereinbarungen mit Dritten zum Auditieren.
Wie lange sie aufbewahrt werden. Sie legen die Aufbewahrungsrichtlinie fest. Keine vom Anbieter vorgegebenen Mindestzeiten oder Datenlöschungspläne.

Dies ist keine Rechtsberatung. Konsultieren Sie Ihren Datenschutzbeauftragten für Ihre spezifische Situation. Aber aus technischer Sicht beseitigt selbstgehostetes Monitoring eine ganze Kategorie von Datentransferfragen.

Wo sollten Sie anfangen?

Ihr Ausgangspunkt hängt von Ihrer Erfahrung ab und davon, welches Problem Sie gerade lösen.

Wenn Sie neu im Server-Monitoring sind (Indie-Hacker, erster VPS):

Beginnen Sie mit SigNoz. Es liefert Ihnen Metriken, Logs und Traces in einem Tool mit Web-UI. Eine Docker-Compose-Datei, ein Tool zum Lernen.
Sobald Sie sicher Dashboards lesen, fügen Sie Ollama für KI-Loganalyse hinzu.
Automatisieren Sie noch keine Fehlerbehebung. Verstehen Sie zuerst das normale Verhalten Ihres Servers.

Wenn Sie bereits Prometheus oder Grafana nutzen (DevOps-Profis):

Fügen Sie Loki für Log-Aggregation hinzu, falls noch nicht geschehen.
Integrieren Sie Ollama für KI-gestützte Log-Triage neben Ihren bestehenden Alerting-Regeln.
Bauen Sie Self-Healing-Workflows mit Alertmanager-Webhooks.
Fügen Sie Langfuse hinzu, wenn Sie beginnen, sich bei operativen Entscheidungen auf LLM-Ausgaben zu verlassen.

Wenn Sie den kompletten Stack vom ersten Tag an wollen (KI-Entwickler):

Stellen Sie einen vCS-8 oder vCS-16 VPS auf Virtua Cloud bereit.
Richten Sie SigNoz für Observability ein.
Betreiben Sie Ollama mit einem 7B-Modell für Loganalyse und Anomalieerkennung.
Verbinden Sie Alertmanager mit Ihren Behebungsskripten.
Deployen Sie Langfuse, um Ihre LLM-Schicht zu überwachen.
Fügen Sie KI-Code-Review zu Ihrer CI/CD-Pipeline hinzu.

Jeder zugehörige Artikel in diesem Themencluster ist ein eigenständiges Tutorial. Sie können sie in beliebiger Reihenfolge durcharbeiten. Der Stack ist modular: Jede Schicht funktioniert unabhängig und bietet eigenständig Mehrwert.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.