Follow one thing across protocols
This is what makes Spider more than a packet viewer. As it decodes a communication, Spider pulls business identifiers out of the payload itself - an order id, a customer, a request id, a country - with no instrumentation of your code. Just decoding and extraction.
Tags and correlation ids
Two kinds of extracted value tie your traffic together:
- Tags - business values lifted from inside the decoded payload (see the Tag field in a communication's Global tab, and the parsing configuration that defines them).
- Correlation ids - identifiers Spider recognises as links between calls, so a request in one service can be matched to the call it triggered in another.
Both are searchable. Filter on a single value and Spider shows you every call that carries it - the HTTP request, the gRPC call, the PostgreSQL query, the Redis command, the Kafka event - side by side in the grid, or in order in the sequence diagram. One identifier, its whole life across the stack.
From the grid or a detail panel, use a quick filter on a tag or correlation id to pivot to every related communication (see Quick filters).
Reading binary payloads
Some of those calls are binary on the wire. Transcoding renders a gRPC protobuf payload as readable JSON, so the identifier is visible and filterable just like an HTTP field.
Turning ids into business meaning
An extracted id is often a raw value - a UUID, an internal key. A plugin can translate it into something a human reads and link it back to your own systems, so a tag becomes a doorway to the business record behind the traffic (see Plugins).
Want to see this end to end on a live system, without a cluster of your own? The live demo traces a single order across HTTPS, gRPC, Redis, PostgreSQL and Kafka - all from captured, decrypted traffic.
Next, let's look at filters to select exactly the communications you need.