AIOps sur VPS : monitoring IA auto-hébergé open source

Datadog et New Relic facturent par hôte, par Go, ou les deux. Pour un développeur solo ou une petite équipe qui gère un à cinq VPS, ces coûts s'accumulent vite sans vrai retour. Consultez la page de tarifs de Datadog et la page de tarifs de New Relic pour les prix actuels.

L'alternative : faire tourner toute votre pile de monitoring, d'analyse de logs et de réponse aux incidents sur un seul VPS. Des outils open source comme SigNoz, Grafana+Loki et Ollama vous offrent l'observabilité, la détection d'anomalies par IA et la remédiation automatisée. Coût total : le prix de votre VPS. Chez Virtua Cloud, cela commence à 24 EUR/mois pour un serveur 2 vCPU, 4 Go de RAM suffisant pour l'observabilité de base, ou 48 EUR/mois pour la pile complète sur un serveur 4 vCPU, 8 Go de RAM.

Cet article cartographie les cinq couches d'une pile AIOps auto-hébergée. Ce n'est pas un tutoriel pas à pas. Chaque section explique le rôle de la couche, recommande des outils et renvoie vers le guide dédié où vous installez et configurez tout en détail.

Qu'est-ce que l'AIOps et pourquoi est-ce important pour les opérateurs VPS ?

AIOps signifie utiliser l'IA et le machine learning pour automatiser le monitoring, l'analyse de logs, la détection d'anomalies et la réponse aux incidents. Pour les opérateurs VPS, cela remplace le cycle manuel qui consiste à vérifier des tableaux de bord, lire des logs et redémarrer des services. Au lieu de payer des plateformes SaaS d'entreprise, vous faites tourner des outils open source sur l'infrastructure que vous gérez déjà. Vos données restent sur votre serveur. Vos coûts restent fixes.

La définition entreprise de l'AIOps se concentre sur la corrélation de milliers d'alertes à travers des centaines de microservices. Ce n'est pas le sujet de ce guide. Pour les opérateurs VPS qui gèrent un à cinq serveurs, l'AIOps signifie :

Collecter métriques, logs et traces en un seul endroit au lieu de se connecter en SSH sur chaque serveur.
Faire tourner un LLM local pour repérer des patterns dans les logs que grep et les regex ne détectent pas.
Automatiser les réponses aux pannes courantes comme un disque plein, un processus planté ou une fuite mémoire.
Obtenir un retour IA sur le code avant qu'il n'arrive en production.

La pile comporte cinq couches. Vous n'avez pas besoin de toutes les utiliser. Commencez par l'observabilité, ajoutez l'analyse IA quand le volume de logs rend la revue manuelle pénible, et progressez vers l'auto-réparation à mesure que vous gagnez en confiance.

Combien coûte le monitoring auto-hébergé par rapport à Datadog ?

Une pile AIOps auto-hébergée sur un VPS Virtua Cloud coûte entre 24 et 96 EUR/mois selon le nombre de couches déployées. C'est le coût total : serveur, stockage, bande passante et tous les logiciels. Les alternatives commerciales comme Datadog utilisent des modèles de tarification par hôte et par Go qui évoluent avec votre infrastructure. Leurs coûts augmentent à mesure que vous ajoutez des hôtes, ingérez plus de logs ou activez le tracing APM.

Fonctionnalité	SaaS commercial (Datadog, New Relic)	Auto-hébergé (VPS Virtua Cloud)
Monitoring d'infrastructure	Tarification par hôte, par palier	Inclus (Prometheus + Grafana)
Gestion des logs	Frais par Go d'ingestion + indexation par événement	Inclus (Loki ou OpenObserve)
APM / Traces	Frais supplémentaires par hôte	Inclus (SigNoz ou Tempo)
Analyse de logs par IA	Indisponible ou module complémentaire séparé	Inclus (Ollama + LLM local)
Alerting	Inclus	Inclus (Alertmanager)
Rétention des données	Limites définies par le fournisseur (jours à mois)	Vous décidez. Le disque est la limite.
Localisation des données	US/EU (au choix)	Votre VPS. Votre juridiction.
Modèle tarifaire	Par hôte + par Go, croît avec l'usage	Coût VPS mensuel fixe

Pour les tarifs commerciaux actuels, consultez les tarifs de Datadog et les tarifs de New Relic. Les coûts auto-hébergés dépendent uniquement du plan VPS que vous choisissez.

La colonne auto-hébergée suppose un plan vCS-8 unique (4 vCPU, 8 Go de RAM, 160 Go SSD) faisant tourner la pile d'observabilité complète via Docker Compose. Si vous n'avez besoin que de métriques et logs de base, un vCS-4 (2 vCPU, 4 Go de RAM) à 24 EUR/mois gère Grafana + Loki + Prometheus pour de petites charges de travail.

Pour les équipes qui veulent aussi la couche d'analyse IA (Ollama avec un modèle de 3-7 milliards de paramètres), le VPS de 8 Go est le minimum. Ollama avec Gemma 2 (2B) tourne avec environ 2 Go de RAM, laissant assez de marge pour SigNoz ou Grafana à côté.

Quels outils d'observabilité open source fonctionnent le mieux sur un VPS ?

La couche d'observabilité collecte les métriques, les logs et les traces de vos applications et de votre infrastructure. Trois piles open source dominent cet espace : SigNoz, OpenObserve et Grafana + Loki. Chacune fait des compromis différents entre fonctionnalités, utilisation des ressources et complexité.

Outil	Idéal pour	Logs	Métriques	Traces	Backend	RAM min	Complexité
SigNoz	Remplacement APM complet de Datadog	Oui	Oui	Oui	ClickHouse	4 Go	Moyenne
OpenObserve	Agrégation de logs légère	Oui	Oui	Oui	Natif (Rust)	~1 Go	Faible
Grafana + Loki + Prometheus	Écosystème établi, extensibilité	Oui (Loki)	Oui (Prometheus)	Via Tempo	Multiple	2-4 Go	Plus élevée

Les trois supportent OpenTelemetry pour l'instrumentation. Cela signifie que vous pouvez instrumenter votre application une seule fois et changer de backend plus tard sans modifier le code applicatif.

Quand choisir SigNoz plutôt qu'OpenObserve ?

Choisissez SigNoz quand vous avez besoin d'un monitoring de performance applicative complet : traces distribuées, cartes de services, suivi des erreurs et logs corrélés. SigNoz utilise ClickHouse comme moteur de stockage, qui gère bien les données à haute cardinalité mais demande plus de RAM. Un déploiement Docker Compose nécessite au moins 4 Go de RAM dédiés à SigNoz, avec 8 Go recommandés pour les charges de production incluant ClickHouse.

Choisissez OpenObserve quand votre besoin principal est l'agrégation et la recherche de logs. OpenObserve se présente comme un binaire unique écrit en Rust. Il démarre avec moins de 1 Go de RAM dans une configuration Docker Compose de base. Il annonce des coûts de stockage 140 fois inférieurs à Elasticsearch grâce à la compression en colonnes. Si vous êtes un indie hacker qui fait tourner une seule application et que vous voulez une recherche de logs rapide sans la charge de ClickHouse, OpenObserve est le chemin le plus léger.

Les deux outils ont des interfaces web pour les requêtes et les tableaux de bord. SigNoz offre une expérience plus complète, proche de Datadog. OpenObserve est plus léger et plus rapide à déployer.

Grafana + Loki est-il toujours la meilleure option en 2026 ?

Grafana + Loki reste l'option la plus flexible. Ce n'est pas la plus simple à mettre en place, mais elle l'emporte sur l'étendue de l'écosystème. Des milliers de tableaux de bord communautaires existent pour chaque service imaginable. Les exporteurs Prometheus couvrent les bases de données, les serveurs web, les métriques matérielles et les métriques applicatives personnalisées. Loki gère l'agrégation de logs avec un langage de requête LogQL qui reflète PromQL.

Le compromis : plus de composants. Une pile Grafana minimale implique de faire tourner Grafana (interface), Prometheus (métriques) et Loki (logs) comme des conteneurs séparés. Ajoutez Promtail ou Alloy comme agent de collecte de logs. Cela fait quatre conteneurs avant même d'ajouter votre propre application. Sur un VPS de 4 Go, cette pile tient mais laisse peu de marge.

Choisissez Grafana + Loki quand vous connaissez déjà l'écosystème, que vous avez besoin de personnalisation poussée ou que vous voulez intégrer des outils qui ne supportent que l'export de métriques Prometheus.

Comment ajouter l'analyse de logs par IA à votre pile de monitoring ?

Faites tourner un LLM local via Ollama pour analyser les logs sans envoyer de données à une API externe. Ollama sert des modèles comme Gemma 2 (2B), Llama 3.2 (3B) ou Qwen 2.5 (7B) via une API HTTP locale. Un script ou une tâche cron alimente le modèle avec des extraits de logs et lui demande d'identifier des anomalies, de résumer les patterns d'erreurs ou de suggérer des causes racines. Pas de coûts d'API. Pas de données qui quittent votre serveur.

C'est là que l'AIOps auto-hébergé diverge du monitoring traditionnel. Grafana et Prometheus vous disent ce qui s'est passé. Un LLM local vous aide à comprendre pourquoi.

Ce que fait la couche d'analyse IA :

Détection d'anomalies : alimentez le modèle avec les 1 000 dernières lignes de logs avec un prompt du type « identifie les patterns inhabituels ou les erreurs dans ces logs ». Le modèle signale les entrées qui dévient des patterns normaux.
Résumé d'erreurs : quand un incident génère des centaines de lignes de logs, le LLM les condense en un résumé lisible avec la cause racine probable.
Reconnaissance de patterns : avec le temps, des patterns d'erreurs récurrents émergent. Le LLM peut regrouper les erreurs liées et identifier les problèmes récurrents qui ne déclencheraient pas d'alertes basées sur des seuils.

Dimensionnement des modèles pour VPS :

Modèle	Paramètres	Utilisation RAM	Vitesse (tokens/sec, CPU)	Idéal pour
Gemma 2 (2B)	2,6 Md	~2 Go	~15-20	Triage rapide de logs sur VPS à faible RAM
Llama 3.2 (3B)	3,2 Md	~2,5 Go	~10-15	Analyse et vitesse équilibrées
Qwen 2.5 (7B)	7 Md	~5 Go	~5-8	Analyse approfondie, nécessite un VPS de 8 Go+

Sur un VPS 4 vCPU sans GPU, l'inférence se fait uniquement sur CPU. Un modèle de 2-3 Md de paramètres produit une analyse de logs utile en 5 à 15 secondes par requête. C'est assez rapide pour une analyse par lots toutes les quelques minutes, pas pour du streaming temps réel.

Ce n'est pas de la magie. Les petits modèles hallucinent. Ils manquent de contexte. Ils signalent parfois des entrées de logs normales comme suspectes. Traitez l'analyse de logs par LLM comme un assistant de triage, pas comme un oracle. Vérifiez toujours ses suggestions en les confrontant aux logs et métriques réels.

Qu'est-ce qu'un VPS auto-réparateur et comment fonctionne-t-il ?

Un VPS auto-réparateur détecte et remédie automatiquement aux pannes courantes sans intervention humaine. L'architecture de base : Prometheus surveille les métriques, Alertmanager déclenche des alertes quand des seuils sont franchis, et un récepteur de webhooks exécute des scripts de remédiation. Ajouter un LLM à cette boucle permet de gérer des pannes qui ne correspondent pas à des règles prédéfinies.

Le pipeline d'auto-réparation :

Prometheus collecte les métriques toutes les 15 secondes (CPU, mémoire, disque, état des processus, taux d'erreurs HTTP).
Les règles d'alerte définissent des conditions : utilisation du disque au-dessus de 90 %, un service qui ne répond plus depuis 60 secondes, utilisation mémoire maintenue au-dessus de 95 %.
Alertmanager reçoit l'alerte et la route vers un endpoint webhook.
Le gestionnaire de remédiation reçoit le webhook. Pour les conditions connues (disque plein, service planté), il exécute un script prédéfini. Pour les conditions inconnues, il appelle le LLM local via Ollama avec le contexte de l'alerte et les logs récents, en demandant un diagnostic et une suggestion de remédiation.
Exécution (optionnel) : pour les remédiations connues à haute confiance (redémarrer un service, vider les fichiers temporaires, effectuer la rotation des logs), le gestionnaire exécute automatiquement. Pour les actions suggérées par le LLM, il envoie la suggestion à votre canal de notification pour approbation humaine.

Remédiations automatisées courantes :

Disque plein : vider /tmp, effectuer la rotation des anciens logs, nettoyer les images Docker avec docker system prune.
Service planté : systemctl restart <service>, puis vérifier qu'il est sain. S'il plante à nouveau dans les 5 minutes, escalader vers un humain.
Pression mémoire : identifier le plus gros consommateur de mémoire, le redémarrer s'il dépasse sa ligne de base attendue.
Expiration de certificat : déclencher un renouvellement Certbot quand le certificat expire dans moins de 7 jours.

Commencez de manière conservatrice. N'automatisez que les remédiations que vous avez exécutées manuellement des dizaines de fois et que vous comprenez parfaitement. Laissez le LLM suggérer des actions pour les situations inconnues, mais gardez un humain dans la boucle pour l'exécution.

Pour une approche sans code du routage d'alertes et des workflows de remédiation, n8n peut être la couche d'orchestration entre Alertmanager et vos scripts de remédiation.

Comment l'IA s'intègre-t-elle dans votre pipeline CI/CD ?

La revue de code par IA détecte les bugs, les failles de sécurité et les problèmes de performance avant que le code n'atteigne votre serveur. Les workflows GitHub Actions peuvent envoyer les diffs de pull requests à Claude ou Gemini pour analyse, poster des commentaires de revue et bloquer les merges quand des problèmes critiques sont trouvés. Cela tourne dans votre pipeline CI/CD sans modifier votre VPS.

Ce que la revue de code par IA détecte et que les linters manquent :

Les erreurs de logique et les cas limites que l'analyse statique ne peut pas détecter.
Les vulnérabilités de sécurité en contexte (un linter signale les fonctions dangereuses, mais un LLM comprend pourquoi le code environnant les rend exploitables).
Les régressions de performance : « cette requête dans une boucle va interroger la base de données N fois ».
Les lacunes de documentation : gestion d'erreurs manquante, noms de variables peu clairs, effets de bord non documentés.

Cette couche diffère des autres car elle tourne typiquement dans votre plateforme CI (GitHub Actions, GitLab CI), pas sur votre VPS. Cependant, si vous voulez tout garder auto-hébergé, vous pouvez faire tourner un runner CI sur votre VPS et router les demandes de revue de code vers votre instance Ollama locale. Le compromis : des revues plus lentes avec des modèles plus petits versus des revues plus rapides et plus précises avec des API cloud.

Qu'est-ce que l'observabilité LLM et pourquoi en avez-vous besoin ?

L'observabilité LLM suit les performances de vos outils IA : utilisation de tokens, latence, taux d'erreur, coûts et qualité des résultats. Si vous faites tourner une fonctionnalité alimentée par un LLM (chatbot, assistant de code, analyseur de logs, générateur de contenu), Langfuse vous donne de la visibilité sur chaque appel. C'est la couche « monitorer les moniteurs » de votre pile AIOps.

Langfuse est une plateforme open source d'ingénierie LLM. Auto-hébergée, elle tourne avec deux conteneurs (web + worker) avec PostgreSQL et optionnellement ClickHouse pour l'analytique. Elle fournit :

Traçage : voir chaque appel LLM avec l'entrée, la sortie, la latence et le nombre de tokens. Explorer les workflows d'agents multi-étapes pour trouver où le temps et les tokens sont dépensés.
Évaluation : noter les sorties avec un LLM-as-a-judge, du feedback humain ou des métriques personnalisées. Suivre la qualité dans le temps.
Suivi des coûts : calculer la dépense réelle par appel LLM, par utilisateur, par fonctionnalité. Comparer les performances des modèles à différents niveaux de prix.
Gestion des prompts : versionner et tester les prompts en A/B. Revenir en arrière quand un nouveau prompt dégrade la qualité des résultats.

Si vous faites tourner Ollama pour l'analyse de logs (couche 2 de cette pile), Langfuse trace chaque requête d'analyse. Vous voyez quelles requêtes de logs produisent des résultats utiles, lesquelles posent problème au modèle et comment la latence évolue quand vous changez de modèle.

Langfuse s'intègre avec OpenTelemetry, LangChain, LlamaIndex et le SDK OpenAI (avec lequel Ollama est compatible). L'instrumentation se fait généralement en quelques lignes de code.

Vous avez besoin de cette couche quand votre utilisation de LLM dépasse l'expérimentation. Une fois que vous dépendez des résultats de l'IA pour l'alerting ou la remédiation, vous devez savoir quand le modèle commence à produire n'importe quoi.

De quelles ressources VPS avez-vous besoin pour une pile AIOps complète ?

Les ressources dépendent des couches que vous déployez. Voici trois configurations associées aux plans VPS Virtua Cloud :

Configuration	Couches	Plan VPS	CPU	RAM	Disque	EUR/mois
Starter	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 Go	80 Go	24
Standard	SigNoz + Ollama (modèle 3B)	vCS-8	4 vCPU	8 Go	160 Go	48
Pile complète	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 Go	320 Go	96

Starter gère les métriques et l'agrégation de logs pour une à trois petites applications. Tableaux de bord et alertes sans analyse IA.

Standard ajoute l'analyse de logs par IA. SigNoz prend environ 4 Go et Ollama avec un modèle 3B utilise environ 2,5 Go. La RAM restante va au système d'exploitation et à vos applications monitorées. C'est le point d'équilibre pour un développeur solo ou une petite équipe.

Pile complète fait tourner toutes les couches décrites dans ce guide. Un modèle à 7 milliards de paramètres produit une meilleure analyse qu'un modèle 3B mais demande plus de RAM. Langfuse ajoute environ 1 Go. Cette configuration est destinée aux équipes qui font tourner des fonctionnalités alimentées par LLM en production et qui ont besoin d'une observabilité totale sur leur infrastructure et leur IA.

Toutes les configurations font tout tourner via Docker Compose. Les articles dédiés couvrent les fichiers docker-compose.yml exacts pour chaque outil.

Une note sur l'utilisation du disque : les données d'observabilité grossissent vite. SigNoz avec ClickHouse compresse bien (attendez-vous à une compression 5 à 10x sur les logs), mais prévoyez 1 à 5 Go de nouvelles données par jour selon la verbosité de vos logs. Définissez des politiques de rétention dès le premier jour. Un disque de 160 Go vous donne environ un à trois mois de données à des taux d'ingestion modérés.

Souveraineté des données : l'avantage RGPD du monitoring auto-hébergé

Quand vous faites tourner votre pile de monitoring sur un VPS européen, vos données d'observabilité ne quittent jamais la juridiction. Les métriques, les logs et les traces contiennent souvent des données personnelles : adresses IP, identifiants utilisateur, chemins de requêtes, messages d'erreur avec du contexte utilisateur. Envoyer ces données à une plateforme SaaS basée aux États-Unis introduit un risque de transfert RGPD, même quand le fournisseur propose une région EU.

Avec une pile auto-hébergée sur un VPS Virtua Cloud en France ou en Allemagne, vous contrôlez :

Où les données sont stockées. Sur disque, dans votre VPS, dans un centre de données européen.
Qui peut y accéder. Pas d'employés du fournisseur, pas de sous-traitants, pas d'accords de traitement de données tiers à auditer.
Combien de temps elles sont conservées. Vous définissez la politique de rétention. Pas de minimums imposés par le fournisseur ni de calendriers de suppression de données.

Ce n'est pas un avis juridique. Consultez votre délégué à la protection des données pour votre situation spécifique. Mais d'un point de vue technique, le monitoring auto-hébergé élimine toute une catégorie de questions sur les transferts de données.

Par où commencer ?

Votre point de départ dépend de votre expérience et du problème que vous résolvez maintenant.

Si vous débutez en monitoring de serveur (indie hackers, premier VPS) :

Commencez par SigNoz. Il vous donne métriques, logs et traces dans un seul outil avec une interface web. Un fichier Docker Compose, un seul outil à apprendre.
Une fois à l'aise avec la lecture des tableaux de bord, ajoutez Ollama pour l'analyse de logs par IA.
N'automatisez pas encore la remédiation. Comprenez d'abord le comportement normal de votre serveur.

Si vous utilisez déjà Prometheus ou Grafana (praticiens DevOps) :

Ajoutez Loki pour l'agrégation de logs si ce n'est pas déjà fait.
Intégrez Ollama pour le triage de logs assisté par IA en complément de vos règles d'alerte existantes.
Construisez des workflows d'auto-réparation avec les webhooks d'Alertmanager.
Ajoutez Langfuse quand vous commencez à vous appuyer sur les résultats du LLM pour les décisions opérationnelles.

Si vous voulez la pile complète dès le premier jour (développeurs IA) :

Déployez un VPS vCS-8 ou vCS-16 sur Virtua Cloud.
Mettez en place SigNoz pour l'observabilité.
Faites tourner Ollama avec un modèle 7B pour l'analyse de logs et la détection d'anomalies.
Connectez Alertmanager à vos scripts de remédiation.
Déployez Langfuse pour monitorer votre couche LLM.
Ajoutez la revue de code par IA à votre pipeline CI/CD.

Chaque article dédié de ce cocon est un tutoriel autonome. Vous pouvez les suivre dans n'importe quel ordre. La pile est modulaire : chaque couche fonctionne indépendamment et apporte de la valeur par elle-même.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.