1. Construire un pipeline #
Le cœur de Bindplane.
Les trois blocs #
| Bloc | Exemples | Conseil |
|---|---|---|
| Sources | File, Journald, Syslog, Windows Events, OTLP, Kubernetes, Prometheus, bases de données, AWS, Azure, GCP | Une source par type de données, labels et attributs dès l'entrée |
| Processeurs | Parse JSON/Regex/CSV, Severity Filter, Filter by condition, Deduplicate, Sampling, Mask Sensitive Data, Add Fields, Batch | Filtrer tôt, enrichir juste avant la destination qui en a besoin |
| Destinations | OTLP, Splunk HEC, Elasticsearch, Google SecOps, Datadog, Grafana Cloud, Amazon S3, Google Cloud Storage | Une destination réutilisable (ressource partagée) entre configurations |
Sources, processeurs et destinations peuvent être créés comme ressources réutilisables : modifier une destination partagée (une URL, un jeton) met à jour toutes les configurations qui l'utilisent, à leur prochain rollout.
Plateforme et rôle #
Une configuration cible une plateforme (Linux, Windows, macOS, Kubernetes Node/Cluster/Gateway, OpenShift) et un rôle (Edge ou Gateway). Les sources proposées dépendent de la plateforme : Journald n'existe pas pour Windows, Windows Events pas pour Linux.
2. Voir ce qui passe : les snapshots #
Déboguer sans deviner.
Snapshots #
Un snapshot affiche un échantillon des enregistrements réels qui traversent un collecteur, à l'entrée ou à la sortie d'un processeur. C'est l'équivalent visuel de l'exportateur debug, sans redéployer.
- Vérifier qu'un parsing produit bien les champs attendus (
http.status_code,user.id). - Contrôler qu'un masquage s'applique avant la destination.
- Mesurer l'effet d'un filtre : le débit avant et après chaque processeur est affiché sur le pipeline.
Bonne Pratique : Avant d'ajouter un processeur, prenez un snapshot de la source : on écrit une règle de parsing ou de filtrage bien plus vite en ayant les vrais enregistrements sous les yeux.
3. Versions et retour arrière #
Changer sans risque.
Cycle de vie #
- Toute modification crée une version brouillon : les collecteurs continuent d'exécuter la version live.
- Avant le rollout, comparez le brouillon au live, ou abandonnez-le.
- Le retour arrière se fait par Roll forward to this version dans l'historique : Bindplane crée une nouvelle version qui copie l'ancienne (v5 roulée vers v3 devient v6 avec le contenu de v3). L'historique n'est jamais réécrit.
- Avant ce retour, Bindplane vérifie que les sources, processeurs et destinations de l'ancienne version existent toujours.
Erreur Courante : Supprimer une destination partagée bloque le retour vers les versions qui l'utilisaient : désactivez-la ou retirez-la des configurations plutôt que de la supprimer.
