RousselTMLEARNING

Observabilité

Bindplane en production : haute disponibilité, sécurité, Kubernetes et configuration as code

Exploiter Bindplane en production : serveurs actifs-actifs, PostgreSQL et bus d'événements, TLS pour OpAMP, haute disponibilité des collecteurs, Kubernetes, CLI, Terraform et supervision.

1. Haute disponibilité du serveur #

Le plan de contrôle.

Architecture #

Bindplane en haute disponibilité
  • Les serveurs Bindplane sont sans état et fonctionnent en actif-actif derrière un équilibreur (qui doit supporter les WebSockets pour OpAMP).
  • Composants à fournir : équilibreur, PostgreSQL hautement disponible, Prometheus pour les mesures et un bus d'événements entre serveurs (par exemple Google Pub/Sub dans l'exemple de référence de l'éditeur).
  • Tous les serveurs ont la même configuration.
À savoir : Rappel : une panne du serveur n'arrête pas la collecte. La haute disponibilité du serveur protège la capacité à changer les configurations, pas le flux de données.

2. Haute disponibilité de la collecte #

Le plan de données.

Ne rien perdre #

RisqueProtection
Destination indisponibleFile d'attente persistante sur disque (persistent queue) et nouvelles tentatives dans le collecteur
Gateway en pannePlusieurs collecteurs gateway derrière un équilibreur OTLP
Pic de volumeBatch, limite mémoire (memory limiter), dimensionnement des gateways sur le débit mesuré
Mauvaise configurationRollouts par lots avec pause sur erreur, retour arrière

3. Sécurité #

Protéger le plan de contrôle.

Mesures #

  • TLS sur l'interface et sur OpAMP (wss://) ; sur Kubernetes, certificat d'autorité monté dans le collecteur (OPAMP_TLS_CA), voire TLS mutuel (OPAMP_TLS_CERT, OPAMP_TLS_KEY).
  • Clé secrète des collecteurs traitée comme un mot de passe et renouvelée si elle fuit.
  • Comptes nominatifs, SSO et RBAC (Admin, User, Viewer) selon l'édition ; pas de compte admin partagé.
  • Secrets des destinations (jetons, mots de passe) stockés dans Bindplane plutôt que dans des fichiers sur chaque serveur.

4. Configuration as code #

Reproductible et revu.

CLI et Terraform #

# Exporter tout ce qui a été construit dans l'interface
mkdir -p bindplane/ && for c in $(bindplane get configurations --output json | jq -r '.[].metadata.name'); do
  bindplane get configuration "$c" --export --output yaml > "bindplane/$c.yaml"
done
git add bindplane/ && git commit -m "Export des configurations Bindplane"

# En CI, sur le serveur cible
bindplane apply bindplane/**/*
bindplane rollout start --all

Un fournisseur Terraform officiel permet aussi de déclarer configurations, sources, processeurs et destinations comme des ressources, avec revue de code et plan avant application.

Erreur Courante : Si l'interface et Git modifient tous deux les mêmes configurations, la prochaine application de Git écrasera les changements faits à la main. Décidez quelle est la source de vérité, et réservez l'interface à l'exploration et aux snapshots.

5. Superviser Bindplane #

Le pipeline est un service critique.

À suivre #

  • Collecteurs déconnectés ou en erreur (page Collectors, ou bindplane get agents).
  • Débit par destination : une chute brutale signale un problème de collecte ou de réseau.
  • Taille des files d'attente persistantes : elle grossit quand une destination est lente.
  • Santé du serveur, de PostgreSQL et de Prometheus.

Articles liés

Bindplane : gérer ses pipelines de télémétrie OpenTelemetry

Comprendre Bindplane : plan de contrôle des collecteurs OpenTelemetry via OpAMP, BDOT Collector, configuratio…

OpenTelemetry Collector, Grafana Alloy et Bindplane : comparer trois approches des pipelines de télémétrie

Comparatif détaillé de trois façons de gérer des pipelines de télémétrie : l'OpenTelemetry Collector en YAML,…

Installer Bindplane : serveur, BDOT Collector et connexion OpAMP

Installer le serveur Bindplane (Docker Compose, Linux, Kubernetes), connecter des collecteurs BDOT par OpAMP …

Pour aller plus loin