50% off tutti i piani, offerta a tempo limitato. A partire da $2.48/mo
VictoriaLogs
Monitoring

VictoriaLogs

VictoriaLogs è un database di log ad alte prestazioni. Alternativa a Loki più veloce ed economica, con il linguaggio di query LogsQL e label in stile Prometheus. Open-source, scritto in Go, dal team di VictoriaMetrics. Progettato per l'aggregazione di log su scala multi-TB su hardware standard.

Version

Latest

Operating System

Ubuntu Server 24.04 LTS

Min. RAM

1 GB

IP Types

IPV4,IPV6

Distribuisci VictoriaLogs su un VPS ← All apps

Overview

VictoriaLogs su Cloudzy ti fornisce un database di log self-hosted veloce, sotto il tuo controllo. Avvia un singolo nodo per lo sviluppo o una macchina più potente per la produzione, poi punta Vector, Fluent Bit, oppure collegaci syslog e inizia a interrogarlo in pochi secondi. vCPU dedicati EPYC, DDR5 RAM, storage NVMe puro e un uplink a 10 Gbps mantengono l'ingest e le query veloci anche durante i picchi di traffico. La fatturazione a ore ti permette di aumentare le risorse nelle ore di punta e ridurle subito dopo.

Description

Questa immagine One-Click include VictoriaLogs all'interno di Docker con un wrapper systemd leggero, più strumenti utili come Grafana, Vector, vmauth, vmalert, Alertmanager, and VictoriaMetrics single-node per le metriche. VictoriaLogs è in ascolto sulla sua porta HTTP nativa ed è pronto ad accettare log e rispondere alle query da subito. Consulta la documentazione ufficiale per il modello dei dati, i metodi di ingest e i pattern di query. 

Accedi all'interfaccia web

Inizia visitando i servizi già attivi sul tuo server. Sostituisci <SERVER-IP> con l'IP della tua istanza.

  • VictoriaLogs: http://<SERVER-IP>:9428 (ingest, query e metriche su /metrics).

  • Grafana: http://<SERVER-IP>:3000 (first login is admin /admin, then change it).

  • VictoriaMetrics single-node: http://<SERVER-IP>:8428 per le metriche compatibili con Prometheus.

  • vmalert UI & API: http://<SERVER-IP>:8880.

  • vmauth gateway: http://<SERVER-IP>:8427 per autenticazione e routing.

  • Alertmanager: http://<SERVER-IP>:9093.

  • Vector API & UI: http://<SERVER-IP>:8686 if enabled in vector config. 

Controlli del servizio per le operazioni del primo giorno:

sudo systemctl start victoria-logs
sudo systemctl stop victoria-logs
sudo systemctl status victoria-logs
docker ps

Advanced Features

Ecco gli aggiornamenti concreti che fanno la differenza su un database di log in esecuzione su infrastruttura tua. Riducono la latenza delle query, mantengono l'ingest fluido durante i picchi e ti permettono un rollback rapido in caso di aggiornamenti problematici.

  • vCPU dedicati e DDR5 RAM per evitare blocchi da noisy-neighbor su scritture e letture concorrenti.

  • Storage esclusivamente NVMe per IOPS elevati su WAL, creazione di indici e compaction.

  • 10 Gbps network port per shipper ad alto throughput e numerosi utenti di dashboard.

  • Snapshot on-demand e rollback prima di aggiornamenti o modifiche allo schema.

  • Hourly billing significa che i clone per staging o load test costano solo per le ore in cui li tieni attivi.
     Un singolo riavvio applica qualsiasi ridimensionamento. Nessuna migrazione dei dati né modifica ai file DNS necessaria.

Ease of Use

Hai una dashboard chiara per riavviare, creare snapshot o migrare tra regioni. Punta Vector or Fluent Bit to http://<SERVER-IP>:9428 per l'ingest HTTP JSON, oppure abilita i receiver syslog su VictoriaLogs se preferisci TCP o UDP 514. Esempi di configurazione sono disponibili nella documentazione, e puoi partire con i campi predefiniti aggiungendo struttura nel tempo. 

Performance Focus

Se il tuo team incorpora pannelli Grafana in pagine di stato pubbliche o portali interni, tempi di caricamento più bassi sui pannelli e query ad hoc più rapide rendono le pagine molto più reattive. NVMe I/O e un uplink a 10 Gbps mantengono i tempi di risposta stabili anche quando più utenti eseguono query su finestre temporali ampie.

Controllo completo del sito

Hai accesso root. Regola la retention, gestisci gli indici, configura gli utenti vmauth e instrada gli alert tramite vmalert and Alertmanager. Il container VictoriaLogs si trova in /root/VictoriaLogs, gestito da un'unità systemd che richiama i target del Makefile, così gli aggiornamenti sono prevedibili e reversibili. Usa docker ps per ispezionare i container, o estendi lo stack con i tuoi file compose. 

Powerful Tools

Questa immagine include o si abbina ai seguenti componenti, così puoi concentrarti sulla qualità dei log, non sull'infrastruttura.

  • VictoriaLogs nodo singolo per ingest e query ad alta velocità sulla porta 9428.

  • Grafana per dashboard ed esplorazione ad hoc sulla porta 3000.

  • VictoriaMetrics single-node se vuoi anche lo storage delle metriche sulla porta 8428.

  • vmauth per aggiungere autenticazione e instradare il traffico multi-tenant sulla porta 8427.

  • vmalert per valutare le regole di alerting ed esporre gli API di alert sulla porta 8880.

  • Vector come shipper semplice e ad alto throughput con un API su 8686 quando abilitato.

Global Reach

Scegli la regione più vicina ai tuoi utenti. Cloudzy opera punti di presenza in:

  • North America: New York City, Dallas, Miami, Utah, Las Vegas

  • Europe: Londra, Amsterdam, Francoforte, Zurigo

  • Asia-Pacific: Singapore

Ogni location offre lo stesso uplink da 10 Gbps, mix Tier-1 e SLA di uptime al 99,95% SLA. L'unica variabile è la distanza.

Application Details

Versione: Non specificata

OS: Ubuntu Server 24.04

Minimum RAM: 1 GB

IP Types: IPv6, IPv4

Distribuisci VictoriaLogs ora: il tuo database di log e le dashboard sono pronti in pochi minuti.

Note e riferimenti: Porta predefinita di VictoriaLogs 9428 e /metrics endpoint, esempi di ingest e data model sono documentati da VictoriaMetrics. Le porte predefinite per vmauth 8427, vmalert 8880, VictoriaMetrics single-node 8428, and Grafana 3000 con il flusso di primo accesso sono documentate nelle guide ufficiali.

Importante: responsabilità di configurazione e dominio

Hai accesso SSH/root completo su ogni OCA. Questa libertà significa anche che le tue modifiche possono break l'app. Leggi questa sezione prima di toccare le configurazioni.

  • Il dominio lo gestisci tu. Non vendiamo né ospitiamo domini/DNS. Se l'app richiede un dominio, devi puntare il tuo dominio al server (A/AAAA/CNAME e MX/TXT se necessario). Il rilascio di SSL e molte dashboard dipendono dalla correttezza di questa configurazione.

  • Cambiare il dominio o l'hostname dopo l'installazione non è un'operazione semplice. Molte OCA scrivono il dominio nei file di configurazione (.env, reverse proxy, URL dell'app). Se lo cambi, aggiorna anche:

    • Reverse proxy (Nginx/Caddy) e certificati TLS

    • "URL esterno"/URL base dell'app e URL di callback/webhook

    • Tutti i link hardcoded nell'app o nei componenti aggiuntivi

  • Credentials matter. Rinominare l'amministratore predefinito, ruotare le password o cambiare le porte dei servizi senza aggiornare la configurazione dell'app può bloccarti fuori o interrompere i servizi. Tieni le credenziali al sicuro e sincronizzate tra l'app, il proxy e le eventuali integrazioni.

  • Le modifiche ai nameserver possono causare downtime. Spostare il dominio su nuovi nameserver o modificare i record NS avvia ritardi di propagazione. Pianifica le modifiche, abbassa il TTL in anticipo e verifica i record A/AAAA prima di procedere.

  • Le modifiche a firewall e porte possono bloccare l'accesso. Se modifichi SSH, HTTP/HTTPS, RDP o le porte dell'app, aggiorna di conseguenza firewall (UFW/CSF/security group) e regole del reverse proxy.

  • Le porte email (SMTP) sono bloccate per impostazione predefinita. Le porte di posta in uscita (es., 25/465/587) may be bloccate per prevenire abusi. Se la tua OCA deve inviare email, richiedi l'accesso SMTP al supporto oppure usa un provider di posta transazionale (SendGrid/Mailgun/SES) tramite API o SMTP approvato.

  • Email & allowlists. Se l'app invia email o riceve webhook, cambiare IP o hostname può influire sulla deliverability o sulle allowlist. Aggiorna SPF/DKIM/DMARC e qualsiasi allowlist di IP.

  • Prima di qualsiasi modifica importante: fai uno snapshot. Usa il snapshot/backup prima di tutto. Se un plugin, un aggiornamento o una modifica alla configurazione causa problemi, puoi ripristinare in pochi minuti.

  • Support scope. Forniamo il server e l'immagine OCA preinstallata. La configurazione a livello applicativo (domini, DNS, impostazioni dell'app, plugin e codice personalizzato) sono di responsabilità dell'utente.

Regola pratica rapida: if you touch dominio, porte, password, hostname o configurazioni proxy/SSL, aggiorna anche le impostazioni dell'applicazione di conseguenza, e fai uno snapshot prima.

Installation

  • Repository VictoriaMetrics clonato da GitHub in /root/VictoriaLogs
  • Docker e dipendenze installati
  • Servizio systemd creato victoria-logs per gestire il container VictoriaLogs tramite i comandi make

Commands

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

Access URLs

  • VictoriaLogs nodo singolo → http://<SERVER-IP>:9428
  • Grafana → http://<SERVER-IP>:3000
  • VictoriaMetrics nodo singolo → 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

Documentation

  • https://docs.victoriametrics.com/victorialogs/

More in Monitoring

Related apps.

Ackee

Ackee
Beszel Hub

Beszel Hub
CheckCle

CheckCle
Checkmate

Checkmate

Esegui il deploy di VictoriaLogs ora. From $2.48/mo.

Deploy a VPS Vedi tutti i piani