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.
Everything is a tag
There is only one mechanism: a tag is a value the Whisperer lifts out of a decoded communication and stores alongside it - an order id, a customer, a country, a request id. Tags are searchable, aggregatable, and the same whatever the protocol carried them.
What differs is where the tag comes from, and that difference is worth understanding because it decides how much work you have to do and how far the answer reaches.
| Technical correlation | Business correlation | |
|---|---|---|
| Where it comes from | A propagation header your stack already emits - traceparent, X-Request-ID, X-Correlation-ID | A value that already lives in your payload - an order id, a customer reference |
| What it costs you | Nothing. The rules ship pre-written | A tag rule per protocol, written once, describing where the value sits |
| How far it reaches | Every hop that was instrumented to propagate it. HTTP, gRPC, Kafka and PostgreSQL; never Redis | Every hop that carries the value, instrumented or not - including the datastore and the legacy service nobody will touch |
| What it groups | One entry point and everything that followed from it | One object, across requests that have nothing to do with each other |
| What it means | "These calls belong to one request" | "These calls belong to one order" |
Neither replaces the other. Technical correlation is what you get in the first twenty minutes; business correlation is what you get once you tell Spider what your business calls things - and it is the one that answers the question your users actually asked.
They slice your traffic in different directions
The two are not the same thing with different amounts of effort. Even with every hop instrumented, they cut the same traffic along different axes.
A trace is a slice of time through the system: whatever was causally downstream of one entry point, inside one request's lifetime. A business identifier is a slice through an object's life: everything that ever touched one order, across requests that are technically unrelated and may be days apart.
Two cases where the difference decides whether you find anything at all:
- A bulk call. A nightly sync pulls 500 orders in one request, or a Kafka batch carries 200 events. That is one request, so it carries one correlation id, and all 500 orders are folded into it. The chain tells you the sync ran; it cannot tell you what happened to yours, because at that hop your order stopped being a thing and became a row. Filter on the order id instead and that same call appears in each of the 500 chains, because the identifier is in the payload it moved. There is no way to fix this with propagation: one request cannot carry 500 trace contexts.
- Background work and events. An order is created by a web request, amended by an agent an hour later, settled by a payment webhook the next morning, reconciled by a batch that night. Four entry points, four unrelated correlation ids, one order. Trace context can cross an async boundary, but it cannot survive the object being stored and re-read - the next thing to touch that row arrives with its own context or with none. The business identifier is written into the row, so it is still there when the batch reads it back.
Correlating communications
Filter on a single tag 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.
Communications carrying a correlation tag get a shortcut for this, a link button in the grid's Links column:
Click- the whole chain in the All view.Shift + Click- the same chain as a sequence diagram.
Which tags earn that button is up to you: it is the Correlation setting in the
Global settings tab, and it defaults to correlationId, the tag the pre-written rules write into. Point it at your
own order-id tag and the button follows the business chain instead.
From the grid or a detail panel, you can also quick-filter on any tag value 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.