Saltar para o conteúdo principal
50% de desconto todos os planos, tempo limitado. A partir de $2.48/mo
VictoriaLogs

VictoriaLogs

VictoriaLogs é um banco de dados de logs de alto desempenho. Alternativa ao Loki mais rápida e econômica, com a linguagem de consulta LogsQL e labels no estilo Prometheus. Open-source, escrito em Go, pela equipe VictoriaMetrics. Desenvolvido para agregação de logs em escala multi-TB em hardware comum.

Em resumo

2k

Estrelas no GitHub

223

Visualizações de página

78

Instalações ativas

Licença Apache-2.0 Versão Latest OS Ubuntu Server 24.04 LTS Min RAM 1 GB IP IPV4,IPV6

As instalações ativas são dados de amostra (pré-visualização); a métrica real será conectada antes do lançamento.

Visão geral

VictoriaLogs no Cloudzy oferece um banco de dados de logs auto-hospedado e rápido, sob seu controle. Inicie um nó único para desenvolvimento ou uma máquina mais robusta para produção e aponte Vector, Fluent Bit, ou conecte via syslog e comece a consultar em segundos. vCPUs EPYC dedicados, DDR5 RAM, NVMe puro e um uplink de 10 Gbps mantêm a ingestão e as consultas ágeis mesmo nos picos de tráfego. A cobrança por hora permite aumentar a capacidade nos momentos de maior demanda e reduzir depois.

Descrição

Esta imagem One-Click já vem com VictoriaLogs dentro do Docker com um wrapper systemd leve, além de complementos úteis como Grafana, Vector, vmauth, vmalert, Alertmanager, e nó único VictoriaMetrics para métricas. O VictoriaLogs escuta na porta HTTP nativa e está pronto para receber logs e responder a consultas imediatamente. Consulte a documentação oficial para o modelo de dados, métodos de ingestão e padrões de consulta. 

Aceda à interface web

Comece acessando os serviços que já estão em execução no seu servidor. Substitua <SERVER-IP> pelo IP da sua instância.

  • VictoriaLogs: http://<SERVER-IP>:9428 (ingestão, consultas e métricas em /metrics).

  • Grafana: http://<SERVER-IP>:3000 (primeiro acesso é admin /admin, depois mude).

  • nó único VictoriaMetrics: http://<SERVER-IP>:8428 para métricas compatíveis com Prometheus.

  • vmalert Interface e API: http://<SERVER-IP>:8880.

  • vmauth porta: http://<SERVER-IP>:8427 para autenticação e roteamento.

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

  • API de Vetor e Interface do Usuário: http://<SERVER-IP>:8686 se ativado em vector config. 

Controles de serviço para as operações iniciais:

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

Funcionalidades avançadas

Aqui estão as melhorias práticas que fazem diferença em um banco de dados de logs em infraestrutura própria. Elas reduzem a latência das consultas, mantêm a ingestão estável durante picos e permitem reverter rapidamente se uma atualização causar problemas.

  • vCPUs e DDR5 RAM dedicados para evitar travamentos por concorrência em escritas e leituras simultâneas.

  • Armazenamento NVMe puro para alto IOPS em WAL, construção de índices e compactações.

  • 10 Gbps network port para shippers de alta taxa e muitos usuários simultâneos no dashboard.

  • Snapshots sob demanda e rollback antes de atualizações ou mudanças de esquema.

  • Faturação à hora significa que clones para staging ou testes de carga custam apenas pelas horas em que ficam ativos.
    Uma única reinicialização aplica qualquer redimensionamento. Nenhuma migração de dados ou edição de DNS é necessária.

Facilidade de uso

Você tem um painel limpo para ligar/desligar, tirar snapshots ou migrar entre regiões. Aponte Vector or Fluent Bit to http://<SERVER-IP>:9428 para ingestão via HTTP JSON, ou habilite receptores syslog no VictoriaLogs se preferir TCP ou UDP 514. Há exemplos de configuração na documentação, e você pode começar com os campos padrão e adicionar estrutura ao longo do tempo. 

Foco em Desempenho

Se sua equipe está incorporando painéis do Grafana em páginas de status públicas ou portais internos, menor tempo até o primeiro byte e consultas ad hoc mais rápidas fazem as páginas parecerem instantâneas. NVMe I/O e um uplink de 10 Gbps mantêm os tempos de resposta estáveis quando vários usuários executam consultas em janelas de tempo grandes.

Controlo total do site

Você tem acesso root. Ajuste a retenção, remova índices desnecessários, configure usuários vmauth e configure alertas via vmalert e Alertmanager. O contêiner VictoriaLogs fica em /root/VictoriaLogs, gerenciado por uma unidade systemd que chama os alvos do Makefile, tornando as atualizações previsíveis e reversíveis. Use docker ps para inspecionar os contêineres ou expandir o stack com seus próprios arquivos compose. 

Ferramentas poderosas

Esta imagem inclui ou integra os seguintes componentes para que você foque na qualidade dos logs, não na configuração inicial.

  • VictoriaLogs nó único para ingestão e consulta de alta velocidade na porta 9428.

  • Grafana para dashboards e exploração ad-hoc na porta 3000.

  • nó único VictoriaMetrics quando você também quiser armazenamento de métricas na porta 8428.

  • vmauth para adicionar autenticação e rotear tráfego multi-tenant na porta 8427.

  • vmalert para avaliar regras de alerta e expor API de alertas na porta 8880.

  • Vector como um shipper simples e de alto throughput com um API na porta 8686, quando habilitado.

Alcance global

Escolha a região mais próxima dos seus usuários. A Cloudzy opera pontos de presença em:

  • América do Norte: Nova York, Dallas, Miami, Utah, Las Vegas

  • Europa: Londres, Amsterdã, Frankfurt, Zurique

  • Ásia-PacíficoSingapura

Cada localização oferece o mesmo uplink de 10 Gbps, mix Tier-1 e SLA de 99,95% de uptime SLA. A única variável é a distância.

Detalhes da Aplicação

Versão: Não especificada

SO: Ubuntu Server 24.04

RAM mínima: 1 GB

Tipos de IP: IPv6, IPv4

Implante VictoriaLogs agora: seu banco de dados de logs e dashboards ficam prontos em minutos.

Notas e referências: Porta padrão do VictoriaLogs 9428 e /metrics endpoint, exemplos de ingestão e modelo de dados são documentados pela VictoriaMetrics. As portas padrão para vmauth 8427, vmalert 8880, nó único VictoriaMetrics 8428, e Grafana 3000 com fluxo de primeiro login estão documentadas nos guias oficiais.

Importante: Responsabilidades de Configuração e Domínio

Tem acesso total SSH/root em cada OCA. Esse poder também significa que as suas alterações podem quebra a aplicação. Leia isto antes de alterar configurações.

  • Você gerencia o domínio. Não vendemos nem alojamos domínios/DNS. Se a aplicação precisar de um domínio, você deve apontar seu domínio para o servidor (A/AAAA/CNAME, e MX/TXT se for relevante). A emissão de SSL e muitos painéis dependem de isto estar correto.

  • Alterar o domínio/hostname após a instalação não é trivial. Muitas OCAs escrevem o domínio nas configurações (.env, reverse proxy, URLs da aplicação). Se o alterar, atualize também:

    • Proxy reverso (Nginx/Caddy) e certificados TLS

    • URL “externo” da aplicação/URL base e URLs de callback/webhook

    • Quaisquer links fixos no aplicativo ou em complementos

  • As credenciais são importantes. Renomear o administrador predefinido, rodar palavras-passe ou alterar portas de serviço sem atualizar a configuração da aplicação pode bloquear seu acesso ou parar serviços. Mantenha as credenciais seguras e sincronizadas entre a aplicação, o proxy e quaisquer integrações.

  • Alterações nos nameservers podem causar indisponibilidade. Mover o seu domínio para novos nameservers ou editar registos NS provoca atrasos de propagação. Planeie as alterações, baixe o TTL com antecedência e verifique os registos A/AAAA antes de mudar.

  • Edições no firewall/portas podem interromper o acesso. Se alterar as portas SSH, HTTP/HTTPS, RDP ou da aplicação, atualize as firewalls (UFW/CSF/grupos de segurança) e as regras de reverse-proxy em conformidade.

  • Portas de e-mail (SMTP) são restritas por padrão. Portas de envio de e-mail (ex.: 25/465/587) pode ser bloqueadas para evitar abusos. Se o seu OCA precisar enviar e-mail, solicite acesso SMTP. junto do suporte ou utilize um fornecedor de email transacional (SendGrid/Mailgun/SES) via API ou SMTP aprovado.

  • Email e listas de permissão. Se a aplicação enviar email ou receber webhooks, alterar IPs/hostnames pode afetar a entregabilidade ou as listas de permissões. Atualize SPF/DKIM/DMARC e quaisquer listas de IPs permitidos.

  • Antes de qualquer mudança importante: tire um snapshot. Use o captura de tela/backup primeiro. Se um plugin, atualização ou edição de configuração correr mal, pode reverter em minutos.

  • Escopo de suporte. Fornecemos o servidor e a imagem OCA pré-instalada. A gestão contínua configuração no nível da aplicação (domínios, DNS, configurações do app, plugins e código personalizado) são de responsabilidade do usuário.

Regra rápida: se tocar domínio, portas, palavras-passe, hostnames ou configurações de proxy/SSL, conte com atualizar também as definições da aplicação e faça um snapshot primeiro.


Instalação

  • Repositório VictoriaMetrics clonado de GitHub para /root/VictoriaLogs
  • Docker e dependências instalados
  • Serviço systemd criado victoria-logs para gerenciar o contêiner VictoriaLogs via comandos make

Comandos

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

Acessar URLs

  • VictoriaLogs nó único → http://<SERVER-IP>:9428
  • Grafana → http://<SERVER-IP>:3000
  • VictoriaMetrics nó único → 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

Documentação

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

Mais em Monitorização

Aplicações relacionadas.

Implante VictoriaLogs agora. A partir de $2,48/mês.