Aperçu
VictoriaJournaux sur Cloudzy vous offre une base de données de journaux rapide et auto-hébergée que vous contrôlez. Faites tourner un seul nœud pour le développement ou une boîte spacieuse pour la production, puis pointez Vecteur, Peu courant, ou syslog dessus et commencez à interroger en quelques secondes. Des processeurs virtuels EPYC dédiés, de la RAM DDR5, du NVMe pur et une liaison montante de 10 Gbit/s assurent l'ingestion et les requêtes rapides pendant les pics de trafic. La facturation horaire signifie que vous pouvez évoluer pendant les heures chargées et revenir plus tard.
Description
Cette image en un clic est expédiée VictoriaJournaux à l'intérieur de Docker avec un wrapper systemd léger, ainsi que des compagnons pratiques comme Grafana, Vecteur, vmauth, vmalert, Gestionnaire d'alertes, et Nœud unique VictoriaMetrics pour les métriques. VictoriaLogs écoute sur son port HTTP natif et est prêt à accepter les journaux et à répondre immédiatement aux requêtes. Consultez la documentation officielle pour connaître le modèle de données, les méthodes d'ingestion et les modèles de requête.
Accéder à l'interface web
Commencez par visiter les services déjà exécutés sur votre serveur. Remplacer <SERVEUR-IP> avec l'adresse IP de votre instance.
- VictoriaJournaux: http://<SERVER-IP>:9428 (ingestion, requêtes et métriques à /métrique).
- Grafana: http://<SERVER-IP>:3000 (la première connexion est administrateur /administrateur, puis changez-le).
- Nœud unique VictoriaMetrics: http://<SERVER-IP>:8428 pour les métriques compatibles Prometheus.
- vmalert Interface utilisateur et API : http://<SERVER-IP>:8880.
- vmauth porte: http://<SERVER-IP>:8427 pour l'authentification et le routage.
- Gestionnaire d'alertes: http://<SERVER-IP>:9093.
- API et interface utilisateur vectorielles: http://<SERVER-IP>:8686 si activé dans vecteur configuration.
Contrôles de service pour les opérations du premier jour :
| sudo systemctl commencer victoria-journaux sudo systemctl arrêt victoria-journaux sudo systemctl statut victoria-journaux docker ps |
Fonctionnalités avancées
Voici les mises à niveau pratiques importantes pour une base de données de journaux sur le calcul que vous possédez. Ils réduisent la latence des requêtes, maintiennent l’ingestion fluide pendant les pics et vous permettent de revenir en arrière rapidement si une mise à jour se comporte mal.
- Processeurs virtuels dédiés et RAM DDR5 pour éviter les blocages dus à des voisins bruyants lors d'écritures et de lectures simultanées.
- Stockage NVMe pur pour des IOPS élevées sur les WAL, les constructions d'index et les compactages.
- 10 Gbps network port pour les expéditeurs à tarifs élevés et de nombreux visualiseurs de tableaux de bord.
- Instantanés et restaurations à la demande avant les mises à niveau ou les modifications de schéma.
- Facturation horaire Cela signifie que les clones de test ou de test de charge ne coûtent que les heures pendant lesquelles vous les conservez.
Un seul redémarrage applique tout redimensionnement. Aucune migration de données ou modification DNS nécessaire.
Simplicité d'usage
Vous obtenez un tableau de bord clair pour redémarrer, prendre des instantanés ou migrer des régions. Indiquer Vecteur or Peu courant 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 recettes sont dans la documentation, et vous pouvez garder les choses simples avec les champs par défaut et ajouter une structure au fil du temps.
Objectif performance
Si votre équipe intègre Grafana les panneaux dans des pages d'état publiques ou des portails internes, un délai réduit pour le premier octet sur les panneaux et des requêtes ad hoc plus rapides permettent aux pages de paraître instantanées. Les E/S NVMe et une liaison montante de 10 Gbit/s maintiennent les temps de réponse stables lorsque plusieurs utilisateurs exécutent des requêtes sur de grandes fenêtres.
Contrôle total du site
Vous avez la racine. Ajuster la rétention, élaguer les index, configurer vmauth utilisateurs et envoyer des alertes via vmalert et Gestionnaire d'alertes. Le conteneur VictoriaLogs vit sous /root/VictoriaLogs, géré par une unité systemd qui appelle les cibles Makefile, les mises à jour sont donc prévisibles et réversibles. Utiliser docker ps pour inspecter les conteneurs ou étendre la pile avec vos propres fichiers de composition.
Outils puissants
Cette image inclut ou s'associe aux éléments suivants afin que vous puissiez vous concentrer sur la qualité des bûches et non sur l'échafaudage.
- VictoriaJournaux Nœud unique pour l'ingestion et les requêtes à grande vitesse sur le port 9428.
- Grafana pour les tableaux de bord et l'exploration ad hoc sur le port 3000.
- Nœud unique VictoriaMetrics lorsque vous souhaitez également le stockage des métriques sur le port 8428.
- vmauth pour ajouter une authentification et acheminer 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.
- Vecteur en tant qu'expéditeur simple à haut débit avec une API à 8686 lorsqu'elle est activée.
Portée mondiale
Choisissez la région la plus proche de vos utilisateurs. Cloudzy exploite des points de présence dans :
- Amérique du Nord: New York, Dallas, Miami, Utah, Las Vegas
- Europe: Londres, Amsterdam, Francfort, Zurich
- Asie-Pacifique: Singapour
Chaque emplacement offre la même liaison montante de 10 Gbit/s, le même mix de niveau 1 et le même SLA de disponibilité de 99,95 %. La seule variable est la distance.
Détails de la demande
Version : Non spécifié
Système d'exploitation : serveur Ubuntu 24.04
RAM minimale : 1 Go
Types IP : IPv6, IPv4
Déployez VictoriaLogs maintenant : votre base de données de journaux et vos tableaux de bord sont prêts en quelques minutes.
Notes et références : VictoriaLogs port par défaut 9428 et /métrique le point de terminaison, les exemples d’ingestion et le modèle de données sont documentés par VictoriaMetrics. Ports par défaut pour vmauth 8427, vmalert 8880, Nœud unique VictoriaMetrics 8428, et Grafana 3000 avec 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 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 :
- Proxy inverse (Nginx/Caddy) et 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 les modules complémentaires
- Les références comptent. 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 t'enfermer dehors ou arrêter des services. Garde tes identifiants en sécurité et synchronisés entre l'application, le proxy et les éventuelles intégrations.
- Les modifications du serveur de noms peuvent entraîner des temps d'arrêt. 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.
- Les modifications du pare-feu/port peuvent interrompre 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 de messagerie (SMTP) sont restreints par défaut. Ports de courrier sortant (par exemple, 25/465/587) peut être fermé pour éviter les abus. Si votre OCA doit envoyer un courrier électronique, demander un 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 autorisées. 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 tout grand changement : prenez un instantané. Utilisez le panneau instantané/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.
- Portée du support. Nous fournissons le serveur et l'image OCA préinstallée. La configuration au niveau de l'application (domaines, DNS, paramètres d’application, plugins et code personnalisé) relève de la responsabilité de l’utilisateur.
Règle générale rapide : si tu touches 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
- Le dépôt VictoriaMetrics cloné de GitHub vers
/root/VictoriaLogs - Docker installé et dépendances
- Service système créé
victoria-logspour gérer le conteneur VictoriaLogs via les 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 URL
- 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 - Gestionnaire d'alertes →
http://<SERVER-IP>:9093 - Interface utilisateur vectorielle →
http://<SERVER-IP>:8686
Documentation
- https://docs.victoriametrics.com/victorialogs/
