Installer OpenObserve sur un VPS Linux : logs, métriques et traces centralisés

OpenObserve est une plateforme d'observabilité open source, écrite en Rust, qui centralise dans un seul outil les logs, les métriques et les traces de vos serveurs, avec des tableaux de bord, des alertes et des requêtes en SQL ou en PromQL. Sur un VPS, elle remplace la lecture des journaux serveur par serveur en SSH : chaque machine envoie ses journaux systemd, ses fichiers de log et ses métriques système vers une instance unique, consultable depuis un navigateur. Ce guide montre comment installer OpenObserve sur un VPS Linux Debian ou Ubuntu, en Docker Compose ou en binaire géré par systemd, le publier en HTTPS derrière Nginx sans exposer son port, puis y brancher vos premières sources de données : un test en curl, l'agent Linux officiel et Prometheus.

Sources : documentation de démarrage d'OpenObserve, référence des variables d'environnement, page de téléchargement et dépôt GitHub du projet.

OpenObserve en bref : ce que vous installez

OpenObserve stocke les données reçues au format Parquet, un format en colonnes et compressé, sur le disque local ou dans un stockage objet compatible S3. L'éditeur met en avant un coût de stockage 140 fois inférieur à celui d'Elasticsearch pour les logs ; c'est son propre chiffre, à vérifier sur vos volumes. Par défaut, OpenObserve tourne en mode local, sur un seul nœud : les métadonnées (utilisateurs, flux, tableaux de bord, alertes) vont dans une base SQLite, les données dans le dossier défini par ZO_DATA_DIR. La documentation d'architecture recommande ce mode pour un usage léger, les tests et tout déploiement qui n'a pas besoin de haute disponibilité : c'est exactement le cas d'un VPS qui surveille quelques serveurs.

Quelle version et quelle édition choisir

Au 13 novembre 2026, la dernière version stable d'OpenObserve est la v1.1.2, publiée le 20 octobre 2026. Une v1.2.0-rc2 est sortie le 12 novembre : c'est une release candidate, à réserver à une instance de test. Épinglez toujours le numéro de version dans votre fichier Compose ou votre script d'installation plutôt que latest : vous choisissez le moment de la mise à jour au lieu de la subir au prochain redémarrage.

Deux éditions existent, et le guide de démarrage officiel utilise désormais l'image Enterprise dans ses exemples. Ce guide installe l'édition open source, image openobserve/openobserve.

Prérequis et dimensionnement du VPS

• Un VPS Linux sous Debian 12 ou 13 ou Ubuntu 24.04 LTS, en amd64 ou arm64 (les deux architectures sont publiées), avec un accès root ou sudo.
• Docker et le plugin Compose pour la méthode recommandée : suivez notre guide pour installer Docker sur un VPS.
• Un nom de domaine, par exemple logs.votre-domaine.fr, dont l'enregistrement DNS A pointe vers l'IP du VPS, pour l'accès en HTTPS.
• Les ports 80 et 443 ouverts dans le pare-feu ; les ports 5080 et 5081 restent fermés depuis l'extérieur.

OpenObserve ne publie pas de configuration minimale pour un nœud unique. Deux points de sa documentation guident le choix de l'offre. D'abord, le stockage : les données arrivent dans un WAL sur le disque local avant d'être converties en Parquet, ce qui demande un disque rapide (le guide de performance cite 3000 IOPS comme suffisant pour la plupart des charges), donc un SSD NVMe plutôt qu'un disque partagé lent. Ensuite, l'espace disque dépend de votre volume de logs et de la rétention choisie : commencez avec une rétention courte, mesurez la croissance du dossier de données pendant une semaine, puis ajustez. Si OpenObserve doit recevoir les logs de plusieurs serveurs de jeu chargés, installez-le sur une machine distincte de celles qu'il surveille : une panne du serveur surveillé ne doit pas emporter ses propres journaux.

Installer OpenObserve avec Docker Compose

Créez un dossier dédié, puis un fichier de variables d'environnement qui contiendra l'identifiant administrateur. Générez un mot de passe solide plutôt que de reprendre celui des exemples de la documentation :

sudo mkdir -p /opt/openobserve && cd /opt/openobserve
openssl rand -base64 24
sudo nano openobserve.env

Contenu de openobserve.env, à adapter :

ZO_ROOT_USER_EMAIL=admin@votre-domaine.fr
ZO_ROOT_USER_PASSWORD=collez-ici-le-mot-de-passe-genere
ZO_DATA_DIR=/data
ZO_TELEMETRY=false
ZO_COMPACT_DATA_RETENTION_DAYS=30
ZO_WEB_URL=https://logs.votre-domaine.fr
ZO_COOKIE_SECURE_ONLY=true

Chaque ligne a un rôle précis. ZO_ROOT_USER_EMAIL et ZO_ROOT_USER_PASSWORD créent le compte root, et uniquement au premier démarrage : les modifier ensuite dans ce fichier ne change pas le mot de passe, il faudra le faire depuis l'interface. ZO_TELEMETRY=false coupe l'envoi de statistiques anonymes. ZO_COMPACT_DATA_RETENTION_DAYS=30 supprime automatiquement les données de plus de 30 jours au lieu des 10 ans par défaut. ZO_WEB_URL indique l'adresse publique de l'interface, utilisée pour les redirections et les liens des alertes. ZO_COOKIE_SECURE_ONLY=true réserve le cookie de session au HTTPS, puisque l'accès passera par Nginx avec un certificat. Protégez le fichier : sudo chmod 600 openobserve.env.

Créez ensuite docker-compose.yml dans le même dossier :

services:
  openobserve:
    image: openobserve/openobserve:v1.1.2
    container_name: openobserve
    restart: unless-stopped
    env_file: openobserve.env
    ports:
      - "127.0.0.1:5080:5080"
    volumes:
      - ./data:/data

La ligne importante est 127.0.0.1:5080:5080. La documentation de Docker le rappelle : un port publié par Docker contourne les règles d'UFW, car le trafic est redirigé vers le conteneur avant de passer par le pare-feu. Publier le port 5080 sans préciser l'adresse le rendrait donc accessible depuis Internet même avec UFW actif. En le liant à 127.0.0.1, seul Nginx, sur la même machine, peut l'atteindre. Le port gRPC 5081 n'est pas publié du tout. Si vous découvrez Compose, notre guide Docker Compose sur un VPS Linux détaille ces notions.

Démarrez le conteneur, suivez son journal, puis interrogez le point de contrôle de santé :

sudo docker compose up -d
sudo docker compose logs -f openobserve
curl http://127.0.0.1:5080/healthz

La dernière commande doit répondre {"status":"ok"}. Les données apparaissent dans /opt/openobserve/data : c'est ce dossier qu'il faudra sauvegarder.

Variante : le binaire et un service systemd

Sans Docker, OpenObserve s'installe sous forme d'un binaire unique. Le script officiel downloadO2.sh télécharge l'archive de l'édition et de la version demandées pour votre système et votre architecture, puis l'extrait dans le dossier courant. Passez-lui explicitement l'édition open source et la version, sinon il prend l'édition Enterprise par défaut :

cd /tmp
curl -L https://raw.githubusercontent.com/openobserve/openobserve/main/downloadO2.sh -o downloadO2.sh
less downloadO2.sh
sh downloadO2.sh opensource v1.1.2
sudo install -m 755 openobserve /usr/local/bin/openobserve

La documentation d'OpenObserve fait tourner le service en root, avec les données dans /data/openobserve. Nous préférons un utilisateur système dédié, sans shell, et un dossier dans /var/lib :

sudo useradd --system --home-dir /var/lib/openobserve --shell /usr/sbin/nologin openobserve
sudo install -d -o openobserve -g openobserve -m 750 /var/lib/openobserve

Le fichier /etc/openobserve.env reprend les variables de la méthode Docker, avec deux différences : le chemin des données et l'adresse d'écoute, limitée à la boucle locale.

ZO_ROOT_USER_EMAIL=admin@votre-domaine.fr
ZO_ROOT_USER_PASSWORD=collez-ici-le-mot-de-passe-genere
ZO_DATA_DIR=/var/lib/openobserve
ZO_HTTP_ADDR=127.0.0.1
ZO_TELEMETRY=false
ZO_COMPACT_DATA_RETENTION_DAYS=30
ZO_WEB_URL=https://logs.votre-domaine.fr
ZO_COOKIE_SECURE_ONLY=true

Puis l'unité /etc/systemd/system/openobserve.service, construite sur celle de la documentation officielle, avec l'utilisateur dédié en plus :

[Unit]
Description=OpenObserve
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=openobserve
Group=openobserve
LimitNOFILE=65535
EnvironmentFile=/etc/openobserve.env
ExecStart=/usr/local/bin/openobserve
ExecStop=/bin/kill -s QUIT $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo chmod 600 /etc/openobserve.env
sudo systemctl daemon-reload
sudo systemctl enable --now openobserve
systemctl status openobserve
curl http://127.0.0.1:5080/healthz

Ici, pas de Docker : UFW s'applique normalement, et une politique « deny » en entrée bloque déjà les ports 5080 et 5081. Pour la syntaxe des unités et la lecture de leurs journaux, voir notre guide pour créer un service systemd sur Linux.

Publier l'interface en HTTPS derrière Nginx

Les API d'ingestion et de recherche d'OpenObserve s'authentifient en HTTP Basic, et l'interface reçoit votre mot de passe à chaque connexion : tout accès depuis l'extérieur doit passer par HTTPS. Créez un bloc serveur Nginx pour votre sous-domaine, par exemple /etc/nginx/sites-available/openobserve :

server {
    listen 80;
    server_name logs.votre-domaine.fr;

    client_max_body_size 50m;

    location / {
        proxy_pass http://127.0.0.1:5080;
        proxy_http_version 1.1;
        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_buffering off;
        proxy_read_timeout 300s;
    }
}

Trois directives méritent une explication. client_max_body_size vaut 1 Mo par défaut dans Nginx, alors qu'un agent envoie ses logs par lots qui dépassent vite cette taille : sans cette ligne, l'ingestion échoue avec une erreur 413. OpenObserve accepte de son côté jusqu'à 200 Mo par requête (ZO_PAYLOAD_LIMIT). proxy_buffering off laisse passer au fil de l'eau les résultats de recherche, qu'OpenObserve renvoie en flux (ZO_STREAMING_ENABLED est actif par défaut). Enfin, l'en-tête X-Real-IP fait partie des sources qu'OpenObserve lit par défaut (ZO_HTTP_REAL_IP_SOURCE) pour connaître l'adresse réelle du client derrière le proxy.

sudo ln -s /etc/nginx/sites-available/openobserve /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d logs.votre-domaine.fr

Certbot ajoute le bloc HTTPS et la redirection depuis le port 80. Les détails sont dans nos guides Nginx en reverse proxy sur un VPS Linux et Certbot et Let's Encrypt. Ouvrez les ports web dans UFW si ce n'est pas déjà fait (sudo ufw allow 'Nginx Full') ; le guide ouvrir des ports avec UFW rappelle les règles de base.

Pour servir OpenObserve sous un sous-chemin (votre-domaine.fr/logs/) plutôt qu'un sous-domaine, ajoutez ZO_BASE_URI=/logs et adaptez le bloc location, comme le montre la documentation officielle. Si l'interface ne doit être vue que par votre équipe, restreignez-la par adresse IP dans Nginx, ou ne la publiez pas du tout et accédez-y à travers un réseau privé, comme décrit dans notre guide Tailscale sur un VPS Linux.

Première connexion et premier log

Ouvrez https://logs.votre-domaine.fr et connectez-vous avec l'e-mail et le mot de passe du fichier d'environnement. Envoyez ensuite un premier événement depuis le VPS, vers un flux (stream) nommé test dans l'organisation default, avec l'API d'ingestion JSON :

curl -u 'admin@votre-domaine.fr:VOTRE_MOT_DE_PASSE' \
  -H 'Content-Type: application/json' \
  -d '[{"level":"info","service":"test","message":"premier log envoyé depuis le VPS"},
       {"level":"error","service":"test","message":"erreur de test"}]' \
  http://127.0.0.1:5080/api/default/test/_json

La réponse attendue ressemble à {"code":200,"status":[{"name":"test","successful":2,"failed":0}]}. Un flux se crée tout seul à la première ingestion, et OpenObserve déduit son schéma des champs reçus : inutile de déclarer un index ou un mapping à l'avance. Dans le menu des logs de l'interface, choisissez le flux test : vos deux événements apparaissent, horodatés dans le champ _timestamp.

Pour l'ingestion, évitez de distribuer le mot de passe root sur tous vos serveurs : la page de l'interface consacrée aux sources de données (Data sources) affiche des commandes et des configurations prêtes à copier, avec l'adresse de votre instance et le jeton à utiliser.

Collecter journald, /var/log et les métriques avec l'agent Linux

Pour chaque serveur à surveiller, y compris le VPS d'OpenObserve lui-même, l'interface propose une commande d'installation de l'agent Linux, déjà remplie avec votre URL et votre clé. Elle a cette forme :

curl -O https://raw.githubusercontent.com/openobserve/agents/main/linux/install.sh
chmod +x install.sh && sudo ./install.sh https://logs.votre-domaine.fr/api/default/ VOTRE_CLE

Lisez le script avant de le lancer : il s'exécute en root. Voici ce qu'il fait dans sa version actuelle. Il installe OpenTelemetry Collector Contrib (otelcol-contrib 0.163.1) dans /usr/local/bin, écrit sa configuration dans /etc/otel-config.yaml et crée le service systemd otel-collector, qui tourne sous l'utilisateur openobserve-agent ajouté aux groupes systemd-journal et adm pour lire les journaux. Il collecte :

• le journal systemd (journald), envoyé dans un flux journald ;
• les fichiers qui correspondent à /var/log/**log ;
• les métriques système toutes les 30 secondes : CPU, mémoire, disques, systèmes de fichiers, charge, réseau, pagination et processus.

Le transport se fait en OTLP/HTTP vers /api/default/v1/logs et ses équivalents pour les métriques, à travers votre Nginx : c'est là que la directive client_max_body_size évite les rejets. Vérifiez ensuite le service avec systemctl status otel-collector et journalctl -u otel-collector -f.

Pour un serveur de jeu, le plus simple est de le faire tourner comme service systemd : tout ce qu'il écrit dans sa console part alors dans journald, et donc dans OpenObserve, sans configuration supplémentaire. Si son journal est un fichier dans son propre dossier, par exemple logs/latest.log d'un serveur Minecraft, ajoutez le chemin au récepteur filelog/std de /etc/otel-config.yaml, vérifiez que l'utilisateur openobserve-agent peut lire le fichier et les dossiers parents, puis redémarrez otel-collector. Notre guide analyser les logs d'un serveur de jeu avec journalctl explique d'où viennent ces journaux et comment les filtrer en local.

Les autres collecteurs fonctionnent aussi. Fluent Bit, par exemple, envoie vers OpenObserve avec sa sortie http : URI /api/default/<flux>/_json, format json, Json_date_key _timestamp, Json_date_format iso8601 et les identifiants en HTTP_User et HTTP_Passwd. Vector, Filebeat, Fluentd, Telegraf et le syslog figurent aussi dans la documentation d'ingestion.

Envoyer les métriques de Prometheus

Si vous avez déjà un Prometheus, par exemple celui de notre guide Grafana et Prometheus pour surveiller un serveur de jeu, OpenObserve peut recevoir ses séries par remote write et les interroger ensuite en PromQL. Ajoutez dans prometheus.yml :

remote_write:
  - url: https://logs.votre-domaine.fr/api/default/prometheus/api/v1/write
    basic_auth:
      username: admin@votre-domaine.fr
      password: VOTRE_MOT_DE_PASSE
    queue_config:
      max_samples_per_send: 10000

Prometheus continue de collecter les exporters comme avant ; OpenObserve devient le stockage longue durée et l'outil de requête commun à vos logs et à vos métriques. Rechargez Prometheus, puis cherchez vos séries dans le menu des métriques.

Interroger les logs en SQL

L'explorateur de logs accepte une recherche simple ou une requête SQL, exécutée sur un intervalle de temps choisi dans l'interface. Quelques requêtes utiles sur le flux de test :

SELECT * FROM "test" WHERE level = 'error'

SELECT level, count(*) AS total FROM "test" GROUP BY level

SELECT * FROM "journald" WHERE match_all('error')

La fonction match_all fait une recherche plein texte insensible à la casse, mais seulement dans les champs indexés en texte intégral : par défaut log, message, msg, content, data, body, json et error, modifiables dans les paramètres du flux. Quand vous savez dans quel champ chercher, str_match(champ, 'valeur'), sensible à la casse, coûte moins cher. La documentation conseille aussi de combiner match_all avec un filtre, sur un hôte ou un service par exemple, pour éviter de parcourir toutes les données de l'intervalle.

Rétention, espace disque et stockage S3

La rétention globale se règle avec ZO_COMPACT_DATA_RETENTION_DAYS (minimum 3 jours), et chaque flux peut avoir sa propre durée dans ses paramètres : gardez par exemple 7 jours de logs de debug et 90 jours de journaux de connexion. C'est le compacteur d'OpenObserve qui fusionne les petits fichiers Parquet et supprime les données expirées. Surveillez la taille du dossier de données (sudo du -sh /opt/openobserve/data) et l'espace libre, avec la méthode de notre guide pour surveiller l'espace disque d'un VPS Linux : un disque plein bloque l'ingestion.

Pour garder plus longtemps sans agrandir le disque du VPS, le mode local sait écrire les fichiers Parquet dans un stockage objet compatible S3, en gardant un seul nœud : ZO_LOCAL_MODE_STORAGE=s3, puis ZO_S3_SERVER_URL, ZO_S3_REGION_NAME, ZO_S3_BUCKET_NAME, ZO_S3_ACCESS_KEY, ZO_S3_SECRET_KEY et ZO_S3_PROVIDER (minio pour MinIO, s3 pour une API compatible S3 générique). La documentation d'architecture précise le compromis : une latence de lecture un peu plus élevée, contre plus de durabilité et de capacité.

Alertes et tableaux de bord

Une fois les données arrivées, OpenObserve permet de créer des tableaux de bord sur n'importe quel flux et des alertes programmées ou en temps réel, définies par une condition ou une requête SQL. Les notifications partent vers des destinations à créer dans la partie gestion : e-mail (avec un serveur SMTP configuré) ou webhook, avec des modèles pour Slack, Discord ou Microsoft Teams. Une bonne première alerte : plus de N lignes contenant « error » sur cinq minutes dans le flux journald d'un serveur de jeu. Pour choisir quoi surveiller et à quels seuils, voir notre guide sur les alertes de monitoring d'un VPS Linux. OpenObserve ne vérifie pas qu'un service répond depuis l'extérieur : pour cela, complétez avec Uptime Kuma.

Mettre à jour et sauvegarder

Avant toute mise à jour, lisez les notes de version sur GitHub, puis sauvegardez le dossier de données, service arrêté pour que la base SQLite et le WAL soient cohérents :

cd /opt/openobserve
sudo docker compose stop
sudo tar czf /root/openobserve-$(date +%F).tar.gz data
sudo docker compose start

Pour passer à une nouvelle version stable, modifiez le tag dans docker-compose.yml, puis lancez sudo docker compose pull && sudo docker compose up -d. En installation binaire, relancez downloadO2.sh avec la nouvelle version, remplacez /usr/local/bin/openobserve et redémarrez le service. Copiez aussi l'archive hors du VPS : notre guide pour sauvegarder un VPS avec rsync vers un serveur distant donne la méthode.

Un VPS Linux séparé suffit pour centraliser les logs de quelques serveurs, qu'il s'agisse d'un serveur FiveM, d'un serveur Minecraft ou de vos services web. Pour une rétention longue ou un gros volume de logs, un serveur dédié offre plus de disque et de mémoire.