Überblick
VictoriaLogs auf Cloudzy gibt dir eine schnelle, selbst gehostete Log-Datenbank unter deiner vollen Kontrolle. Starte einen einzelnen Node für die Entwicklung oder eine leistungsstärkere Instanz für den Produktionsbetrieb und richte dann Vector, Fluent Bit, oder Syslog darauf aus - Abfragen laufen innerhalb von Sekunden. Dedizierte EPYC vCPUs, DDR5 RAM, reines NVMe und ein 10 Gbps-Uplink sorgen dafür, dass Ingest und Abfragen auch im Spitzenbetrieb flott bleiben. Stündliche Abrechnung erlaubt es dir, bei Bedarf hochzuskalieren und danach wieder zurückzufahren.
Beschreibung
Dieses One-Click-Image enthält VictoriaLogs innerhalb von Docker mit einem schlanken systemd-Wrapper sowie nützlichen Zusatzkomponenten wie Grafana, Vector, vmauth, vmalert, Alertmanager und VictoriaMetrics Single-Node für Metriken. VictoriaLogs lauscht auf seinem nativen HTTP-Port und ist sofort bereit, Logs entgegenzunehmen und Abfragen zu beantworten. Details zu Datenmodell, Ingestion-Methoden und Abfragemustern findest du in der offiziellen Dokumentation.
Webinterface aufrufen
Rufe zunächst die bereits laufenden Dienste auf deinem Server auf. Ersetze <SERVER-IP> durch die IP-Adresse deiner Instanz.
- VictoriaLogs: http://<SERVER-IP>:9428 (Ingest, Abfragen und Metriken unter /metrics).
- Grafana: http://<SERVER-IP>:3000 (erste Anmeldung ist admin /admin, dann ändern Sie es).
- VictoriaMetrics Single-Node: http://<SERVER-IP>:8428 für Prometheus-kompatible Metriken.
- vmalert Benutzeroberfläche & API: http://<SERVER-IP>:8880.
- vmauth Tor: http://<SERVER-IP>:8427 für Authentifizierung und Routing.
- Alertmanager: http://<SERVER-IP>:9093.
- Vector API & Benutzeroberfläche: http://<SERVER-IP>:8686 wenn aktiviert in vector config.
Service-Steuerung für den laufenden Betrieb:
| sudo systemctl Starten victoria-logs sudo systemctl stop victoria-logs sudo systemctl status victoria-logs docker ps |
Erweiterte Funktionen
Das sind die praxisrelevanten Verbesserungen für eine Log-Datenbank auf eigener Infrastruktur. Sie senken die Abfragelatenz, halten die Ingestion auch bei Lastspitzen stabil und ermöglichen ein schnelles Rollback, falls ein Update Probleme verursacht.
- Dedizierte vCPUs und DDR5 RAM um konkurrierende Schreib- und Lesezugriffe nicht gegenseitig zu blockieren.
- Reiner NVMe-Speicher für hohe IOPS bei WAL, Indexaufbau und Kompaktierung.
- 10 Gbps network port für viele parallele Shipper und Dashboard-Nutzer.
- Snapshots und Rollback auf Abruf vor Upgrades oder Schema-Änderungen.
- Stündliche Abrechnung bedeutet, dass Staging- oder Last-Test-Klone nur für die Stunden anfallen, in denen sie tatsächlich laufen.
Ein einzelner Neustart übernimmt jede Größenänderung. Keine Datenmigration oder Anpassungen an DNS erforderlich.
Benutzerfreundlichkeit
Sie erhalten ein übersichtliches Dashboard, um den Server neu zu starten, Snapshots zu erstellen oder Regionen zu wechseln. Zeigen Sie Vector or Fluent Bit to http://<SERVER-IP>:9428 für HTTP JSON-Ingestion, oder aktivieren Sie Syslog-Receiver auf VictoriaLogs, wenn Sie TCP oder UDP 514 bevorzugen. Beispiel-Konfigurationen finden Sie in der Dokumentation. Sie können mit Standardfeldern starten und die Struktur nach Bedarf ergänzen.
Performance-Fokus
Wenn Ihr Team Grafana Panels in öffentliche Statusseiten oder interne Portale einbettet, sorgen kürzere Time-to-First-Byte und schnellere Ad-hoc-Abfragen dafür, dass Seiten sofort reagieren. NVMe I/O und ein 10 Gbps-Uplink halten die Antwortzeiten stabil, wenn mehrere Nutzer gleichzeitig Abfragen über große Zeitfenster ausführen.
Volle Website-Kontrolle
Sie haben Root-Zugriff. Passen Sie Retention und Indizes an, konfigurieren Sie vmauth Nutzer und richten Sie Alerts über vmalert und Alertmanagerein. Der VictoriaLogs-Container liegt unter /root/VictoriaLogs, verwaltet von einer systemd-Unit, die die Makefile-Targets aufruft. Updates sind damit vorhersehbar und rückgängig zu machen. Nutzen Sie docker ps um Container zu inspizieren oder den Stack mit eigenen Compose-Dateien zu erweitern.
Leistungsstarke Tools
Dieses Image enthält die folgenden Komponenten oder lässt sich damit kombinieren, damit Sie sich auf Log-Qualität konzentrieren können, nicht auf Boilerplate.
- VictoriaLogs Einzelknoten für schnelle Ingestion und Abfragen auf Port 9428.
- Grafana für Dashboards und Ad-hoc-Analysen auf Port 3000.
- VictoriaMetrics Single-Node wenn Sie zusätzlich Metriken auf Port 8428 speichern möchten.
- vmauth um Authentifizierung hinzuzufügen und Multi-Tenant-Traffic auf Port 8427 zu routen.
- vmalert zur Auswertung von Alerting-Regeln und zur Bereitstellung von Alert-APIs auf Port 8880.
- Vector als schlanker, hochdurchsatzfähiger Shipper mit einem API auf 8686, wenn aktiviert.
Globale Reichweite
Wähle die Region, die deinen Nutzern am nächsten liegt. Cloudzy betreibt Points of Presence in:
- Nordamerika : New York City, Dallas, Miami, Utah, Las Vegas
- Europa: London, Amsterdam, Frankfurt, Zürich
- Asien-PazifikSingapur
Jeder Standort bietet denselben 10 Gbps Uplink, Tier-1-Mix und eine Uptime-SLA von 99,95 %. Die einzige Variable ist die Entfernung.
Anwendungsdetails
Version: Nicht angegeben
Betriebssystem: Ubuntu Server 24.04
Mindestens erforderlicher RAM: 1 GB
IP-Typen: IPv6, IPv4
VictoriaLogs jetzt deployen: Deine Log-Datenbank und Dashboards sind in wenigen Minuten einsatzbereit.
Hinweise und Referenzen: VictoriaLogs Standardport 9428 und /metrics Endpoint, Ingestion-Beispiele und Datenmodell sind von VictoriaMetrics dokumentiert. Standardports für vmauth 8427, vmalert 8880, VictoriaMetrics Single-Node 8428, und Grafana 3000 mit First-Login-Flow sind in den offiziellen Guides dokumentiert.
Wichtig: Konfiguration und Domain-Verantwortlichkeiten
Du bekommst auf jeder OCA vollen SSH-/Root-Zugriff. Diese Macht bedeutet auch, dass deine Änderungen Pause die App. Bitte lies das, bevor du an den Configs schraubst.
- Du verwaltest die Domain. Wir verkaufen und hosten keine Domains/DNS. Wenn die App eine Domain braucht, musst du deine Domain auf den Server zeigen lassen (A/AAAA/CNAME sowie MX/TXT, wenn relevant). Die SSL-Ausstellung und viele Dashboards hängen davon ab, dass das korrekt ist.
- Domain/Hostname nach der Installation zu ändern ist nicht trivial. Viele OCAs schreiben die Domain in Configs (.env, Reverse Proxy, App-URLs). Wenn du sie änderst, aktualisiere auch:
- Reverse-Proxy (Nginx/Caddy) und TLS-Zertifikate
- App-„external URL“/Base-URL und Callback-/Webhook-URLs
- Alle fest eingetragenen Links in der App oder in Add-ons
- Anmeldedaten sind wichtig. Den Standard-Admin umbenennen, Passwörter rotieren oder Service-Ports ändern, ohne die App-Config zu aktualisieren, kann ausgesperrt wirst oder Dienste anhalten. Halte Zugangsdaten sicher und synchron zwischen App, Proxy und allen Integrationen.
- Nameserver-Änderungen können Ausfallzeiten verursachen. Beim Umziehen deiner Domain auf neue Nameserver oder Bearbeiten der NS-Einträge entstehen Propagation-Delays. Plane Änderungen, senke die TTL im Voraus und überprüfe A/AAAA-Records, bevor du umstellst.
- Firewall- und Port-Änderungen können den Zugriff unterbrechen. Wenn du SSH-, HTTP/HTTPS-, RDP- oder App-Ports änderst, passe Firewalls (UFW/CSF/Security Groups) und Reverse-Proxy-Regeln entsprechend an.
- E-Mail-Ports (SMTP) sind standardmäßig gesperrt. Ausgehende Mail-Ports (z. B. 25/465/587) könnte sein sind gesperrt, um Missbrauch zu verhindern. Wenn dein OCA E-Mails versenden muss, fordere SMTP-Zugang an. vom Support oder nutze einen Transactional-E-Mail-Anbieter (SendGrid/Mailgun/SES) per API oder freigegebenem SMTP.
- E-Mail & Whitelist. Wenn die App Mails verschickt oder Webhooks empfängt, können geänderte IPs/Hostnamen die Zustellbarkeit oder Allowlists beeinflussen. Aktualisiere SPF/DKIM/DMARC und alle IP-Allowlists.
- Vor größeren Änderungen: Erstelle einen Snapshot. Verwenden Sie zuerst das Snapshot/Sicherung zuerst. Wenn ein Plugin, ein Update oder eine Config-Änderung schiefgeht, kannst du in Minuten zurückrollen.
- Supportumfang. Wir stellen den Server und das vorinstallierte OCA-Image bereit. Der laufende Konfiguration auf Anwendungsebene (Domains, DNS, App-Einstellungen, Plugins und benutzerdefinierter Code) liegen in der Verantwortung des Nutzers.
Faustregel: wenn Sie berühren Domain, Ports, Passwörter, Hostnamen oder Proxy-/SSL-Configs, rechne damit, auch die App-Einstellungen anpassen zu müssen, und erstelle vorher einen Snapshot.
Installation
- VictoriaMetrics-Repo von GitHub geklont nach
/root/VictoriaLogs - Docker und Abhängigkeiten installiert
- systemd-Dienst erstellt
victoria-logszur Verwaltung des VictoriaLogs-Containers über make-Befehle
Befehle
sudo systemctl start victoria-logs # Start VictoriaLogs service sudo systemctl stop victoria-logs # Stop service sudo systemctl status victoria-logs # Check service status docker ps # List running Docker containers
Zugriffs-URLs
- Single-Node VictoriaLogs →
http://<SERVER-IP>:9428 - Grafana →
http://<SERVER-IP>:3000 - Single-Node VictoriaMetrics →
http://<SERVER-IP>:8428 - vmalert →
http://<SERVER-IP>:8880 - vmauth →
http://<SERVER-IP>:8427 - Alertmanager →
http://<SERVER-IP>:9093 - Vector UI →
http://<SERVER-IP>:8686
Dokumentation
- https://docs.victoriametrics.com/victorialogs/