1. Passer en production #
Du nœud unique au cluster.
Quel mode choisir ? #
| Situation | Mode |
|---|---|
| Essai, petite équipe, perte de quelques minutes acceptable | Nœud unique sur disque |
| Nœud unique, données à protéger | Nœud unique avec stockage objet |
| Disponibilité exigée, forte charge | Haute disponibilité sur Kubernetes |
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.yaml2. 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 une version de l'image plutôt que
latest, 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.
