SigNoz sur VPS : APM open source en 15 minutes

Les outils SaaS d'observabilité ont un modèle tarifaire redoutable : gratuit jusqu'à une poignée d'hôtes, puis la facture s'envole avec chaque service ajouté. Pour une agence web qui gère dix projets clients ou un développeur indépendant qui scale son SaaS, la note mensuelle dépasse rapidement 200 à 500 € sans que la valeur ajoutée soit proportionnelle.

SigNoz change la donne. C'est une plateforme d'observabilité open source (licence Apache 2.0) qui repose sur ClickHouse pour le stockage haute performance des traces et des métriques, et sur le protocole OpenTelemetry pour l'instrumentation. Vous gardez vos données chez vous, vous contrôlez la rétention, et vous ne payez que le VPS qui fait tourner la stack.

SigNoz s'appuie sur ClickHouse, un moteur de base de données colonnaire très gourmand en mémoire. Le minimum absolu recommandé est 4 Go de RAM — en dessous, ClickHouse se fait tuer par l'OOM killer du kernel avant même que l'UI se charge. Pour un usage production avec plusieurs applications instrumentées, visez 8 Go.

Voici la liste complète des prérequis :
- Un VPS sous Ubuntu 22.04 ou Debian 12.
- Docker Engine ≥ 24 et Docker Compose V2 installés.
- Le port 8080 ouvert dans votre pare-feu (UI SigNoz).
- Les ports 4317 (OTLP/gRPC) et 4318 (OTLP/HTTP) ouverts pour recevoir les traces.
- Un accès root ou sudo sur le VPS.
- Au moins 20 Go d'espace disque libre pour ClickHouse et ses fichiers de données.

SigNoz reçoit les traces via le protocole OTLP. Voici comment brancher trois environnements courants.

Node.js (Express/Fastify) :

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

Créez un fichier tracing.js chargé avant le reste de l'application :

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const sdk = new NodeSDK({ instrumentations: [getNodeAutoInstrumentations()] });
sdk.start();

Démarrez votre app en pointant vers votre VPS :

OTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="mon-api" \
node -r ./tracing.js app.js

Python (FastAPI/Flask) :

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

OTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="mon-service-python" \
opentelemetry-instrument uvicorn main:app

Go — spans manuels :

Pour Go, l'instrumentation auto est plus limitée ; on créé des spans manuellement :

go get go.opentelemetry.io/otel \
       go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp \
       go.opentelemetry.io/otel/sdk/trace

Initialisez le traceur dans votre main.go :

exp, _ := otlptracehttp.New(ctx,
    otlptracehttp.WithEndpointURL("http://<IP_VPS>:4318"),
    otlptracehttp.WithInsecure(),
)
tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exp))
otel.SetTracerProvider(tp)

Puis créez des spans autour des opérations critiques :

tracer := otel.Tracer("mon-service-go")
ctx, span := tracer.Start(ctx, "fetch-user-details")
defer span.End()
span.SetAttributes(attribute.String("user.id", userID))

Dans les trois cas, les traces apparaissent dans l'interface SigNoz sous Services dans les secondes qui suivent le premier appel.

Sur un VPS à disque limité, la rétention par défaut de SigNoz (3 jours de traces, 30 jours de métriques) peut saturer l'espace en quelques semaines si votre volume de traces est élevé.

Ajuster la rétention depuis l'UI :

Allez dans Settings → Retention Period pour définir des durées différentes pour les traces, les métriques et les logs. Pour une agence multi-projets, 7 jours de traces et 90 jours de métriques est un bon équilibre.

Configurer le cold storage ClickHouse (TTL par volume) :

Pour les VPS avec un second volume moins cher (par exemple un volume bloc supplémentaire monté sur /mnt/cold), vous pouvez configurer ClickHouse pour déplacer les données âgées automatiquement.

Dans /etc/clickhouse-server/config.xml, ajoutez un volume cold :

<storage_configuration>
  <disks>
    <default/>
    <cold_disk>
      <type>local</type>
      <path>/mnt/cold/clickhouse/</path>
    </cold_disk>
  </disks>
  <policies>
    <tiered>
      <volumes>
        <hot><disk>default</disk></hot>
        <cold><disk>cold_disk</disk></cold>
      </volumes>
    </tiered>
  </policies>
</storage_configuration>

Puis appliquez la politique TTL sur les tables de traces SigNoz :

ALTER TABLE signoz_traces.distributed_signoz_index_v2
  MODIFY TTL toDateTime(timestamp) + INTERVAL 7 DAY
  TO VOLUME 'cold',
  toDateTime(timestamp) + INTERVAL 30 DAY DELETE;

ClickHouse déplace les données vers le volume cold après 7 jours et les supprime après 30 jours — sans intervention manuelle.

Une fois vos applications instrumentées, SigNoz peuple automatiquement la vue Services avec la latence P50/P99, le taux d'erreur et le débit de chaque service. Vous pouvez créer des alertes sur n'importe lequel de ces signaux.

Alerte sur la latence P99 :
1. Allez dans Alerts → New Alert Rule.
2. Choisissez le type Metric Based Alert.
3. Saisissez la condition : p99(signoz_latency_bucket{service_name="mon-api"}) > 500 (alerte si P99 > 500 ms).
4. Configurez le canal de notification : Slack, email ou webhook.

Alerte sur le taux d'erreur :
Utilisez la condition rate(signoz_calls_total{service_name="mon-api",status_code="STATUS_CODE_ERROR"}[5m]) > 0.05 pour déclencher une alerte si plus de 5 % des appels échouent sur 5 minutes.

Détection d'anomalie (alerte sur variation soudaine) :
SigNoz supporte des alertes de type Anomaly (onglet dédié dans la création de règle) : définissez une fenêtre de référence (par exemple 7 jours) et un seuil d'écart acceptable. Toute déviation inhabituelle du débit ou de la latence déclenche l'alerte — utile pour capturer des dégradations lentes que les seuils fixes manquent.

Créer un dashboard personnalisé :
1. Allez dans Dashboards → New Dashboard.
2. Ajoutez un panel de type Time Series et sélectionnez une métrique Prometheus.
3. Appliquez des filtres par service, environnement ou endpoint.

SigNoz en mode standalone (un seul VPS, une seule instance ClickHouse) tient sans effort jusqu'à une dizaine de services instrumentés générant quelques milliers de spans par seconde. C'est le cas d'usage cible pour un VPS développeur.

Quand envisager le passage en cluster :
- Votre VPS atteint régulièrement 80 % d'utilisation CPU sur le processus ClickHouse.
- Le volume de traces ingérées dépasse 5 000 spans/s en pointe soutenue.
- Vous avez besoin d'une haute disponibilité (zéro temps d'arrêt lors des mises à jour).

Scaling vertical (recommandé en premier) :
Avant de distribuer, doublez la RAM du VPS. ClickHouse est conçu pour tirer parti d'une mémoire importante ; passer de 8 à 16 Go RAM déplace souvent le goulot d'étranglement vers le réseau plutôt que vers le CPU.

Scaling horizontal (cluster ClickHouse) :
SigNoz fournit des charts Helm pour un déploiement Kubernetes avec ClickHouse distribué (shards + réplicas). C'est une infrastructure significativement plus complexe — réservez-la aux stacks qui dépassent vraiment les limites du standalone. Sur un VPS, la voie la plus simple est un second VPS dédié à ClickHouse, relié au premier par réseau privé.

L'UI ne se charge pas sur le port 8080
Vérifiez que le conteneur signoz-frontend est en état running et que votre pare-feu autorise le port :

docker compose ps | grep frontend
ufw status | grep 8080

Les traces n'apparaissent pas dans l'interface
La cause la plus fréquente est une variable OTEL_EXPORTER_OTLP_ENDPOINT incorrecte. Vérifiez que :
- l'URL pointe vers l'IP publique du VPS, pas vers localhost ;
- le port est 4318 pour OTLP/HTTP (ou 4317 pour gRPC) ;
- aucun pare-feu ne bloque ce port entre votre app et le VPS.

Test rapide depuis le serveur de l'application :

curl -v http://<IP_VPS>:4318

Une réponse 405 Method Not Allowed confirme que le collector écoute bien.

ClickHouse OOM — conteneur en boucle de redémarrage
Consultez dmesg | grep -i oom pour confirmer le kill. Si la RAM est insuffisante, limitez l'utilisation mémoire de ClickHouse :

echo '<max_memory_usage>2000000000</max_memory_usage>' \
  >> /etc/clickhouse-server/users.xml
docker compose restart clickhouse

Timeout de démarrage SigNoz
Si docker compose ps montre le conteneur signoz en starting pendant plus de 5 minutes, ClickHouse n'est pas encore prêt. SigNoz attend une réponse de ClickHouse avant de s'initialiser. Vérifiez la santé du conteneur ClickHouse :

docker compose logs clickhouse --tail=50

Un disque plein ou des droits insuffisants sur le volume de données sont les causes les plus courantes de ce blocage.

Erreur connection refused depuis l'app
Assurez-vous que les ports 4317 ou 4318 sont ouverts dans le firewall du VPS SigNoz, et que l'URL dans OTEL_EXPORTER_OTLP_ENDPOINT pointe bien vers l'IP publique du VPS, pas vers localhost.