Télémétrie en fichiers Parquet, interrogée en SQL
OpenObserve est une plateforme d'observabilité à héberger soi-même, dont le serveur est écrit en Rust. Elle reçoit logs, métriques et traces en OpenTelemetry (OTLP), ainsi que les données RUM des navigateurs et des applications mobiles, et range le tout en fichiers Parquet colonnaires. Logs et traces s'interrogent en SQL, les métriques en SQL ou en PromQL. Dashboards, alertes et incidents partagent la même interface web.
Le projet se présente comme une alternative à Datadog, Splunk et Elasticsearch, et comme une plateforme unique face à l'assemblage Grafana, Loki, Prometheus et Tempo. Sa particularité est de pouvoir tout écrire dans un bucket S3 ou compatible (GCS, MinIO, Azure Blob...), mode imposé en cluster. SigNoz et Superlog gardent leur télémétrie dans ClickHouse. Netdata part de l'autre bout : un agent par machine, qui stocke ses métriques sur place et ne les centralise que si l'on ajoute des nœuds parents.
Le comparatif des plateformes d'observabilité open source confronte le stockage objet d'OpenObserve aux bases des autres plateformes.
Nœuds sans état et pipelines qui filtrent avant stockage
- Démarrage en une commande : l'image Docker tourne seule sur le port 5080, le compte administrateur défini par deux variables d'environnement. Une instance unique garde ses métadonnées dans SQLite et ne demande aucun autre service.
- Des nœuds sans état en cluster : l'ingester passe les données par un journal local (WAL), les convertit en Parquet et les pousse vers le stockage objet, où le compactor fusionne les petits fichiers. Le querier ne garde que du cache. Le projet en tire des redémarrages rapides ; la durabilité repose sur le stockage objet.
- Pipelines à l'ingestion : un éditeur visuel enrichit, masque, réduit ou normalise les données avant stockage (fonctions VRL) et convertit des logs en métriques : ce qui est filtré à l'entrée n'occupe pas le bucket.
Édition open source sans SSO, données immuables dix ans
S3 n'est pas le réglage par défaut. Une instance seule écrit sur son disque local ; le stockage objet s'active par ZO_LOCAL_MODE_STORAGE. Il devient obligatoire en haute disponibilité, qui passe par Kubernetes et Helm et demande PostgreSQL (ou MySQL) pour les métadonnées, NATS pour coordonner les nœuds, et au moins un nœud de chaque rôle (router, ingester, compactor, querier, scheduler).
Le « 140 fois moins cher » se mesure contre Elasticsearch. Le chiffre vient d'un graphique du README, qui l'attribue à la compression du Parquet et au prix du stockage objet. La lecture se paie en cache : par défaut, un querier consacre la moitié de sa mémoire aux fichiers Parquet, et le cache disque peut prendre la moitié de l'espace libre.
Les données sont immuables et gardées dix ans par défaut. Une ligne ingérée ne se modifie ni ne se supprime : seules des périodes entières de rétention tombent. Sans réglage de ZO_COMPACT_DATA_RETENTION_DAYS ou de la rétention par flux, rien n'est effacé avant 3 650 jours.
L'édition open source n'a ni SSO ni rôles. Tous ses utilisateurs ont accès à toutes les fonctions. Elle est sous AGPL-3.0 ou ultérieure : qui expose une version modifiée en service réseau doit en publier le code.
L'édition entreprise est une image distincte, sous licence commerciale. Elle ajoute le SSO (OIDC, SAML 2.0, LDAP/AD), un RBAC à configurer avec OpenFGA, un journal d'audit, la recherche fédérée entre clusters et le masquage automatique des données sensibles. Les notes de la v1.0.0 comptent 80 commits côté entreprise pour 295 côté open source. Auto-hébergée, elle est gratuite jusqu'à 50 Go ingérés par jour, sur devis au-delà.
Une 1.0 de septembre 2026, 43 versions stables cette année. Le dépôt date de février 2023. La v1.0.0, première 1.x en disponibilité générale, est sortie le 11 septembre 2026, au terme d'une année à une version mineure par mois environ. Dernière version stable : v1.0.4, du 24 septembre, suivie d'une v1.1.0-rc1 le 30.