Installer OpenObserve et ingérer ses premières données

1. Installer OpenObserve #

Binaire ou Docker Compose.

Avec Docker Compose #

services:
  openobserve:
    image: public.ecr.aws/zinclabs/openobserve:latest
    ports:
      - "5080:5080"
    environment:
      ZO_DATA_DIR: /data
      ZO_ROOT_USER_EMAIL: root@example.com
      ZO_ROOT_USER_PASSWORD: Complexpass#123
    volumes:
      - o2-data:/data

volumes:
  o2-data:

docker compose up -d
curl http://localhost:5080/healthz
# {"status":"ok"}

L'interface est sur http://localhost:5080. Les identifiants de l'utilisateur racine ne servent qu'au premier démarrage : les changer ensuite dans le fichier ne change pas le mot de passe.

Avec le binaire #

ZO_ROOT_USER_EMAIL=root@example.com ZO_ROOT_USER_PASSWORD='Complexpass#123' ./openobserve

Erreur GLIBC_2.xx not found ? Nous l'avons rencontrée sur Debian 12. Prenez l'archive -linux-amd64-musl, qui ne dépend pas de la version de la glibc.

2. Les variables à connaître #

Tout se configure par l'environnement.

Réglages principaux #

Stocker dans S3 ou MinIO #

En mode local, on peut déjà sortir les données du disque. Le dossier local garde alors le WAL et les fichiers temporaires.

ZO_LOCAL_MODE: "true"
ZO_LOCAL_MODE_STORAGE: s3
ZO_S3_SERVER_URL: http://minio:9000
ZO_S3_REGION_NAME: us-east-1
ZO_S3_BUCKET_NAME: openobserve
ZO_S3_ACCESS_KEY: minioadmin
ZO_S3_SECRET_KEY: minioadmin
ZO_S3_PROVIDER: minio

3. Première ingestion #

Envoyer et retrouver des événements.

Envoyer #

Le chemin est toujours /api/<organisation>/<flux>/_json. Le flux est créé s'il n'existe pas.

curl -u 'root@example.com:Complexpass#123' \
  -H 'Content-Type: application/json' \
  http://localhost:5080/api/default/commandes/_json \
  -d '[
    {"level":"error","service":"paiement","message":"timeout vers la banque","duree_ms":3100},
    {"level":"info","service":"paiement","message":"ok","duree_ms":120},
    {"level":"info","service":"panier","message":"ok","duree_ms":40}
  ]'
# {"code":200,"status":[{"name":"commandes","successful":3,"failed":0}]}

Interroger #

L'API de recherche attend du SQL et une période en microsecondes.

NOW=$(date +%s)
curl -s -u 'root@example.com:Complexpass#123' \
  -H 'Content-Type: application/json' \
  http://localhost:5080/api/default/_search \
  -d "{\"query\":{
        \"sql\":\"SELECT service, count(*) AS n, avg(duree_ms) AS moy FROM commandes GROUP BY service ORDER BY n DESC\",
        \"start_time\":$(( (NOW-3600)*1000000 )),
        \"end_time\":$(( (NOW+60)*1000000 )),
        \"from\":0,\"size\":10}}" | jq .hits

Ce que l'ingestion transforme #

Ces résultats ont été observés en envoyant {"Level":"INFO","http":{"status":500},"Tags":["a","b"]} :

Le piège des données anciennes : un événement de plus de 5 heures est refusé, tout en renvoyant un code HTTP 200. Le détail est dans la réponse : "successful":0,"failed":1,"error":"Too old data...". Lisez donc le corps de la réponse pour vos reprises d'historique, et augmentez ZO_INGEST_ALLOWED_UPTO si besoin.