Pourquoi une base unique pour l'observabilité
Métriques, logs et traces décrivent le même incident sous trois angles. Quand ils vivent dans trois outils, on passe d'un onglet à l'autre en recopiant des horodatages, et la question « quelles requêtes lentes ont précédé ces erreurs ? » demande trois requêtes dans trois langages.
GreptimeDB les range tous dans des tables, dans un moteur en colonnes conçu pour les séries temporelles. Les métriques reçues de Prometheus restent interrogeables en PromQL, et tout — métriques, logs et traces — s'interroge aussi en SQL, avec jointures et agrégats. Grafana la voit comme une source Prometheus ordinaire.
Ce que GreptimeDB apporte
- Trois signaux, un moteur — métriques, logs et traces dans des tables d'un même stockage en colonnes.
- SQL et PromQL — jointures, fenêtres et agrégats en SQL ; vos requêtes PromQL fonctionnent telles quelles.
- Compatible Prometheus — cible
remote_write, API de requête Prometheus, source de données Grafana sans plugin. - OpenTelemetry natif — ingestion OTLP/HTTP des métriques, des logs et des traces.
- Autres protocoles — API push de Loki, line protocol d'InfluxDB, API SQL en HTTP.
- Tableau de bord intégré — éditeur SQL et PromQL, exploration des tables, graphiques des résultats.
GreptimeDB face à une pile Prometheus, Loki et Tempo
Faites défiler le tableau
| GreptimeDB | Prometheus + Loki + Tempo | |
|---|---|---|
| Services à exploiter | Un seul conteneur | Trois services, trois configurations |
| Langages de requête | SQL et PromQL | PromQL, LogQL et TraceQL |
| Croiser logs et métriques | Une requête SQL | Plusieurs requêtes, à la main |
| Ingestion | remote_write, OTLP, Loki, InfluxDB, SQL | Un protocole par service |
| Grafana | Source de données Prometheus | Une source par service |
| Rétention | Par base ou par table, en SQL | Un réglage par service |
Prérequis
Un VPS Ubuntu 24.04 avec 2 Go de RAM suffit pour démarrer ; prévoyez 4 Go et davantage de disque si vous centralisez de nombreux services, car les logs et les traces occupent bien plus de place que les métriques. Il vous faut Docker avec le plugin Compose, et un nom de domaine pointant vers le VPS, avec nginx et un certificat HTTPS : vos serveurs y enverront leurs données et Grafana l'interrogera.
Installer GreptimeDB avec Docker Compose
Préparer le répertoire et le mot de passe
Créez le répertoire de l'application et un fichier
.envqui porte le mot de passe de l'utilisateuradmin.mkdir -p /opt/greptimedb && cd /opt/greptimedb echo "ADMIN_PASSWORD=$(openssl rand -hex 16)" > .env chmod 600 .envÉcrire le docker-compose.yml
Le port n'est publié que sur la boucle locale : seul nginx y accède. L'option
--user-providerdéclare l'utilisateuradminet protège toute l'API HTTP. La variableGREPTIMEDB_STANDALONE__ENABLE_TELEMETRYcoupe le rapport d'usage anonyme envoyé à l'éditeur.services: greptimedb: image: greptime/greptimedb:v1.3.0 restart: unless-stopped ports: - "127.0.0.1:4000:4000" environment: GREPTIMEDB_STANDALONE__ENABLE_TELEMETRY: "false" command: - standalone - start - --http-addr=0.0.0.0:4000 - --data-home=/greptimedb_data - --user-provider=static_user_provider:cmd:admin=${ADMIN_PASSWORD} volumes: - greptimedb-data:/greptimedb_data volumes: greptimedb-data: {}Démarrer et vérifier
Le démarrage prend quelques secondes.
/healthrépond sans authentification ; l'API SQL, elle, renvoie 401 sans identifiants.docker compose up -d curl -fsS http://127.0.0.1:4000/health curl -u admin:VOTRE_MOT_DE_PASSE http://127.0.0.1:4000/v1/sql -d 'sql=SHOW TABLES'Publier en HTTPS avec nginx
Dans le vhost de votre domaine (certificat obtenu par certbot), proxifiez vers le port local. Relevez
client_max_body_size: les lotsremote_writeet OTLP dépassent vite la limite par défaut.location / { proxy_pass http://127.0.0.1:4000; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 32m; }
Sans --user-provider, la base est ouverte à tous
Sans fournisseur d'utilisateurs, GreptimeDB accepte toute requête : quiconque connaît l'adresse peut lire vos logs et écrire, modifier ou supprimer des tables en SQL. Gardez l'authentification active, et ne publiez jamais le port 4000 directement sur l'IP publique : passez toujours par le reverse proxy HTTPS. Les ports gRPC, MySQL et PostgreSQL de GreptimeDB n'ont pas à être publiés non plus.
Envoyer les métriques de Prometheus
Dans le prometheus.yml de chaque serveur, ajoutez un bloc remote_write vers GreptimeDB. Le paramètre db désigne la base de destination ; public existe dès le premier démarrage.
remote_write:
- url: https://greptime.example.ma/v1/prometheus/write?db=public
basic_auth:
username: admin
password: VOTRE_MOT_DE_PASSERechargez Prometheus : chaque métrique devient une table, visible avec SHOW TABLES; dans le tableau de bord.
Envoyer logs et traces par OpenTelemetry
Dans l'OpenTelemetry Collector (ou directement dans le SDK de votre application), déclarez un exportateur OTLP/HTTP vers GreptimeDB. L'en-tête Authorization porte admin:mot-de-passe encodé en Base64, et les traces exigent en plus l'en-tête X-Greptime-Pipeline-Name: greptime_trace_v1. Déclarez donc deux exportateurs : posé sur les logs, cet en-tête les fait refuser.
exporters:
otlphttp/greptime:
endpoint: https://greptime.example.ma/v1/otlp
headers:
Authorization: "Basic BASE64_ADMIN_MOT_DE_PASSE"
otlphttp/greptime-traces:
endpoint: https://greptime.example.ma/v1/otlp
headers:
Authorization: "Basic BASE64_ADMIN_MOT_DE_PASSE"
X-Greptime-Pipeline-Name: greptime_trace_v1
service:
pipelines:
logs:
exporters: [otlphttp/greptime]
metrics:
exporters: [otlphttp/greptime]
traces:
exporters: [otlphttp/greptime-traces]Les métriques arrivent sur /v1/otlp/v1/metrics, les logs sur /v1/otlp/v1/logs et les traces sur /v1/otlp/v1/traces : le collecteur ajoute ces suffixes lui-même. Si vous envoyez déjà vos logs à Loki, Promtail et Grafana Alloy peuvent viser /v1/loki/api/v1/push.
Interroger GreptimeDB depuis Grafana
Dans Grafana, ajoutez une source de données de type Prometheus avec l'URL https://votre-domaine/v1/prometheus, activez l'authentification basique et saisissez l'utilisateur admin et son mot de passe. Vos tableaux de bord PromQL fonctionnent sans modification.
Pour les logs et les traces, écrivez vos requêtes en SQL dans le tableau de bord intégré (https://votre-domaine/dashboard/), où les identifiants se saisissent dans les paramètres de connexion. Une requête comme SELECT * FROM opentelemetry_logs ORDER BY timestamp DESC LIMIT 50; affiche les derniers logs reçus.
Rétention, disque et sauvegarde
Sans réglage, GreptimeDB ne supprime rien. La rétention se fixe en SQL, pour une base entière ou par table (option ttl à la création). La commande COPY DATABASE exporte une base au format Parquet dans le volume de données, sous /greptimedb_data/copy/ :
ALTER DATABASE public SET 'ttl'='90d';
COPY DATABASE public TO 'backup/' WITH (FORMAT='parquet');Copiez ensuite ce dossier hors du VPS, ou sauvegardez le volume Docker greptimedb-data entier, conteneur arrêté. Surveillez l'espace disque : c'est presque toujours la taille des logs qui décide.
Mettre à jour GreptimeDB
Lisez d'abord les notes de version : une montée de version majeure peut demander une étape de migration. Changez le tag de l'image dans docker-compose.yml, puis :
cd /opt/greptimedb
docker compose pull && docker compose up -d
docker compose logs --tail 20Les données du volume sont conservées. Faites un COPY DATABASE juste avant une mise à jour majeure : c'est votre point de retour.
Installation en un clic depuis le Marketplace ServOrbit
Le Marketplace ServOrbit installe GreptimeDB sur votre VPS sans ligne de commande : il déploie le conteneur officiel, génère le mot de passe de l'utilisateur admin, active l'authentification sur toute l'API HTTP, coupe le rapport d'usage anonyme et publie le tableau de bord en HTTPS sur un sous-domaine de votre domaine ou sur le sous-domaine gratuit du VPS (greptimedb.{dns_slug}.servorbit-dns.com). Le mot de passe s'affiche dans votre espace client ; il ne reste qu'à brancher Prometheus, OpenTelemetry et Grafana.
