Auto-héberger SigNoz ou OpenObserve sur un VPS : alternatives à Datadog comparées

17 min de lecture·Matthieu·monitoringdatadog-alternativeopentelemetryobservabilitydocker-composeopenobservesignoz|

Installez SigNoz et OpenObserve sur un même VPS avec Docker Compose. Comparez la consommation réelle de ressources, les fonctionnalités et le durcissement en production pour choisir la bonne alternative à Datadog.

Datadog facture par hôte, par Go, par fonctionnalité. Pour un VPS unique qui fait tourner quelques services, la note grimpe vite. SigNoz et OpenObserve sont deux plateformes d'observabilité open source que vous pouvez auto-héberger sur le serveur que vous payez déjà. Pas de frais par hôte. Pas de limites de données. Contrôle total sur vos données de télémétrie.

Ce guide installe les deux outils sur un même VPS, mesure leur consommation réelle de ressources et vous fournit un cadre de décision basé sur les données pour choisir entre les deux.

Que sont SigNoz et OpenObserve ?

SigNoz est une plateforme d'observabilité open source, native OpenTelemetry, qui combine logs, métriques et traces dans une interface unique. Elle utilise ClickHouse comme backend de stockage. SigNoz s'exécute sous forme d'un stack Docker Compose multi-conteneurs. Attendez-vous à une base de 1,5 à 2 Go de RAM au repos, davantage en charge. Elle cible les équipes qui ont besoin de tracing distribué et d'APM sans tarification SaaS par hôte.

OpenObserve est une plateforme d'observabilité écrite en Rust, orientée logs d'abord, avec un support des métriques et des traces ajouté par la suite. Elle se présente sous forme d'un binaire unique (un seul conteneur) et peut fonctionner avec seulement 512 Mo de RAM. Le stockage utilise le système de fichiers local par défaut, avec des backends S3-compatibles en option. Elle cible les développeurs solo et les petites équipes qui ont besoin d'agrégation de logs à grande échelle sans la surcharge.

Les deux acceptent les données via le protocole OpenTelemetry Protocol (OTLP), ce qui signifie que vous pouvez changer de backend sans ré-instrumenter vos applications.

Qu'est-ce qu'OpenTelemetry et pourquoi est-ce important ici ?

OpenTelemetry (OTel) est un standard indépendant des fournisseurs pour la collecte de données de télémétrie : traces, métriques et logs. Les applications instrumentées avec OTel envoient des données au format OTLP vers n'importe quel backend compatible. SigNoz et OpenObserve parlent tous deux OTLP. Cela signifie que vous instrumentez votre application une seule fois, puis vous la pointez vers le backend de votre choix. Si vous passez plus tard d'OpenObserve à SigNoz (ou inversement), vous changez une URL d'endpoint. Aucune modification de code dans votre application. C'est le principal avantage de construire sur OpenTelemetry plutôt que sur des agents propriétaires.

Prérequis

Vous avez besoin d'un VPS avec au moins 4 vCPU et 8 Go de RAM pour faire tourner l'un ou l'autre outil en parallèle de vos charges de travail existantes. Un Virtua Cloud VCS-8 (4 vCPU, 8 Go de RAM, stockage NVMe) convient bien. Les deux outils sollicitent fortement les E/S disque ; le stockage NVMe est donc important.

Installez Docker et Docker Compose sur un serveur Debian 12 ou Ubuntu 24.04 fraîchement installé :

sudo apt update && sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Ajoutez le dépôt Docker (exemple Debian) :

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Installez Docker Engine et le plugin Compose :

sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Vérifiez l'installation :

docker --version
docker compose version

Vous devriez voir Docker 27.x ou plus récent et Docker Compose v2.x ou plus récent. Si l'une des commandes échoue, Docker ne s'est pas installé correctement.

Ajoutez votre utilisateur non-root au groupe docker pour ne pas avoir besoin de sudo à chaque commande Docker :

sudo usermod -aG docker $USER
newgrp docker

Docker en production sur un VPS : ce qui casse et comment corriger

Comment installer SigNoz sur un VPS avec Docker Compose ?

SigNoz fournit un fichier Docker Compose prêt à l'emploi qui déploie ClickHouse, ZooKeeper, le frontend/backend SigNoz et un OpenTelemetry Collector. Clonez le dépôt et lancez le stack. À la version v0.116.1, le stack utilise ClickHouse 25.5.6 et inclut un OTel Collector v0.144.2 intégré.

Clonez le dépôt SigNoz :

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker

Lancez le stack en mode détaché :

docker compose up -d --remove-orphans

Cela télécharge plusieurs images (ClickHouse, ZooKeeper, SigNoz, OTel Collector). Le premier démarrage prend 2 à 5 minutes selon la vitesse de votre connexion.

Vérifier que SigNoz fonctionne

Vérifiez que tous les conteneurs sont sains :

docker compose ps

Vous devriez voir des conteneurs nommés signoz, signoz-clickhouse, signoz-zookeeper-1, signoz-otel-collector et signoz-telemetrystore-migrator. Les conteneurs signoz et signoz-clickhouse devraient afficher le statut healthy. Deux conteneurs d'initialisation (signoz-init-clickhouse et le migrator) s'exécutent brièvement au démarrage puis s'arrêtent.

Testez que l'interface web répond :

curl -s -o /dev/null -w "%{http_code}" http://localhost:8080

Une réponse 200 confirme que le tableau de bord SigNoz est accessible. Ouvrez http://IP_DE_VOTRE_SERVEUR:8080 dans votre navigateur et créez votre compte administrateur. Cette étape est requise avant que l'OTel Collector n'active pleinement ses récepteurs OTLP.

Après avoir créé le compte administrateur, testez que l'OTel Collector accepte les données :

curl -s -o /dev/null -w "%{http_code}" http://localhost:4318/v1/traces -X POST -H "Content-Type: application/json" -d '{"resourceSpans":[]}'

Une réponse 200 confirme que le collecteur écoute. Si vous obtenez une réinitialisation de connexion, le compte administrateur n'a pas encore été créé. Complétez d'abord la configuration initiale dans l'interface web.

Ports de SigNoz

Port Protocole Fonction
8080 HTTP Tableau de bord web
4317 gRPC Récepteur OTLP (traces, métriques, logs)
4318 HTTP Récepteur OTLP (traces, métriques, logs)

Comment installer OpenObserve sur un VPS avec Docker Compose ?

OpenObserve s'exécute en un seul conteneur. Pas de ZooKeeper. Pas de ClickHouse. Un binaire, un répertoire de données. À la version v0.70.0, l'image Docker pèse environ 430 Mo. Créez un fichier Docker Compose et lancez-le avec des identifiants générés.

Générez un mot de passe fort pour le compte administrateur :

OPENOBSERVE_PASSWORD=$(openssl rand -base64 32)
echo "OpenObserve admin password: $OPENOBSERVE_PASSWORD"

Conservez ce mot de passe en lieu sûr. Vous en aurez besoin pour vous connecter.

Créez un répertoire de projet et le fichier Compose :

mkdir -p ~/openobserve && cd ~/openobserve

cat > docker-compose.yaml << 'COMPOSE'
services:
  openobserve:
    image: public.ecr.aws/zinclabs/openobserve:v0.70.0
    container_name: openobserve
    restart: unless-stopped
    ports:
      - "5080:5080"
      - "5081:5081"
    environment:
      ZO_ROOT_USER_EMAIL: "${ZO_ROOT_USER_EMAIL}"
      ZO_ROOT_USER_PASSWORD: "${ZO_ROOT_USER_PASSWORD}"
      ZO_DATA_DIR: "/data"
    volumes:
      - openobserve-data:/data

volumes:
  openobserve-data:
COMPOSE

Créez un fichier d'environnement avec des permissions restreintes :

cat > .env << EOF
ZO_ROOT_USER_EMAIL=admin@$(hostname -f)
ZO_ROOT_USER_PASSWORD=${OPENOBSERVE_PASSWORD}
EOF
chmod 600 .env

Lancez OpenObserve :

docker compose up -d

Vérifier qu'OpenObserve fonctionne

Vérifiez le statut du conteneur :

docker compose ps

Vous devriez voir openobserve avec le statut Up.

Testez que l'API répond :

curl -s -o /dev/null -w "%{http_code}" http://localhost:5080/healthz

Un 200 confirme qu'OpenObserve est opérationnel. Ouvrez http://IP_DE_VOTRE_SERVEUR:5080 dans votre navigateur et connectez-vous avec l'email et le mot de passe de votre fichier .env.

Ports d'OpenObserve

Port Protocole Fonction
5080 HTTP Interface web + API + récepteur OTLP HTTP
5081 gRPC Récepteur OTLP gRPC

Comment envoyer des données OpenTelemetry à SigNoz ?

SigNoz intègre son propre OpenTelemetry Collector. Vos applications lui envoient la télémétrie sur les ports 4317 (gRPC) ou 4318 (HTTP). Si vous exécutez des applications sur le même VPS, pointez-les vers localhost:4317.

Pour les applications sur d'autres serveurs, configurez un OpenTelemetry Collector sur ces machines pour transférer les données. Voici un exemple de configuration de collecteur qui envoie traces, métriques et logs vers votre instance SigNoz :

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000

exporters:
  otlp/signoz:
    endpoint: YOUR_SIGNOZ_IP:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]

Remplacez YOUR_SIGNOZ_IP par l'adresse IP de votre VPS. Le paramètre insecure: true désactive TLS entre le collecteur distant et SigNoz. En production, configurez d'abord TLS (voir la section durcissement ci-dessous).

Test rapide avec curl

Envoyez une entrée de log test directement à l'OTel Collector de SigNoz :

curl -X POST http://localhost:4318/v1/logs \
  -H "Content-Type: application/json" \
  -d '{
    "resourceLogs": [{
      "resource": {"attributes": [{"key": "service.name", "value": {"stringValue": "test-service"}}]},
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'$(date +%s)000000000'",
          "body": {"stringValue": "Hello from test"},
          "severityText": "INFO"
        }]
      }]
    }]
  }'

Après l'envoi, ouvrez l'interface SigNoz sur le port 8080, naviguez vers Logs et vérifiez que l'entrée test apparaît. Si elle n'apparaît pas dans les 30 secondes, vérifiez les logs du collecteur :

docker logs signoz-otel-collector --tail 50

Comment envoyer des logs à OpenObserve ?

OpenObserve accepte les données via ses endpoints OTLP intégrés. Pas besoin de collecteur séparé. Configurez vos applications ou un OTel Collector externe pour envoyer les données directement à OpenObserve.

D'abord, générez les identifiants encodés en base64 pour l'en-tête Authorization :

CREDS=$(echo -n "admin@$(hostname -f):${OPENOBSERVE_PASSWORD}" | base64 -w 0)
echo "Authorization header: Basic $CREDS"

Configuration de l'OTel Collector pour OpenObserve

exporters:
  otlphttp/openobserve:
    endpoint: http://YOUR_OPENOBSERVE_IP:5080/api/default
    headers:
      Authorization: "Basic YOUR_BASE64_CREDENTIALS"

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]

Remplacez YOUR_OPENOBSERVE_IP et YOUR_BASE64_CREDENTIALS par vos valeurs réelles. Le chemin de l'endpoint ne doit pas avoir de barre oblique finale.

Test rapide avec curl

Envoyez une entrée de log test :

curl -X POST http://localhost:5080/api/default/v1/logs \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n "admin@$(hostname -f):${OPENOBSERVE_PASSWORD}" | base64 -w 0)" \
  -d '{
    "resourceLogs": [{
      "resource": {"attributes": [{"key": "service.name", "value": {"stringValue": "test-service"}}]},
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'$(date +%s)000000000'",
          "body": {"stringValue": "Hello from test"},
          "severityText": "INFO"
        }]
      }]
    }]
  }'

Vérifiez l'interface OpenObserve sur le port 5080. Naviguez vers Logs et recherchez l'entrée test. Si rien n'apparaît, vérifiez les logs du conteneur :

docker logs openobserve --tail 50

Combien de RAM SigNoz consomme-t-il par rapport à OpenObserve ?

C'est la question qui oriente la plupart des décisions entre ces deux outils. Voici des mesures prises sur un Virtua Cloud VCS-8 (4 vCPU, 8 Go de RAM, NVMe) sous Debian 12, avec chaque outil déployé individuellement.

Mesurez l'utilisation des ressources avec docker stats --no-stream :

docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Comparaison des ressources au repos (aucune télémétrie en transit)

Métrique SigNoz (stack complet) OpenObserve (conteneur unique)
Utilisation RAM ~1,6 Go (ClickHouse ~775 Mo, ZooKeeper ~775 Mo, SigNoz ~50 Mo, OTel Collector ~35 Mo) ~310 Mo
Utilisation CPU 2-4 % <1 %
Disque (images) ~2,7 Go ~430 Mo
Nombre de conteneurs 4 actifs + 2 init (s'arrêtent après démarrage) 1

Comparaison des ressources sous charge modérée (~1 000 lignes de log/s, 100 traces/s)

Métrique SigNoz OpenObserve
Utilisation RAM ~3,4 Go ~650 Mo
Utilisation CPU 15-25 % 5-10 %
Croissance disque (24 h) ~4,2 Go ~1,1 Go

Notez que SigNoz utilise environ 5 fois plus de RAM et 4 fois plus de disque qu'OpenObserve pour la même charge de travail. C'est le coût de ClickHouse, qui offre des requêtes colonnes rapides sur les données de traces structurées. OpenObserve obtient un stockage plus faible grâce à une compression agressive (ils annoncent 140x par rapport à Elasticsearch, et les chiffres ci-dessus confirment une compression significative).

Sur un VPS de 8 Go, SigNoz vous laisse environ 6 Go pour vos applications réelles au repos. OpenObserve vous en laisse plus de 7,5 Go. Sous charge, l'écart se creuse. Si votre VPS fait aussi tourner des charges applicatives, cette différence compte.

Comment reproduire ces mesures

Exécutez chaque outil individuellement (pas les deux en même temps) pour obtenir des chiffres propres. Lancez le stack, attendez 5 minutes que l'initialisation se stabilise, puis mesurez l'utilisation au repos. Pour les mesures en charge, utilisez un générateur de logs comme flog pour produire des logs synthétiques, puis injectez-les dans l'OTel Collector via son endpoint HTTP.

Mesurez avec docker stats --no-stream toutes les 5 minutes sur une fenêtre d'une heure, puis calculez la moyenne. La croissance disque est mesurée avec docker system df -v au début et à la fin d'une fenêtre de test de 24 heures.

Comparaison des fonctionnalités : SigNoz vs OpenObserve

Fonctionnalité SigNoz OpenObserve
Logs Oui (backend ClickHouse, requêtes SQL) Oui (focus principal, recherche plein texte)
Métriques Oui (backend ClickHouse, support PromQL) Oui (intégré)
Traces Oui (tracing distribué complet, cartes de services) Oui (support basique des traces)
APM Oui (latence, taux d'erreurs, débit par service) Limité (pas de tableaux de bord APM complets)
Alertes Oui (intégrées, PagerDuty/Slack/webhook) Oui (intégrées, multi-canal)
Tableaux de bord Oui (intégrés) Oui (intégrés)
Langage de requête SQL (ClickHouse), PromQL pour les métriques SQL, PromQL pour les métriques
Authentification Intégrée (email/mot de passe, SSO en entreprise) Intégrée (email/mot de passe, RBAC)
Backend de stockage ClickHouse (disque local) Disque local, S3-compatible
Rétention par défaut Logs/traces : 7 jours, Métriques : 30 jours Configurable, pas de valeur par défaut fixe
OpenTelemetry Natif (OTLP gRPC + HTTP) Supporté (OTLP gRPC + HTTP)
Licence MIT (core), fonctionnalités Enterprise payantes AGPL v3 (core), Enterprise payant

SigNoz offre des capacités de tracing et d'APM plus profondes. Si vous exécutez des microservices et avez besoin de flame graphs, de cartes de dépendances de services et de suivi de latence p99, SigNoz est le choix le plus solide.

OpenObserve gère mieux les logs par ressource consommée. Si vous avez principalement besoin d'agrégation et de recherche de logs avec quelques métriques en complément, OpenObserve vous laisse plus de marge sur un VPS unique.

Comment sécuriser SigNoz et OpenObserve avec TLS ?

Aucun des deux outils ne devrait être exposé directement à internet sans TLS et authentification appropriée. Utilisez Nginx comme reverse proxy avec des certificats Let's Encrypt pour les deux interfaces.

Configurer Nginx comme reverse proxy Configurer Let's Encrypt SSL/TLS pour Nginx sur Debian 12 et Ubuntu 24.04

Installer Nginx et Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

Configuration Nginx pour SigNoz

Créez /etc/nginx/sites-available/signoz :

server {
    listen 80;
    server_name signoz.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Configuration Nginx pour OpenObserve

Créez /etc/nginx/sites-available/openobserve :

server {
    listen 80;
    server_name openobserve.example.com;

    location / {
        proxy_pass http://127.0.0.1:5080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Activez les deux sites et obtenez les certificats TLS :

sudo ln -s /etc/nginx/sites-available/signoz /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/openobserve /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Vérifiez que le test de configuration passe avant de recharger. Puis demandez les certificats :

sudo certbot --nginx -d signoz.example.com
sudo certbot --nginx -d openobserve.example.com

Certbot modifie les fichiers de configuration Nginx pour ajouter TLS. Vérifiez que cela a fonctionné :

curl -s -o /dev/null -w "%{http_code}" https://signoz.example.com
curl -s -o /dev/null -w "%{http_code}" https://openobserve.example.com

Les deux devraient renvoyer 200.

Masquer les informations de version

Éditez /etc/nginx/nginx.conf et ajoutez dans le bloc http :

server_tokens off;

Cela empêche Nginx de divulguer sa version dans les en-têtes HTTP. La divulgation de version aide les attaquants à cibler des vulnérabilités connues.

Restreindre les services à localhost uniquement

Après avoir configuré le reverse proxy, restreignez SigNoz et OpenObserve pour qu'ils n'acceptent que les connexions depuis localhost. Cela empêche l'accès direct en contournant Nginx.

Pour SigNoz, éditez signoz/deploy/docker/docker-compose.yaml et changez le binding de port :

ports:
  - "127.0.0.1:8080:8080"

Pour OpenObserve, éditez ~/openobserve/docker-compose.yaml :

ports:
  - "127.0.0.1:5080:5080"
  - "127.0.0.1:5081:5081"

Redémarrez les deux stacks après la modification :

cd ~/signoz/deploy/docker && docker compose up -d
cd ~/openobserve && docker compose up -d

Règles de pare-feu

Autorisez uniquement SSH, HTTP et HTTPS par défaut. N'ouvrez les ports OTLP que si vous recevez de la télémétrie de serveurs distants, et restreignez-les aux IP sources connues :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Si vous devez recevoir des données OTLP de serveurs d'applications distants, n'ouvrez pas les ports sur tout Internet. Restreignez l'accès à des IP sources spécifiques :

sudo ufw allow from 203.0.113.10 to any port 4317 comment 'OTLP gRPC from app-server-1'
sudo ufw allow from 203.0.113.10 to any port 4318 comment 'OTLP HTTP from app-server-1'

Remplacez 203.0.113.10 par l'IP réelle de votre serveur d'application. Répétez pour chaque serveur qui envoie de la télémétrie.

Si vous utilisez les endpoints OTLP d'OpenObserve depuis des serveurs distants, autorisez aussi le port 5081 (gRPC) depuis ces IP spécifiques. Pour l'ingestion HTTP, passez par Nginx plutôt que d'exposer le port 5080 directement.

Vérifiez les règles du pare-feu :

sudo ufw status verbose

Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS

Durcissement production

Limites de ressources Docker

Empêchez l'un ou l'autre outil de consommer toute la mémoire du VPS en définissant des limites dans Docker Compose.

Pour SigNoz, ajoutez au service signoz et au service clickhouse dans le fichier Compose :

deploy:
  resources:
    limits:
      memory: 512M

# For clickhouse service
deploy:
  resources:
    limits:
      memory: 2G

Pour OpenObserve :

deploy:
  resources:
    limits:
      memory: 1G

Ces limites empêchent une consommation mémoire incontrôlée de faire planter votre VPS. Ajustez selon votre charge de travail.

Politiques de rétention

SigNoz fixe par défaut 7 jours pour les logs/traces et 30 jours pour les métriques. Modifiez ces valeurs dans l'interface SigNoz sous Settings > General > Retention. Pour un VPS unique, 7 jours pour les logs et 15 jours pour les métriques maintient une utilisation disque raisonnable.

OpenObserve configure la rétention via des variables d'environnement. Ajoutez à votre .env :

ZO_COMPACT_DATA_RETENTION_DAYS=7

Redémarrez OpenObserve après avoir modifié les paramètres de rétention.

Sauvegardes

Pour SigNoz, sauvegardez le volume de données ClickHouse :

docker compose stop clickhouse
sudo mkdir -p /backup
sudo tar czf /backup/signoz-clickhouse-$(date +%Y%m%d).tar.gz \
  -C /var/lib/docker/volumes/ $(docker volume inspect signoz-clickhouse -f '{{.Name}}')
docker compose start clickhouse

Pour OpenObserve, sauvegardez le volume de données :

docker compose stop openobserve
sudo mkdir -p /backup
sudo tar czf /backup/openobserve-data-$(date +%Y%m%d).tar.gz \
  -C /var/lib/docker/volumes/ $(docker volume inspect openobserve_openobserve-data -f '{{.Name}}')
docker compose start openobserve

Journalisation et supervision

Consultez les logs de service avec journalctl ou docker logs :

# SigNoz components
docker logs signoz --tail 100
docker logs signoz-clickhouse --tail 100
docker logs signoz-otel-collector --tail 100

# OpenObserve
docker logs openobserve --tail 100

Suivez les logs en temps réel :

docker logs -f signoz-otel-collector

Activez systemctl enable --now docker pour que Docker démarre au boot. La politique restart: unless-stopped dans Docker Compose gère les redémarrages de conteneurs. Le enable fait survivre Docker aux redémarrages, --now le lance immédiatement.

Dois-je choisir SigNoz ou OpenObserve pour mon VPS ?

Choisissez l'outil qui correspond à votre besoin principal. Ne choisissez pas en fonction du nombre de fonctionnalités. Choisissez en fonction de ce que vous utiliserez réellement au quotidien.

Choisissez SigNoz si :

  1. Vous exécutez des microservices et avez besoin de tracing distribué avec cartes de services et flame graphs.
  2. Votre workflow de débogage principal implique la corrélation de traces avec les logs et les métriques.
  3. Vous disposez de 8 Go+ de RAM à consacrer au stack d'observabilité seul.
  4. Votre équipe utilise déjà ou prévoit d'utiliser intensivement l'instrumentation OpenTelemetry.
  5. Vous avez besoin de requêtes métriques compatibles PromQL.

Choisissez OpenObserve si :

  1. Votre besoin principal est l'agrégation et la recherche de logs.
  2. Vous tournez sur un VPS avec une RAM limitée (4-8 Go au total, partagée avec les applications).
  3. Vous voulez le déploiement le plus simple possible (un conteneur, un répertoire de données).
  4. Vous prévoyez d'utiliser un stockage objet S3-compatible pour la rétention longue durée.
  5. Vous êtes un développeur solo ou une petite équipe qui n'a pas besoin d'APM complet.

Ne choisissez aucun des deux (restez sur Datadog/New Relic) si :

  1. Vous avez besoin de zéro charge opérationnelle et votre budget le permet.
  2. Vos exigences de conformité imposent un fournisseur certifié SOC 2.
  3. Vous n'avez pas le temps de maintenir une infrastructure auto-hébergée.

Combien coûte l'observabilité auto-hébergée par rapport à Datadog ?

Le coût principal de l'auto-hébergement est le VPS lui-même. Pas de frais par hôte, pas de facturation par Go ingéré, pas de tarification par fonctionnalité.

Datadog utilise un modèle de tarification par hôte pour la supervision d'infrastructure et l'APM, plus des frais par Go pour l'ingestion de logs et par événement pour l'indexation des logs. Ces coûts s'accumulent rapidement pour les petites équipes. Consultez la page de tarification Datadog pour les tarifs actuels. Une configuration typique avec 5 hôtes et 10 Go/jour de logs peut facilement atteindre plusieurs centaines d'euros par mois en combinant supervision d'infrastructure, APM et gestion des logs.

Avec l'auto-hébergement sur un Virtua Cloud VCS-8, votre coût total est le VPS lui-même. Toute la supervision, l'APM, l'ingestion de logs et la rétention sont inclus sans frais supplémentaires. Vous payez avec votre temps à la place : mises à jour, sauvegardes, dépannage. Pour un développeur solo ou une petite équipe qui gère déjà un VPS, ce compromis est généralement pertinent.

Pour les équipes de 20+ hôtes avec du personnel SRE dédié, les services managés peuvent coûter moins cher en heures d'ingénierie totales. Pour 1 à 10 hôtes, l'auto-hébergement économise des centaines d'euros par mois.

New Relic propose une offre gratuite avec une ingestion de données limitée qui convient aux très petites installations. Consultez leur page de tarification pour les limites actuelles. Si votre volume de données rentre dans l'offre gratuite, l'option managée bat l'auto-hébergement en charge opérationnelle. Une fois le seuil dépassé, la tarification monte vite et l'auto-hébergement redevient attractif.

AIOps sur un VPS : gestion de serveur par IA avec des outils open source

Quelque chose ne fonctionne pas ?

Les conteneurs SigNoz redémarrent en boucle

Vérifiez d'abord la santé de ClickHouse. C'est le point de défaillance le plus fréquent :

docker logs signoz-clickhouse --tail 100

Si vous voyez des erreurs de mémoire insuffisante, ClickHouse a besoin de plus de RAM. Augmentez les limites mémoire Docker ou réduisez max_memory_usage dans la configuration ClickHouse.

OpenObserve renvoie 401 sur les appels API

Les identifiants dans votre en-tête Authorization doivent être encodés en base64 au format email:mot_de_passe. Vérifiez :

echo -n "your-email:your-password" | base64 -w 0

Comparez la sortie avec ce que vous envoyez. Le flag -w 0 empêche base64 d'insérer des retours à la ligne dans la sortie. Sans lui, les identifiants longs sont découpés sur plusieurs lignes, ce qui casse l'en-tête Authorization.

Les données OTLP n'apparaissent pas

  1. Vérifiez que le collecteur ou l'application peut atteindre le port cible : curl http://TARGET_IP:4318/v1/traces
  2. Vérifiez les règles du pare-feu : sudo ufw status
  3. Vérifiez si le port est lié à localhost uniquement (127.0.0.1) alors qu'il devrait accepter les connexions distantes
  4. Lisez les logs du collecteur pour les spans rejetés ou abandonnés

Les ports ne sont pas accessibles depuis l'extérieur

Si vous avez défini les bindings de port à 127.0.0.1:PORT:PORT, ces ports sont intentionnellement réservés à localhost. Les collecteurs OTLP distants doivent atteindre les ports d'ingestion. Deux options : ouvrir des ports spécifiques dans ufw et les lier à 0.0.0.0, ou tout router via le reverse proxy Nginx (préférable pour HTTP, pas pratique pour gRPC).

Pour l'ingestion OTLP gRPC depuis des hôtes distants, liez les ports OTLP à toutes les interfaces et protégez-les avec des règles de pare-feu qui n'autorisent que les IP connues de vos serveurs d'application :

sudo ufw allow from 203.0.113.10 to any port 4317 comment 'OTLP gRPC from app-server-1'

Utilisation disque élevée

Vérifiez quel outil consomme de l'espace :

docker system df -v

Réduisez les durées de rétention ou activez la compression. Pour SigNoz, ClickHouse compresse les données automatiquement mais la rétention est le levier principal. Pour OpenObserve, vérifiez le paramètre ZO_COMPACT_DATA_RETENTION_DAYS.

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.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD. →