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 horaire 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.
Simplicité d'usage
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.
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é.
Portée 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
Tu obtiens un accès SSH/root complet sur chaque OCA. Ce pouvoir signifie aussi que tes modifications peuvent casser l'application. Lis bien ceci avant de bricoler les configs.
- Vous gérez le domaine. Nous ne vendons ni n'hébergeons de domaines/DNS. Si l'application a besoin d'un domaine, vous devez faire pointer votre domaine vers le serveur (A/AAAA/CNAME, et MX/TXT le cas échéant). L'émission du SSL et beaucoup de panneaux dépendent du fait que ce soit correct.
- Changer le domaine/hostname après l'installation n'a rien de trivial. Beaucoup d'OCA écrivent le domaine dans les configs (.env, reverse proxy, URL de l'application). Si tu le modifies, mets aussi à jour :
- Le reverse proxy (Nginx/Caddy) et les certificats TLS
- URL « externe »/URL de base de l'application et URL de callback/webhook
- Tous les liens codés en dur dans l'application ou ses extensions
- Les identifiants sont importants. Renommer l'admin par défaut, faire tourner les mots de passe ou changer les ports des services sans mettre à jour la config de l'application peut vous bloquer l'accès ou arrêter des services. Garde tes identifiants en sécurité et synchronisés entre l'application, le proxy et les éventuelles intégrations.
- Modifier les serveurs de noms peut provoquer une interruption de service. Déplacer ton domaine vers de nouveaux nameservers ou modifier les enregistrements NS déclenche des délais de propagation. Planifie tes changements, baisse le TTL en avance et vérifie les enregistrements A/AAAA avant de basculer.
- Modifier le pare-feu ou les ports peut couper l'accès. Si tu changes les ports SSH, HTTP/HTTPS, RDP ou ceux de l'application, mets à jour les pare-feux (UFW/CSF/security groups) 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 utilise un fournisseur d'e-mail transactionnel (SendGrid/Mailgun/SES) via API ou SMTP autorisé.
- E-mail et listes d'autorisation. Si l'application envoie des e-mails ou reçoit des webhooks, changer d'IP ou de hostname peut affecter la délivrabilité ou les allowlists. Mets à jour SPF/DKIM/DMARC et toutes les allowlists d'IP.
- Avant toute modification importante : prenez un snapshot. Utilisez la fonctionnalité capture instantanée/sauvegarde d'abord. Si un plugin, une mise à jour ou une modification de config tourne mal, tu peux 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 domaine, ports, mots de passe, hostnames ou configs proxy/SSL, prévois aussi de mettre à jour les réglages de l'application, et fais un snapshot d'abord.
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/
