OpenObserve en production : bonnes pratiques

1. Passer en production #

Du nœud unique au cluster.

Quel mode choisir ? #

La haute disponibilité se déploie avec le chart Helm officiel, qui demande un stockage objet et PostgreSQL :

helm repo add openobserve https://charts.openobserve.ai
helm repo update
helm install o2 openobserve/openobserve -n openobserve --create-namespace -f values.yaml

2. Bonnes pratiques #

Ce qui évite les mauvaises surprises.

Données #

• Un flux par famille de logs : le schéma d'un flux trop hétérogène grossit vite, et ZO_COLS_PER_RECORD_LIMIT (1000 champs) rejette les événements au-delà.
• Rétention par flux : gardez longtemps l'audit, peu de temps les logs de débogage.
• Peu de partitions, sur peu de valeurs : niveau ou environnement, jamais un identifiant.
• Requêtes bornées dans le temps : c'est le premier levier de performance.

Sécurité #

• Changez le mot de passe racine, et ne l'utilisez pas pour la collecte.
• Placez OpenObserve derrière un proxy TLS.
• Gardez la protection SSRF active, en n'autorisant que les cibles nécessaires.
• Masquez les données sensibles dans un pipeline temps réel.

Exploitation #

• Sauvegardez : avec le disque local, le dossier de données entier ; en HA, le stockage objet et PostgreSQL.
• Épinglez un tag précis de l'image, comme o2cr.ai/openobserve/openobserve:v1.1.2, et lisez les notes de version.
• Supervisez OpenObserve : il expose ses métriques sur /metrics.
• Désactivez la télémétrie si votre politique l'exige : ZO_TELEMETRY=false.

3. Sources officielles #

Pour aller plus loin.

Documentation #

• Documentation d'OpenObserve
• Architecture
• Éditions et téléchargement
• Dépôt GitHub