Une facture Datadog qui passe de quelques milliers d'euros à un budget de département, ça arrive plus vite qu'on ne l'imagine. Le modèle est facturé par host, par Go de logs ingérés, par million d'événements, par module activé. Chaque dimension grossit seule. Sur un parc Kubernetes qui scale, la surface monitorée explose et la note suit. C'est exactement le terrain où une plateforme self-hosted bâtie sur des standards ouverts reprend la main : on paie l'infrastructure, pas l'ingestion.
SigNoz se positionne là. Plateforme d'observabilité open source qui regroupe traces, métriques et logs dans une seule application, conçue dès l'origine autour d'OpenTelemetry. Pas d'agent maison, pas de format propriétaire, un seul magasin de données. Voyons ce que ça vaut en exploitation réelle, et quand la stack Grafana modulaire reste le meilleur choix.
Les trois piliers sous une seule UI
L'observabilité moderne tient sur trois signaux : les traces (le parcours d'une requête à travers les services), les métriques (séries temporelles, latence, débit, saturation) et les logs (l'événement brut). Le piège classique des stacks assemblées à la main, c'est que chaque signal vit dans son propre outil, avec son propre langage de requête et ses propres labels. Corréler un pic de latence avec les logs qui vont avec devient un exercice de discipline sur l'alignement des labels.
SigNoz pose les trois signaux sur le même schéma et le même magasin de données. Concrètement, on part d'une anomalie de latence sur une trace, on saute aux logs corrélés du même span sans changer d'outil ni réaligner quoi que ce soit. C'est l'argument central face à un assemblage modulaire : la corrélation est native, pas reconstruite a posteriori.
Pour la mécanique des trois piliers et le rôle pivot du standard, voir notre décryptage sur OpenTelemetry et la fin du lock-in d'instrumentation.
OpenTelemetry natif, pas un greffon
Le point qui change tout : SigNoz est construit autour du modèle de données OpenTelemetry depuis le premier jour, pas avec un support OTel ajouté après coup sur une architecture propriétaire. La différence n'est pas cosmétique. Vous instrumentez une fois avec OpenTelemetry, et votre instrumentation reste portable. Si vous décidez un jour de changer de backend, le code applicatif ne bouge pas, seul le endpoint de collecte change.
L'ingestion passe par l'OpenTelemetry Collector. Une config minimale ressemble à ça :
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 5s
send_batch_size: 10000
exporters:
otlp:
endpoint: signoz-otel-collector:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
Rien de spécifique à SigNoz dans ce fichier hormis le endpoint d'export. C'est tout l'intérêt : la couche d'instrumentation est standard, le backend est interchangeable. Pas d'agent propriétaire à déployer sur chaque host, pas de SDK maison à maintenir.
ClickHouse comme socle de stockage
SigNoz stocke les trois signaux dans ClickHouse, base de données colonne utilisée à grande échelle par Uber et Cloudflare. Le choix est cohérent avec la nature de la donnée d'observabilité : volume élevé, haute cardinalité, requêtes d'agrégation sur de gros ensembles. ClickHouse encaisse des millions d'événements par seconde sur du matériel raisonnable, et son moteur colonne rend les agrégations rapides tout en gardant un coût de stockage bas comparé aux stacks traditionnelles.
Un seul moteur pour traces, métriques et logs, ça veut dire un seul backend à déployer, scaler et opérer. C'est le contraste structurel avec un assemblage où chaque signal a son propre store. Côté ops, ça réduit la surface d'exploitation, mais ça concentre aussi le risque : ClickHouse devient le composant critique unique. Son dimensionnement n'est pas une formalité.
Self-hosted : déploiement et dimensionnement
SigNoz s'auto-héberge via docker-compose pour un démarrage rapide, ou via Helm sur Kubernetes pour la production. Le démarrage tient en quelques commandes :
git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
docker compose up -d
Ça lance le frontend, le query service, l'OpenTelemetry Collector et ClickHouse. Suffisant pour évaluer. Pour de la prod, on passe sur Kubernetes avec un ClickHouse dimensionné séparément.
Le vrai travail d'exploitation est là. ClickHouse en production demande du CPU, de la RAM et surtout du disque rapide proportionnés au volume ingéré et à la rétention voulue. La règle qu'on applique : on dimensionne par le débit d'ingestion (événements par seconde, Go de logs par jour) croisé avec la fenêtre de rétention, pas par le nombre de hosts. Un parc qui génère beaucoup de logs verbeux coûtera plus en stockage qu'un parc plus large mais discret.
La rétention se pilote signal par signal via les politiques TTL de ClickHouse. SigNoz expose ce réglage dans son interface. On garde rarement les trois signaux sur la même durée : les traces sont volumineuses et leur intérêt décroît vite, les métriques agrégées se conservent longtemps pour peu cher, les logs dépendent de la contrainte de conformité. Le piège classique : laisser la rétention par défaut et découvrir trois mois plus tard que le disque ClickHouse sature. La rétention est une décision d'architecture, pas un réglage qu'on oublie.
Pour les choix de stockage de séries temporelles à grande échelle, notre comparatif sur VictoriaMetrics comme TSDB de supervision éclaire les arbitrages coût/rétention sur le pilier métriques.
Licence : open core, pas open washing
Point à vérifier parce qu'il bouge, et qu'on n'invente pas. État au moment où on écrit : le cœur de SigNoz est sous licence MIT (Expat), le dossier ee (enterprise edition) est sous une licence SigNoz Enterprise propriétaire. Modèle open core classique. Le cœur MIT est pleinement fonctionnel : APM unifié, logs, traces, métriques via OpenTelemetry, sans frais par host ni par Go ingéré.
Ce qui est réservé à l'édition Enterprise : le SSO SAML/OIDC, le RBAC fin, et la fonction Ingest Guard. Autrement dit, les briques de gouvernance d'accès et de contrôle d'ingestion en environnement multi-équipes. Pour une équipe ops qui veut une observabilité self-hosted sans budget de licence, le cœur MIT suffit. Pour une grande organisation avec des exigences d'authentification fédérée et de cloisonnement, l'addition Enterprise se discute. La distinction est nette et documentée, pas du vernis open source sur un produit verrouillé.
L'angle FinOps : pourquoi ça revient moins cher
Le moteur du débat, c'est le coût. Datadog facture l'infrastructure à partir de 15 $ par host et par mois, l'APM à partir de 31 $ par host et par mois, plus la gestion de logs au Go ingéré et au million d'événements indexés (source : grille de prix Datadog et analyse SigNoz citées en sources). Le problème n'est pas le tarif unitaire, c'est l'accumulation : chaque module activé facture en parallèle sur une unité différente, et sur Kubernetes la surface monitorée se révèle souvent 3 à 5 fois supérieure à l'estimation contractuelle.
Selon les analyses sectorielles citées en sources, les factures d'observabilité SaaS croissent de 30 à 50 % par an pour beaucoup d'équipes, et les dépassements 2x à 3x au-dessus du budget initial sont fréquents à l'échelle. On ne reprend pas ces chiffres comme une vérité absolue, mais l'ordre de grandeur est documenté et constant d'une source à l'autre.
En self-hosted, le modèle change de nature. Le coût devient celui de l'infrastructure ClickHouse et du temps d'exploitation, pas de l'ingestion. Une fois le serveur dimensionné, ingérer plus d'événements ne déclenche pas de ligne de facturation supplémentaire, ça consomme du disque et du CPU déjà provisionnés. Le coût devient prévisible et linéaire, là où le SaaS devient exponentiel et opaque.
Le trade-off est honnête : on échange une facture qui grimpe contre du temps d'ingénierie pour opérer la stack. Ce n'est rentable que si le volume justifie l'effort, ou si la souveraineté de la donnée de télémétrie est une contrainte non négociable. Sur cet arbitrage build vs buy en supervision, notre analyse FinOps en production pose la méthode de calcul.
SigNoz tout-en-un ou stack Grafana modulaire
La vraie question pour une équipe SRE, ce n'est pas SigNoz contre Datadog, c'est SigNoz contre la stack Grafana self-hosted : Prometheus pour les métriques, Loki pour les logs, Tempo pour les traces, le tout visualisé dans Grafana.
| Critère | SigNoz | Stack Grafana (LGTM) |
| Backends à opérer | Un seul (ClickHouse) | Plusieurs (Prometheus/Mimir, Loki, Tempo) |
| Corrélation des signaux | Native, schéma partagé | À construire via alignement de labels |
| Instrumentation | OpenTelemetry natif | OTel possible, Prometheus historique |
| Langage de requête | Query builder unifié sur ClickHouse | PromQL, LogQL, TraceQL distincts |
| Maturité écosystème | Plus jeune | Très mature, large communauté |
| Flexibilité par composant | Faible (monolithe cohérent) | Forte (chaque brique remplaçable) |
Le verdict côté ops. SigNoz gagne quand on veut démarrer vite une observabilité OpenTelemetry cohérente avec un seul backend à maîtriser, et que la corrélation immédiate entre les trois signaux a de la valeur. C'est le choix d'une équipe qui ne veut pas devenir experte de quatre systèmes différents.
La stack Grafana garde l'avantage quand on a déjà du Prometheus en place et une expertise PromQL installée, quand on veut remplacer un composant sans toucher aux autres, ou quand la maturité et la taille de l'écosystème pèsent dans la décision. La modularité est un atout réel pour qui sait l'opérer, un fardeau pour qui ne veut pas.
Pour creuser chaque brique de l'alternative modulaire : Prometheus, Grafana et Alertmanager sur le pilier métriques et alerting, la stack de logging Loki pour les logs, et Grafana Tempo pour le tracing distribué.
Ce qu'on retient
SigNoz est un pari cohérent : un seul backend ClickHouse, OpenTelemetry de bout en bout, les trois signaux corrélés sans effort. Le gain de simplicité d'exploitation est réel face à un assemblage de quatre outils. L'angle FinOps tient debout : en self-hosted, le coût redevient prévisible quand le SaaS dérive.
La contrepartie est l'exploitation de ClickHouse, qui devient le point critique unique et dont le dimensionnement et la rétention demandent un vrai travail d'architecture. Ce n'est pas un produit qu'on installe et qu'on oublie. Pour une équipe qui veut de l'observabilité souveraine, standardisée sur OpenTelemetry, et qui accepte d'opérer son stockage, SigNoz est un candidat sérieux. Pour qui a déjà investi dans l'écosystème Prometheus/Grafana et en maîtrise la modularité, le statu quo se défend.
Déployer une plateforme d'observabilité self-hosted, dimensionner ClickHouse et tenir la rétention dans la durée, c'est un travail d'exploitation continu. Si votre supervision a besoin d'être conçue, opérée et tenue au niveau sans y consacrer une équipe interne, on peut prendre en charge la stack en infogérance.
Sources
- SigNoz sur GitHub : dépôt officiel, description de la plateforme, architecture OpenTelemetry native et stockage ClickHouse.
- SigNoz : observabilité sur ClickHouse et OpenTelemetry (blog ClickHouse) : retour de l'éditeur de ClickHouse sur l'usage en magasin unique pour traces, métriques et logs.
- Licence SigNoz (fichier LICENSE) : état exact de la licence, cœur MIT Expat et dossier enterprise sous licence propriétaire.
- Datadog Pricing Explained (SigNoz) : décomposition du modèle de facturation Datadog par host, logs et module, et ses effets à l'échelle.
- Modern Grafana Alternative (SigNoz) : comparaison structurée entre l'approche tout-en-un et la stack Grafana LGTM modulaire.
