Présentation
VictoriaLogs sur Cloudzy vous donne une base de données de logs rapide et auto-hébergée, entièrement sous votre contrôle. Démarrez un nœud unique pour le développement ou une instance plus puissante pour la production, puis pointez Vector, Fluent Bit, ou syslog vers elle et commencez à interroger vos données en quelques secondes. Des vCPU EPYC dédiés, de la RAM DDR5, du NVMe pur et une liaison montante à 10 Gbps maintiennent l'ingestion et les requêtes réactives même aux heures de pointe. La facturation à l'heure vous permet d'augmenter la capacité pour les périodes chargées, puis de la réduire ensuite.
Description
Cette image One-Click intègre VictoriaLogs dans Docker avec un wrapper systemd léger, ainsi que des outils complémentaires pratiques comme Grafana, Vector, vmauth, vmalert, Alertmanager, et VictoriaMetrics nœud unique pour les métriques. VictoriaLogs écoute sur son port HTTP natif et est prêt à accepter des logs et à répondre aux requêtes immédiatement. Consultez la documentation officielle pour le modèle de données, les méthodes d'ingestion et les patterns de requêtes.
Accéder à l'interface web
Commencez par accéder aux services déjà actifs sur votre serveur. Remplacez <SERVER-IP> par l'IP de votre instance.
- VictoriaLogs: http://<SERVER-IP>:9428 (ingestion, requêtes et métriques sur /metrics).
- Grafana: http://<SERVER-IP>:3000 (la première connexion utilise admin /admin, pensez à modifier le mot de passe ensuite).
- VictoriaMetrics nœud unique: http://<SERVER-IP>:8428 pour les métriques compatibles Prometheus.
- vmalert Interface & API : http://<SERVER-IP>:8880.
- vmauth gateway : http://<SERVER-IP>:8427 pour l'authentification et le routage.
- Alertmanager: http://<SERVER-IP>:9093.
- API Vector & UI: http://<SERVER-IP>:8686 si activé dans vector config.
Contrôles de service pour les opérations du premier jour :
| sudo systemctl Démarrer victoria-logs sudo systemctl stop victoria-logs sudo systemctl status victoria-logs docker ps |
Fonctionnalités avancées
Voici les améliorations concrètes qui comptent pour une base de données de logs sur une infrastructure que vous gérez. Elles réduisent la latence des requêtes, maintiennent l'ingestion fluide lors des pics, et permettent un retour arrière rapide si une mise à jour pose problème.
- Des vCPUs dédiés et DDR5 RAM pour éviter les blocages dus aux interférences entre écritures et lectures concurrentes.
- Stockage NVMe pur pour un IOPS élevé sur le WAL, la construction d'index et les compactions.
- 10 Gbps network port pour les agents à débit élevé et les nombreux utilisateurs de tableaux de bord.
- Snapshots à la demande et retour arrière avant les mises à jour ou les changements de schéma.
- Facturation à l'heure les clones de staging ou de test de charge ne coûtent que le temps où vous les conservez.
Un simple redémarrage applique tout redimensionnement. Aucune migration de données ni modification de DNS nécessaire.
Facilité d'utilisation
Un tableau de bord clair vous permet de redémarrer, de prendre un snapshot ou de migrer entre régions. Pointez Vector or Fluent Bit to http://<SERVER-IP>:9428 pour l'ingestion HTTP JSON, ou activez les récepteurs syslog sur VictoriaLogs si vous préférez TCP ou UDP 514. Des exemples de configuration sont disponibles dans la documentation, et vous pouvez démarrer simplement avec les champs par défaut, puis ajouter de la structure au fil du temps.
Priorité aux performances
Si votre équipe intègre des panneaux Grafana dans des pages de statut publiques ou des portails internes, réduire le temps avant le premier octet et accélérer les requêtes ad hoc rend les pages instantanées. NVMe I/O et une liaison montante à 10 Gbps maintiennent les temps de réponse stables lorsque plusieurs utilisateurs exécutent des requêtes sur de grandes plages temporelles.
Contrôle total du site
Vous avez l'accès root. Ajustez la rétention, élaguez les index, configurez les utilisateurs vmauth et routez les alertes via vmalert et Alertmanager. Le conteneur VictoriaLogs se trouve sous /root/VictoriaLogs, géré par une unité systemd qui appelle les cibles du Makefile, ce qui rend les mises à jour prévisibles et réversibles. Utilisez docker ps pour inspecter les conteneurs, ou étendez la stack avec vos propres fichiers compose.
Des outils puissants
Cette image inclut ou associe les éléments suivants pour que vous puissiez vous concentrer sur la qualité des logs, pas sur la configuration initiale.
- VictoriaLogs nœud unique pour l'ingestion et les requêtes à haute vitesse sur le port 9428.
- Grafana pour les tableaux de bord et l'exploration ad hoc sur le port 3000.
- VictoriaMetrics nœud unique si vous souhaitez également stocker des métriques sur le port 8428.
- vmauth pour ajouter l'authentification et router le trafic multi-tenant sur le port 8427.
- vmalert pour évaluer les règles d'alerte et exposer les API d'alerte sur le port 8880.
- Vector comme collecteur simple et à haut débit avec un API sur le port 8686 lorsqu'il est activé.
Couverture mondiale
Choisissez la région la plus proche de vos utilisateurs. Cloudzy dispose de points de présence à :
- Amérique du Nord : New York City, Dallas, Miami, Utah, Las Vegas
- Europe : Londres, Amsterdam, Francfort, Zurich
- Asie-Pacifique : Singapour
Chaque site offre le même uplink 10 Gbps, un mix Tier-1 et un SLA de disponibilité à 99,95 %. La seule variable est la distance.
Détails de l'application
Version : non spécifiée
OS : Ubuntu Server 24.04
Minimum RAM : 1 GB
Types d'IP : IPv6, IPv4
Déployez VictoriaLogs maintenant : votre base de données de logs et vos tableaux de bord sont prêts en quelques minutes.
Notes et références : Le port par défaut 9428 de VictoriaLogs et /metrics l'endpoint, les exemples d'ingestion et le modèle de données sont documentés par VictoriaMetrics. Les ports par défaut pour vmauth 8427, vmalert 8880, VictoriaMetrics nœud unique 8428, et Grafana 3000 avec le flux de première connexion sont documentés dans leurs guides officiels.
Important : configuration et responsabilités liées au domaine
Vous disposez d'un accès SSH/root complet sur chaque OCA. Cela implique aussi que vos modifications peuvent casser l'application. Lisez ceci avant de modifier les configurations.
- Vous gérez le domaine. Nous ne vendons ni n'hébergeons de domaines/DNS. Si l'application nécessite un domaine, vous devez faire pointer votre domaine vers le serveur (A/AAAA/CNAME, et MX/TXT si nécessaire). L'émission de SSL et de nombreux tableaux de bord dépendent de l'exactitude de cette configuration.
- Changer le domaine ou le nom d'hôte après l'installation n'est pas une opération anodine. De nombreuses OCAs intègrent le domaine dans leurs fichiers de configuration (.env, reverse proxy, URLs applicatifs). Si vous le modifiez, mettez également à jour :
- Le reverse proxy (Nginx/Caddy) et les certificats TLS
- Les URLs "externes"/de base et les URLs de callback/webhook de l'application
- Tous les liens codés en dur dans l'application ou ses extensions
- Les identifiants sont importants. Renommer l'administrateur par défaut, changer les mots de passe ou modifier les ports des services sans mettre à jour la configuration de l'application peut vous bloquer l'accès ou interrompre des services. Gardez vos identifiants à jour et cohérents entre l'application, le proxy et les intégrations.
- Modifier les serveurs de noms peut provoquer une interruption de service. Migrer votre domaine vers de nouveaux serveurs de noms ou modifier les enregistrements NS déclenche des délais de propagation. Planifiez vos changements, réduisez le TTL à l'avance et vérifiez les enregistrements A/AAAA avant de basculer.
- Modifier le pare-feu ou les ports peut couper l'accès. Si vous modifiez SSH, HTTP/HTTPS, RDP ou les ports applicatifs, mettez à jour les pare-feux (UFW/CSF/groupes de sécurité) et les règles du reverse proxy en conséquence.
- Les ports SMTP sont restreints par défaut. Les ports de messagerie sortante (par ex., 25/465/587) peuvent être bloqués pour prévenir les abus. Si votre OCA doit envoyer des e-mails, demandez l'accès SMTP. auprès du support ou utilisez un fournisseur de messagerie transactionnelle (SendGrid/Mailgun/SES) via API ou un SMTP approuvé.
- E-mail et listes d'autorisation. Si l'application envoie des e-mails ou reçoit des webhooks, changer d'IP ou de nom d'hôte peut affecter la délivrabilité ou les listes d'autorisation. Mettez à jour SPF/DKIM/DMARC ainsi que toutes les listes d'IP autorisées.
- Avant toute modification importante : prenez un snapshot. Utilisez la fonctionnalité capture instantanée/sauvegarde du panneau en premier. Si un plugin, une mise à jour ou une modification de configuration tourne mal, vous pouvez revenir en arrière en quelques minutes.
- Périmètre du support. Nous fournissons le serveur et l'image OCA préinstallée. La configuration au niveau applicatif (domaines, DNS, paramètres de l'application, plugins et code personnalisé) relève de la responsabilité de l'utilisateur.
Règle simple : si vous touchez le domaine, les ports, les mots de passe, les noms d'hôtes ou les configurations proxy/SSL, pensez aussi à mettre à jour les paramètres de l'application, et faites un snapshot au préalable.
Installation
- Dépôt VictoriaMetrics cloné depuis GitHub vers
/root/VictoriaLogs - Docker et ses dépendances installés
- Service systemd créé
victoria-logspour gérer le conteneur VictoriaLogs via des commandes make
Commandes
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
Accéder aux URLs
- VictoriaLogs nœud unique →
http://<SERVER-IP>:9428 - Grafana →
http://<SERVER-IP>:3000 - VictoriaMetrics nœud unique →
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/
