GoReplay & traffic replay — capturer le trafic de prod et le rejouer ailleurs

1📖 Glossaire — le vocabulaire de base

• Traffic replay — rejouer des requêtes réelles enregistrées contre un service, en temps réel ou en différé.
• Shadowing / mirroring — dupliquer le trafic live vers une seconde instance dont la réponse est ignorée (fire and forget). La prod répond toujours depuis l'instance principale.
• Sniffer vs proxy — un proxy est sur le chemin de la requête (il peut la bloquer, la ralentir). Un sniffer écoute le réseau à côté, sans être sur le chemin. GoReplay est un sniffer.
• libpcap / NET_RAW — bibliothèque et capability Linux nécessaires pour lire les paquets bruts d'une interface réseau. Sans CAP_NET_RAW, pas de capture.
• Fichier .gor — format texte de GoReplay : une ligne de métadonnées puis la requête HTTP brute, séparées par un marqueur.
• Middleware GoReplay — programme externe branché sur stdin/stdout qui voit chaque requête et réponse et peut la modifier ou la supprimer avant replay.
• Idempotence — une requête rejouée deux fois produit le même état qu'une fois. Un POST de création ne l'est généralement pas.
• Différentiel (Diffy) — comparer les réponses de deux versions d'un service recevant les mêmes requêtes, en éliminant le bruit non déterministe.

2Les trois familles de replay

Avant de choisir un outil, il faut choisir une famille. Elles ne répondent pas au même besoin.

flowchart LR
    subgraph A["🔴 Shadowing temps réel"]
        direction TB
        A1[Trafic prod] --> A2[Copie immédiate]
        A2 --> A3[Instance candidate]
        A3 -.réponse jetée.-> A2
    end
    subgraph B["🟡 Replay différé"]
        direction TB
        B1[Trafic prod] --> B2[(Fichier de capture)]
        B2 -->|plus tard, ailleurs,<br/>vitesse au choix| B3[Env cible]
    end
    subgraph C["🟢 Record & replay de tests"]
        direction TB
        C1[Trafic + appels sortants] --> C2[(Tests + mocks générés)]
        C2 --> C3[CI, sans dépendances]
    end

3GoReplay — comment ça marche

GoReplay (binaire gor, écrit en Go) se place à côté du service et lit les paquets de l'interface réseau via libpcap. Il reconstitue les requêtes HTTP, leur applique filtres, réécritures et middleware, puis les envoie vers une ou plusieurs sorties. Le service d'origine ne sait même pas qu'il est écouté.

Toute la CLI se lit comme un pipeline input → output :

flowchart LR
    IR["--input-raw :8080<br/>(sniff réseau)"] --> F["Filtres<br/>--http-allow-*"]
    IF["--input-file cassette.gor<br/>(replay différé)"] --> F
    IT["--input-tcp :28020<br/>(reçu d'un autre gor)"] --> F
    F --> R["Réécriture<br/>--http-header, --http-rewrite-url"]
    R --> M["Middleware<br/>(programme externe)"]
    M --> OH["--output-http https://env-cible"]
    M --> OF["--output-file cassette.gor"]
    M --> OT["--output-tcp agregateur:28020"]
    M --> OS["--output-stdout"]

Les trois usages canoniques

# 1. Voir ce qui passe (debug)
sudo gor --input-raw :8080 --output-stdout

# 2. Shadowing temps réel : chaque requête reçue en prod est copiée vers staging
sudo gor --input-raw :8080 --output-http "https://staging.example.com"

# 3. Enregistrer aujourd'hui, rejouer demain
sudo gor --input-raw :8080 --output-file "requests-%Y-%m-%d.gor"
gor --input-file "requests-2026-09-10.gor" --output-http "https://env-cible.example.com"

Les entrées et sorties se combinent : on peut à la fois enregistrer dans un fichier et forwarder vers staging, ou lire un fichier et l'envoyer vers deux environnements.

Flags essentiels

Sans sudo, donner la capability une fois pour toutes au binaire :

sudo setcap "cap_net_raw,cap_net_admin+eip" /usr/local/bin/gor

4Le fichier .gor — une cassette avec le timing

Le format est du texte brut, volontairement simple. Chaque requête est précédée d'une ligne de métadonnées et les entrées sont séparées par un marqueur qu'on ne risque pas de trouver dans un corps HTTP : 🐵🙈🙉.

Exemple tiré d'une appli de préparation de commandes click & collect : un opérateur du magasin 1234 signale un article manquant sur une commande en cours de préparation.

1 a4c3f9e2b1d04c7e8f6a5b3c2d1e0f9a 1757491201123456789
POST /api/pickings/7c1e.../missing-items HTTP/1.1
Host: bff.example.com
X-Store-Id: 1234
Content-Type: application/json

{"sku":"A-4471","quantity":2,"reason":"NOT_FOUND"}
🐵🙈🙉
2 a4c3f9e2b1d04c7e8f6a5b3c2d1e0f9a 1757491201187654321 64198532
HTTP/1.1 200 OK
Content-Type: application/json

{"id":"7c1e...","status":"IN_PROGRESS","missingItems":1}
🐵🙈🙉

La ligne de métadonnées : [type] [request_id] [timestamp_ns] [latence].

• type : 1 requête, 2 réponse d'origine, 3 réponse rejouée.
• request_id : identique entre une requête et ses réponses. C'est ce qui permet de comparer original et rejoué.
• timestamp en nanosecondes : c'est lui qui pilote le rythme du replay.

Le timing, c'est le fichier qui le porte

Au replay, GoReplay respecte les écarts entre timestamps. Une requête à 09:00

gor --input-file "cassette.gor"        --output-http "https://cible"   # timing d'origine
gor --input-file "cassette.gor|200%"   --output-http "https://cible"   # 2x plus vite
gor --input-file "cassette.gor|0"      --output-http "https://cible"   # sans attente, à fond

Plusieurs fichiers, plusieurs serveurs

--input-file accepte un glob. GoReplay lit les fichiers en parallèle et trie les requêtes par timestamp entre les fichiers en streaming, sans tout charger en mémoire :

gor --input-file "captures/pod-*.gor" --output-http "https://cible"

Compression : si l'extension finit par .gz, lecture et écriture sont gzippées automatiquement.

5Filtrer et réécrire — ne rejouer que ce qui t'intéresse

Cas concret : rejouer un seul magasin identifié par un header, et rien d'autre.

sudo gor --input-raw :8080 \
  --http-allow-header "X-Store-Id:^1234$" \
  --output-file "store-1234-%Y-%m-%d.gor"

Les filtres sont des regex et se cumulent :

Puis, au replay, on réécrit ce qui ne peut pas être identique sur l'env cible :

gor --input-file "store-1234-2026-09-10.gor" \
  --http-disallow-url "^/actuator" \
  --http-header "Authorization: Bearer eyJhbGciOi..." \
  --http-header "User-Agent: Replayed by Gor" \
  --output-http "https://bff.env-cible.example.com"

6Middleware — quand un flag ne suffit plus

Les flags font des réécritures statiques. Dès qu'il faut une décision par requête (remapper un id, choisir un token selon l'utilisateur, corréler avec la réponse précédente), on branche un middleware : n'importe quel exécutable qui lit stdin et écrit stdout.

sequenceDiagram
    participant G as gor
    participant M as Middleware (stdin/stdout)
    participant C as Env cible
    G->>M: type 1 · requête d'origine (hex)
    M-->>G: requête modifiée (ou rien = drop)
    G->>C: requête rejouée
    C-->>G: réponse
    G->>M: type 3 · réponse rejouée (hex)
    Note over M: peut mémoriser un id / token<br/>renvoyé par la cible
    G->>M: type 2 · réponse d'origine (si --input-raw-track-response)

Le protocole : chaque message est une ligne hex-encodée. Une fois décodée, c'est l'en-tête [type] [request_id] [timestamp] [latence], un \n, puis le payload HTTP brut. Le middleware doit réémettre les réponses telles quelles et peut modifier ou ne pas réémettre les requêtes (ne rien écrire = la requête est supprimée du replay).

Squelette en Python, qui remplace le token et remappe l'id d'une préparation créée côté cible :

#!/usr/bin/env python3
import sys, re, binascii

id_map = {}          # id prod -> id env cible
pending = {}         # request_id -> True si c'était un POST de création

for line in sys.stdin:
    raw = binascii.unhexlify(line.strip())
    header, _, payload = raw.partition(b"\n")
    ptype, req_id, *_ = header.split(b" ")

    if ptype == b"1":                                   # requête d'origine
        payload = re.sub(rb"Authorization: .*\r\n",
                         b"Authorization: Bearer TOKEN_CIBLE\r\n", payload)
        for prod_id, target_id in id_map.items():       # remap des ids connus
            payload = payload.replace(prod_id, target_id)
        if payload.startswith(b"POST /api/pickings HTTP"):
            pending[req_id] = True
    elif ptype == b"3" and req_id in pending:           # réponse de la cible
        m = re.search(rb'"id":"([0-9a-f-]{36})"', payload)
        if m:
            id_map[b"<id-prod-correspondant>"] = m.group(1)   # à corréler avec la réponse d'origine (type 2)

    sys.stdout.write(binascii.hexlify(header + b"\n" + payload).decode() + "\n")
    sys.stdout.flush()

gor --input-file "cassette.gor" --middleware "./remap.py" --output-http "https://cible"

7GoReplay dans Kubernetes — plusieurs pods, une seule cassette

Trois façons de capturer, selon ce qu'on contrôle.

flowchart TB
    subgraph Prod["Cluster prod"]
        subgraph P1["Pod BFF 1"]
            A1[app :8080]
            S1[sidecar gor]
        end
        subgraph P2["Pod BFF 2"]
            A2[app :8080]
            S2[sidecar gor]
        end
        subgraph P3["Pod BFF 3"]
            A3[app :8080]
            S3[sidecar gor]
        end
        AG["Agrégateur gor<br/>--input-tcp :28020<br/>--output-file cassette.gor"]
        S1 -- "--output-tcp" --> AG
        S2 -- "--output-tcp" --> AG
        S3 -- "--output-tcp" --> AG
    end
    AG --> F[("cassette.gor<br/>ordonnée par timestamp")]
    F -->|"J+1"| T["Env cible<br/>gor --input-file --output-http"]

Option A — sidecar par pod + agrégateur (le plus courant)

Le sidecar partage le namespace réseau du pod, donc il voit le port de l'app en clair. Chaque sidecar envoie ce qu'il capture en TCP vers un agrégateur unique qui écrit le fichier. Pas de fusion manuelle, un seul fichier déjà ordonné.

# extrait du Deployment du BFF
containers:
  - name: bff
    image: registry/bff:1.2.3
    ports: [{ containerPort: 8080 }]
  - name: gor
    image: buger/goreplay:latest
    args:
      - --input-raw
      - ":8080"
      - --http-allow-header
      - "X-Store-Id:^1234$"
      - --http-disallow-url
      - "^/actuator"
      - --output-tcp
      - "gor-aggregator.tooling.svc:28020"
    securityContext:
      capabilities:
        add: ["NET_RAW", "NET_ADMIN"]

# sur le pod agrégateur
gor --input-tcp :28020 --output-file "/captures/store-1234-%Y-%m-%d.gor.gz"

Option B — DaemonSet avec sélecteur k8s://

Les versions récentes savent capturer depuis le nœud en ciblant des pods via l'API Kubernetes. Un DaemonSet tourne sur chaque nœud, avec un ServiceAccount qui a get / list / watch sur pods, deployments et daemonsets.

gor --input-raw "k8s://prod/deployment/bff:8080" --output-tcp "gor-aggregator:28020"

Sélecteurs disponibles : k8s://[ns/]pod/nom, k8s://[ns/]deployment/nom, k8s://[ns/]daemonset/nom, k8s://[ns/]labelSelector/app=bff, k8s://[ns/]fieldSelector/.... Sans namespace, tous les namespaces. Avantage : aucune modification des Deployments applicatifs.

Option C — capturer à l'ingress

Un seul point de capture, mais le pod ingress voit tout le cluster et, souvent, du TLS. À réserver si l'ingress parle en clair vers l'amont et si le filtrage par header suffit à isoler ce qu'on veut.

8Les pièges d'un replay — ce que l'outil ne réglera jamais

GoReplay renvoie les mêmes octets. Le scénario, lui, dépend de l'état du serveur. Voici ce qui casse, dans l'ordre où on le découvre.

flowchart LR
    R["Requête rejouée<br/>(octets identiques)"] --> A{Token<br/>valide ?}
    A -- non --> A1["401 sur tout<br/>→ --http-header Authorization"]
    A -- oui --> B{Ressource<br/>/id existe ?}
    B -- non --> B1["404<br/>→ dump de la veille + remap d'ids"]
    B -- oui --> C{Déjà<br/>rejouée ?}
    C -- oui --> C1["Doublon<br/>→ un seul run, ou idempotence"]
    C -- non --> D{Dépend de<br/>la date du jour ?}
    D -- oui --> D1["Réponses vides<br/>→ shift de date ou données à J-1"]
    D -- non --> OK["✅ Fidèle"]

9Les autres outils connus — et quand les préférer

Istio / Envoy mirror — le shadowing sans rien installer

Si le service mesh est déjà là, une VirtualService suffit. Le trafic est dupliqué vers un second subset en fire and forget, la réponse du miroir est jetée, et Istio ajoute -shadow au header Host pour que la cible sache qu'elle reçoit une copie.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bff
spec:
  hosts: [bff]
  http:
    - route:
        - destination: { host: bff, subset: v1 }
          weight: 100
      mirror: { host: bff, subset: v2 }
      mirrorPercentage: { value: 100.0 }

Quand : shadowing temps réel d'une nouvelle version. Limite : pas d'enregistrement, pas de replay différé, pas de filtrage par header sans une règle match dédiée. nginx propose l'équivalent avec la directive mirror.

Diffy — comparer les réponses, pas juste rejouer

Diffy (né chez Twitter) est un proxy qui envoie chaque requête vers trois instances : primary et secondary font tourner le code connu, candidate le nouveau. Les différences primary ↔ secondary mesurent le bruit (timestamps, ids aléatoires, ordre non déterministe). Seules les différences candidate ↔ primary qui dépassent ce bruit sont des régressions.

Quand : valider qu'une refonte (migration de framework, réécriture d'un service) répond pareil. Il se nourrit très bien d'un gor --output-http http://diffy:8880. Limite : lecture seule en pratique, trois instances à faire tourner, projet peu actif.

mitmproxy — le proxy qui enregistre et rejoue, TLS compris

mitmdump -w flows.mitm                    # enregistrer (le client passe par le proxy)
mitmdump -C flows.mitm                    # client-side replay : rejouer les requêtes vers le serveur
mitmdump -S flows.mitm                    # server-side replay : répondre à la place du serveur

Quand : on contrôle le client (tests, mobile, poste de dev), on a besoin du TLS ou du server-side replay (rejouer les réponses pour mocker un backend). Scriptable en Python avec des addons. Limite : c'est un proxy, il faut router le client vers lui. Impraticable pour du trafic prod entrant à l'échelle.

tcpreplay — les paquets bruts, sans comprendre HTTP

tcpdump -i eth0 -w capture.pcap port 8080
tcpreplay -i eth0 --multiplier=2 capture.pcap

Rejoue un .pcap au niveau 2-4, octet pour octet, sans rien savoir du protocole. Quand : tester un firewall, un IDS, une pile réseau. Limite : aucune réécriture applicative, les sessions TCP rejouées ne sont pas de vraies connexions avec le serveur cible. Pas fait pour tester une API.

Keploy — eBPF, tests et mocks générés

Keploy capture au niveau noyau (eBPF) le trafic entrant et les appels sortants (Postgres, MongoDB, Redis, Kafka, HTTP). Il en fait des cas de test avec les mocks des dépendances, rejouables en CI sans base ni broker. Langage-agnostique.

Quand : transformer un flux réel en suite de tests d'intégration reproductibles. Limite : orienté tests de dev/CI, pas replay d'une journée de prod à l'échelle ; nécessite eBPF donc Linux récent et privilèges.

Speedscale / proxymock — la version commerciale « Kubernetes-native »

Sidecar proxy installé par un Operator, capture entrant et sortant, mocke les dépendances, et sait décaler les timestamps des données sensibles à la date. Version gratuite proxymock pour le poste de dev. Quand : on veut le replay + mocks + charge dans un produit intégré, avec du support. Limite : commercial, lock-in.

WireMock record & playback

WireMock en mode proxy enregistre les échanges vers un backend et les rejoue comme stubs. C'est du server-side replay côté Java, très utilisé en tests. Pas un outil de replay de trafic entrant.

Et pour Kafka ? Le replay est natif

Un topic Kafka est déjà une cassette : les messages restent pendant la rétention avec leur timestamp. Pour rejouer la journée d'hier à un consumer, il suffit de repositionner son groupe :

kafka-consumer-groups.sh --bootstrap-server kafka:9092 \
  --group picking-service --topic order-placed \
  --reset-offsets --to-datetime 2026-09-10T00:00:00.000 --execute

Autres scénarios : --to-earliest, --to-latest, --by-duration PT24H, --shift-by -1000, --to-offset. Toujours faire un --dry-run d'abord, et arrêter le consumer pendant le reset (le groupe doit être inactif). Entre deux clusters, copier les messages avec MirrorMaker 2 ou un petit consumer/producer qui filtre et respecte les écarts de timestamps.

Tableau de synthèse

10Exemple complet — rejouer la journée d'un magasin sur un env cible

Scénario : une enseigne propose du click & collect. Les clients commandent en ligne, chaque commande arrive au service picking par un événement Kafka order-placed qui porte le magasin de retrait. En magasin, les préparateurs utilisent une appli mobile qui passe par un BFF, avec le header X-Store-Id, pour démarrer une préparation, signaler un article manquant et marquer la commande prête. On veut simuler la journée du magasin 1234 sur un env de test, comme une copie de ce qui s'est passé hier, avec un état de départ contrôlé.

flowchart LR
    Cli[Clients web] -->|order-placed| K[(Kafka)]
    K --> PK[Service picking]
    Op[Préparateurs<br/>magasin 1234] -->|X-Store-Id: 1234| BFF[BFF]
    BFF --> PK
    BFF --> ST[Service stock]
    PK -->|order-ready| N[Notifications client]

Deux canaux d'entrée, donc deux choses à rejouer : les commandes (Kafka) et les gestes des préparateurs (HTTP). Les gestes n'ont de sens que si les commandes existent déjà.

sequenceDiagram
    participant P as Prod (3 pods BFF + sidecars gor)
    participant AG as Agrégateur gor
    participant K as Kafka cible
    participant DB as Bases env cible
    participant T as BFF env cible

    Note over P,AG: Jour J
    P->>AG: --output-tcp (filtré X-Store-Id: 1234)
    AG->>AG: store-1234-J.gor.gz

    Note over DB,K: Soir du jour J
    DB->>DB: 1. pg_dump / snapshot de TOUTES les bases touchées (picking, stock)
    K->>K: 2. injecter les commandes order-placed du jour J (magasin 1234)

    Note over T: Jour J+1
    AG->>T: 3. gor --input-file store-1234-J.gor.gz<br/>--http-header Authorization<br/>--output-http
    T-->>AG: réponses rejouées (type 3)
    DB->>DB: 4. extrait cible, comparé à l'extrait prod de fin de J<br/>sur clé métier, pas sur ids ni timestamps

1. Capture (jour J), sur chaque pod BFF

gor --input-raw :8080 \
    --http-allow-header "X-Store-Id:^1234$" \
    --http-disallow-url "^/actuator" \
    --output-tcp "gor-aggregator.tooling.svc:28020"

2. Agrégation, un seul fichier

gor --input-tcp :28020 --output-file "/captures/store-1234-%Y-%m-%d.gor.gz"

3. Dump et commandes du jour (soir du jour J)

pg_dump -Fc picking > picking-before-replay.dump
pg_dump -Fc stock   > stock-before-replay.dump
kafka-consumer-groups.sh --bootstrap-server kafka-cible:9092 --group picking-service \
  --topic order-placed --reset-offsets --to-datetime 2026-09-10T00:00:00.000 --dry-run

Si les clusters Kafka sont séparés, remplacer le reset par une copie des messages order-placed du magasin 1234 vers le topic de l'env cible.

4. Replay (jour J+1), timing d'origine

gor --input-file "/captures/store-1234-2026-09-10.gor.gz" \
    --http-header "Authorization: Bearer ${TOKEN_ENV_CIBLE}" \
    --http-header "User-Agent: Replayed by Gor" \
    --output-http "https://bff.env-cible.example.com" \
    --output-file "/captures/replayed-2026-09-11.gor"

Le second --output-file garde les réponses rejouées (type 3) : c'est la matière première de la comparaison.

5. Comparer l'état final de la cible avec l'état prod de fin de journée J, en joignant sur la clé métier (numéro de commande + SKU) et en ignorant les ids techniques des préparations et les instants de création, qui diffèrent forcément. Ce qu'on attend : mêmes commandes prêtes, mêmes articles signalés manquants, mêmes quantités.

Sources

• GoReplay — dépôt GitHub (buger/goreplay) — README, architecture, images
• GoReplay — Saving and Replaying from file — format .gor, suffixes de vitesse, glob, gzip
• GoReplay — Request filtering — --http-allow-header, --http-allow-url, --http-allow-method
• GoReplay — Request rewriting — --http-header, --http-set-param, --http-rewrite-url
• GoReplay — Middleware — protocole stdin/stdout, types 1/2/3, exemple de mapping de tokens
• GoReplay — Capturing (goreplay.org/docs) — --input-raw, moteurs, capabilities, TLS
• GoReplay — Kubernetes (k8s/README) — DaemonSet, RBAC, sélecteurs k8s://
• GoReplay — Troubleshooting — CAP_NET_RAW, sidecar
• kubereplay — intégration GoReplay / Kubernetes (lwolf) — operator communautaire
• Istio — Traffic Mirroring — mirror, mirrorPercentage, suffixe -shadow
• Diffy — opendiffy/diffy — topologie primary / secondary / candidate, images
• mitmproxy — Features — client-side et server-side replay
• Keploy — keploy/keploy — record/replay eBPF, tests et mocks générés
• Speedscale — GoReplay vs Speedscale — comparaison, point de vue éditeur
• Speedscale — Definitive guide to traffic replay — panorama des familles d'outils
• Apache Kafka — Operations, consumer groups — kafka-consumer-groups.sh --reset-offsets
• kafka-core-model — offsets, consumer groups, rétention : pourquoi un topic est déjà une cassette
• kafka-spring-error-handling — idempotence consumer, prérequis d'un replay Kafka
• spring-boot-tests-integration — Testcontainers pour reconstituer un env cible jetable