Comment le Collector communique avec PWR : les flux Startup, PULL et PUSH
10 min de lecture
Trois schémas de séquence détaillés pour comprendre exactement comment le Collector démarre, comment PWR récupère des rapports à la demande (PULL) et comment le Collector remonte ses heartbeats et snapshots (PUSH) — et pourquoi votre base PostgreSQL reste isolée dans les trois cas.
Vue d'ensemble : trois flux, un seul principe d'isolation
Le Collector et PWR échangent selon trois flux bien distincts, illustrés par les trois schémas de cette page : le démarrage et l'établissement du tunnel (Startup & Tunnel), les requêtes à la demande via le tunnel Cloudflare (PULL) et les remontées proactives du Collector (PUSH).
Ces trois flux partagent un même principe : la base PostgreSQL du client n'est jamais interrogée que localement, par le Collector lui-même. Ni PWR (le SaaS), ni Cloudflare n'obtiennent d'accès direct à la base ou à ses identifiants, quel que soit le flux en cours.
- PUSH : connexion sortante initiée par le Collector vers PWR — heartbeats, statut et snapshots légers envoyés proactivement, dès le démarrage du Collector.
- PULL : requête initiée par PWR, acheminée uniquement à travers le tunnel Cloudflare déjà établi en sortie par le Collector — jamais une connexion entrante directe vers le réseau du client.
- Startup & Tunnel : la séquence de démarrage qui met en place la connexion sortante (tunnel) utilisée ensuite par le flux PULL.
Flux 1 — Startup & Tunnel : démarrage du Collector et établissement de la connexion sortante
Au démarrage, le processus Collector se met à écouter en local (host:port) indépendamment de toute configuration COLLECTOR_BASE_URL : il fonctionne dès son lancement, que le tunnel soit déjà provisionné ou non.
Le Collector établit ensuite une connexion sortante vers Cloudflare Tunnel (cloudflared), qui lui attribue une URL publique stable (par exemple clientNN.audit-postgresql.com). Le Collector transmet cette URL au backend PWR via update_status(..., collector_base_url=URL), qui l'enregistre et accuse réception (ack).
Point important : COLLECTOR_BASE_URL n'est qu'une métadonnée de routage utilisée par le SaaS pour savoir où adresser ses futures requêtes PULL — elle n'active ni ne désactive le processus Collector, qui tourne déjà de façon autonome sur la machine du client.
Flux 2 — PULL via le tunnel Cloudflare : rapports et opérations à la demande
Le flux PULL est indépendant du flux PUSH : il est déclenché uniquement quand PWR a besoin de données à la demande, par exemple lorsqu'un utilisateur consulte le live, ouvre un snapshot précis ou génère un rapport de comparaison depuis son espace compte.
PWR récupère d'abord COLLECTOR_BASE_URL auprès du central control store, puis adresse une requête HTTP à https://clientNN.../api/reports/.... Cloudflare Tunnel reçoit cette requête sans qu'aucun port entrant n'ait été ouvert côté client, et la relaie à travers la connexion sortante déjà établie par le Collector jusqu'à son API locale.
Le Collector traite alors la route concernée (/api/live, /api/snap/{snap_id}, /api/reports/*), interroge localement perfhist ou pg_stat_* avec les paramètres du rapport demandé, puis renvoie la réponse HTTP qui est relayée telle quelle jusqu'à PWR par le tunnel.
Utilité pour l'installation : c'est ce flux qui alimente le live et les rapports affichés dans votre espace compte sans exposer directement PostgreSQL sur Internet — Cloudflare ne fait que relayer des octets, il ne se connecte jamais lui-même à la base.
Flux 3 — PUSH : heartbeats et snapshots envoyés proactivement
Le flux PUSH est également indépendant du flux PULL : c'est le Collector qui initie systématiquement la connexion sortante vers PWR, en s'authentifiant avec son propre Collector Token.
Une fois authentifié (200 OK), le Collector envoie périodiquement un send_heartbeat (acquitté par un 2xx) puis un POST /collector/snapshot contenant un snapshot léger, également acquitté.
Utilité pour l'installation : ce flux est ce qui fait passer votre connexion à Collector connecté avec une dernière activité à jour dans votre espace compte, sans qu'aucune connexion entrante ne soit jamais nécessaire vers le réseau du client.
Isolation de votre base de données dans les trois flux
Dans les trois schémas ci-dessus, une seule flèche touche jamais Client DB (local data source) : celle qui part de Collector (client network). Ni PWR, ni le central control store, ni Cloudflare Tunnel n'apparaissent connectés à la base — c'est le résultat direct de l'architecture, pas seulement une bonne pratique documentée.
Le Collector Token (authentification Collector ↔ PWR, utilisé en PUSH) et le Tunnel Token (authentification cloudflared ↔ Cloudflare, utilisé pour établir le tunnel en Startup) sont deux secrets distincts : la compromission de l'un ne donne accès ni à l'autre, ni aux identifiants PostgreSQL, qui ne quittent jamais la configuration locale du Collector.
Même en PULL, le tunnel Cloudflare ne relaie que des requêtes HTTP vers l'API locale du Collector : il n'a ni la capacité ni les identifiants pour interroger PostgreSQL directement.
PUSH vs PULL : ce qu'il faut retenir
Les deux flux sont complémentaires et fonctionnent indépendamment l'un de l'autre : l'absence de rapport à la demande (PULL) n'affecte jamais les heartbeats (PUSH), et inversement.
- PUSH — initié par : le Collector, vers PWR.
- PUSH — sert à : heartbeats, statut de connexion, snapshots légers envoyés proactivement.
- PUSH — fréquence : continue, dès le démarrage du Collector.
- PULL — initié par : PWR, vers le Collector via le tunnel Cloudflare.
- PULL — sert à : rapports et opérations à la demande (live, snapshot précis, comparaisons).
- PULL — fréquence : ponctuelle, déclenchée par une action dans votre espace compte.
- Commun aux deux flux : aucune connexion entrante n'est jamais ouverte sur le réseau du client, et seule PostgreSQL, jamais Cloudflare ni PWR, est interrogée directement par le Collector.