How is capturing traffic different from tracing or logging it?

A log or a span is a description someone wrote in advance, recording the fields they expected to need. A capture is the traffic itself. You can go back to a capture and ask a question nobody anticipated, because the bytes are still there; you cannot do that with a log entry that never contained the field.

Can I open Spider captures in Wireshark?

Yes. Spider exports sessions as pcapng, encrypted and decrypted alike, so anything you find can be handed to Wireshark or to a colleague who does not use Spider. It also imports pcapng, so a capture taken elsewhere can be decoded and analysed inside Spider.

Do I need to capture everything all the time?

No, and generally you should not. Capture is targeted: you decide which workloads to watch and when. Pointing it at what you are investigating is both cheaper and easier to work with than capturing the whole estate continuously.

Can I replay captured traffic against a service?

For HTTP, yes, at two scales. A single captured request exports as a runnable curl command from the interface. For a whole feed there is Ingest, which reads captured communications through the API, rewrites them with regular expressions to address a different environment, replays them and compares the responses. Flowbird, now Arrive, used it to replay live production traffic onto a new platform during a migration. Both are HTTP only today; for other protocols you get the reconstructed exchange and pcapng export.

Capturing and replaying traffic between services

Some problems only exist in production. The request that fails one time in four hundred, the third-party integration that swears it sent the right thing, the migration that behaves differently under real load. What these have in common is that you cannot reason your way to the answer. You need the traffic itself.

Why logs and traces are not enough

Logs and spans are descriptions written in advance. Somebody decided which fields mattered, wrote code to record them, and everything else was discarded at the moment it passed. That is the right trade for monitoring, where you need a small, cheap, constant signal. It is the wrong trade for investigation, where the field you need is reliably the one nobody logged.

Traces have the same shape with a nicer picture. A span tells you a call happened, how long it took and how it ended. It does not tell you what was in the body, and you cannot replay it. Aggregation makes this worse: by the time a metric says the error rate rose, the individual requests that caused it are gone.

What a capture gives you instead

Spider captures packets in the pods, rebuilds the TCP sessions they belong to, and decodes each request and response in full. Encrypted traffic is included, because the session keys are read out of process memory as connections are established. How that works →

What you end up with is not a summary of the conversation. It is the conversation: the exact request, the exact response, the headers nobody thought to log, and the packets underneath them if the answer turns out to be at that level.

The pcapng round trip

Anything Spider holds can leave it. Sessions export as pcapng, encrypted and decrypted both, so a finding can be opened in Wireshark, attached to a ticket, or sent to a vendor who has never heard of Spider. That matters more than it sounds: evidence that only exists inside one tool is difficult to act on with anyone outside your team.

It works in the other direction too. A pcapng taken somewhere else can be imported into Spider and decoded with the same parsers, which is how a capture from a system Spider was never deployed to still ends up readable.

Replaying what you captured

One request at a time, any captured HTTP call exports as a runnable curl command straight from the interface. A request you found in production becomes one you can fire again, hand to a colleague, or drop into a test.

At the other end of the scale there is Ingest, which replays a whole feed. It queries captured communications through Spider's API, rewrites them with regular expressions so they address a different environment, sends them, and compares the response codes and bodies that come back. What you get is not a load generator firing synthetic traffic, but your own production requests, in their real distribution, run against a system that has never seen them.

Flowbird, now Arrive, used it to migrate more than a hundred microservices from Docker Swarm to Kubernetes in a single cutover, which left no room for a progressive rollout. The live Swarm feed was replayed onto the new Kubernetes production about 45 seconds behind, at the same load, with URLs rewritten to match the new platform, and the two systems' responses compared as they went. Differences were found and fixed before the switch rather than after it.

Both paths are HTTP only today. For the other protocols, the reconstructed exchange and its pcapng are what you work from. Ingest documentation →

What this gets used for

Reproducing a failure that will not reproduce anywhere except production.
Validating a migration by replaying the live production feed onto the new platform and comparing the responses.
Settling an argument with a third party about what was sent, with the bytes to show for it.
Cloning a protocol before a vendor withdraws the system that speaks it.

That last one is not hypothetical. The case studies include a 2024 incident where captured traffic was the specification for a replacement, because no other description of the protocol existed.

Who else can do this

Kubeshark also captures packets across a cluster and exports filtered PCAP, and it is free on small clusters. Pixie does not capture packets, so it cannot produce a PCAP. Cilium ships a separate packet-capture recorder that can, though it sits outside Hubble's flow view. DeepFlow's capture is flow-oriented. How the five tools compare →

Competitor details checked on 9 August 2026 against vendor documentation.

Common questions

How is capturing traffic different from tracing or logging it?: A log or a span is a description someone wrote in advance, recording the fields they expected to need. A capture is the traffic itself. You can go back to a capture and ask a question nobody anticipated, because the bytes are still there; you cannot do that with a log entry that never contained the field.
Can I open Spider captures in Wireshark?: Yes. Spider exports sessions as pcapng, encrypted and decrypted alike, so anything you find can be handed to Wireshark or to a colleague who does not use Spider. It also imports pcapng, so a capture taken elsewhere can be decoded and analysed inside Spider.
Do I need to capture everything all the time?: No, and generally you should not. Capture is targeted: you decide which workloads to watch and when. Pointing it at what you are investigating is both cheaper and easier to work with than capturing the whole estate continuously.
Can I replay captured traffic against a service?: For HTTP, yes, at two scales. A single captured request exports as a runnable curl command from the interface. For a whole feed there is Ingest, which reads captured communications through the API, rewrites them with regular expressions to address a different environment, replays them and compares the responses. Flowbird, now Arrive, used it to replay live production traffic onto a new platform during a migration. Both are HTTP only today; for other protocols you get the reconstructed exchange and pcapng export.